Apoala Project

.

The representation and interaction forms described above have been implemented in a hybrid visualization tool building environment. The core tool in that environment is Data Explorer (http//www-i.almaden.ibm.com/dx/) a general-purpose data visualization software package available from IBM that runs on most major Unix and Windows 95 -- Windows NT platforms. Data Explorer (DX) employs a dataflow client-server execution model that allows a developer to author visualization applications by selecting modules of appropriate functionality from a large library, and then describing the flow of data through those modules. The selection of modules and dataflow can be specified in a scripting language, or, more commonly, through a visual program editor (VPE) that provides a point&endash;click&endash;connect graphic interface for application authoring.
The functionality of the provided module library can be extended through a macro-program facility that allows new modules to be created by grouping specific combinations of library modules. Alternately, new modules can be written in C, following well-defined guidelines, and added to local DX libraries. Additionally, developers can author applications in C that link directly to either individual modules or entire applications in DX to extend DX functionality. These applications often do not use the native DX user interface and instead create a custom environment that provides a look and feel appropriate to a particular discipline or application. In this project, a facility available in DX called DXLink has been used in conjunction with a custom C program and Tcl/TK scripts (http//sunscript.sun.com/about/) to create a unique, appropriate, graphic user interface for controlling a visualization application authored in DX.

Tcl (Tool Command Language) is a simple, yet powerful, platform independent scripting language (runs on Unix, Windows and Macintosh) that is easily imbedded into other applications. Tk is a window system toolkit that adds the functionality of creating and manipulating very sophisticated graphical user interfaces. Together, Tcl/Tk provides a simple, pragmatic, yet elegant, development toolkit for building graphic user interfaces that can control complex processes in a visually intuitive fashion. Additionally, the rapid development cycle of graphic user interfaces using Tcl/Tk allows for easy experimentation and detailed development of the interface. Tcl/Tk scripts can run standalone, be linked with C programs, or extended over the Web.
The total visualization application exists in three parts: (1.) a DX program that performs the appropriate analysis and display; (2.) a Tcl/Tk script that presents and manages the graphic user interface; and, (3.) a C program that defines the execution context and linkages between Tcl/Tk and DX (figure 13).

A feature of Tcl/Tk is the availability of a custom command interpreter from within a C program, and an important element of this is the ability to extend the functionality of Tcl by adding custom commands that are defined as C procedures. The DXLink facility of DX provides an interface between a C program and the Data Explorer User Interface and the Data Explorer Executive. Functions are available to load and exit DX programs, set and retrieve named variables, control execution, handle errors, process configuration files and scripting commands, control window visibility, and define messaging between the C program and DX. Creating custom commands that Tcl/Tk interactors can access and use to control DX is accomplished by writing C procedures that invoke DXLink facilities and then adding those procedures to the repertoire of commands recognized by the Tcl/Tk interpreter.

int dxproc(ClientData clientData, Tcl_Interp *interp,
int argc, char *argv[]) {

char *sealev;

char slvl[3];

sealev = Tcl_GetVar(interp,"sealev",0);

slvl[0]=*sealev;

++sealev;

slvl[1]=*sealev;

slvl[2]=0;

DXLSetValue(conn, "contour_line_value", slvl);

DXLExecuteOnce(conn);

return TCL_OK;}

That procedure is defined to Tcl/Tk as the command, "dx" by this invocation in the C program

Tcl_CreateCommand(interp, "dx", dxproc, (ClientData) NULL,
(Tcl_CmdDeleteProc *) NULL);

Thus, when the Tcl/Tk interpretor executes the following Tcl statement

button $w.buttons.code -text dx -command "dx"

it will pass control back to the dxproc procedure which will read the current value of the variable, "sealev" (which the user has somehow defined through the graphic user interface), pass it along to DX in the appropriate form, request a single cycle of execution, and return control to the Tcl interpretter.

If only one possible DX application can be executed, it can be started in the C program and the control of it passed on to the Tcl/Tk interpreter. If more than one DX application is possible, specific individual invocations can be defined and added to the Tcl/Tk interpreter for user selection. Alternatively, a command can be created that uses a character string supplied by the user interface to determine which DX application to invoke.

Every user interaction to DX can be managed in this fashion, from simple, context-based scalar input to sophisticated launches of other application programs that recalculate massive streams of data that ultimately arrive back at DX for additional inspection and interaction. Indeed, visualization applications that are authored within a Tcl/Tk context can easily cascade through whatever analysis and display software a user feels is appropriate to the problems at hand. For example, a C program can define, launch and manage a DX application. Depending on the resulting DX analysis, additional C programs, additional Tcl/Tk scripts, and additional applications (say, ArcInfo or Autoclass or even locally-written programs in any language) can be launched either serially or in parallel with the current application, on the local host or on remote resources, hidden or visable to the user. In this manner, the most appropriate visualization software environment for an application can be presented, even when that context is not known ahead of time and/or continually changes throughout the visualization process. This provides a graphic user interface that is intuitive and supportive of the hueristics of the domain expert while defining a flexible, adaptive, control structure for algorithmic processes -- the ideal paradigm for KDD.

Want to learn more about IBM Data Explorer work at Penn State? Go here.

Copyright © 1998-2000 Pennsylvania State University


.
	The representation and interaction forms described above have been implemented in a hybrid visualization tool building environment. The core tool in that environment is Data Explorer (http//www-i.almaden.ibm.com/dx/) a general-purpose data visualization software package available from IBM that runs on most major Unix and Windows 95 -- Windows NT platforms. Data Explorer (DX) employs a dataflow client-server execution model that allows a developer to author visualization applications by selecting modules of appropriate functionality from a large library, and then describing the flow of data through those modules. The selection of modules and dataflow can be specified in a scripting language, or, more commonly, through a visual program editor (VPE) that provides a point&endash;click&endash;connect graphic interface for application authoring. The functionality of the provided module library can be extended through a macro-program facility that allows new modules to be created by grouping specific combinations of library modules. Alternately, new modules can be written in C, following well-defined guidelines, and added to local DX libraries. Additionally, developers can author applications in C that link directly to either individual modules or entire applications in DX to extend DX functionality. These applications often do not use the native DX user interface and instead create a custom environment that provides a look and feel appropriate to a particular discipline or application. In this project, a facility available in DX called DXLink has been used in conjunction with a custom C program and Tcl/TK scripts (http//sunscript.sun.com/about/) to create a unique, appropriate, graphic user interface for controlling a visualization application authored in DX. Tcl (Tool Command Language) is a simple, yet powerful, platform independent scripting language (runs on Unix, Windows and Macintosh) that is easily imbedded into other applications. Tk is a window system toolkit that adds the functionality of creating and manipulating very sophisticated graphical user interfaces. Together, Tcl/Tk provides a simple, pragmatic, yet elegant, development toolkit for building graphic user interfaces that can control complex processes in a visually intuitive fashion. Additionally, the rapid development cycle of graphic user interfaces using Tcl/Tk allows for easy experimentation and detailed development of the interface. Tcl/Tk scripts can run standalone, be linked with C programs, or extended over the Web. The total visualization application exists in three parts: (1.) a DX program that performs the appropriate analysis and display; (2.) a Tcl/Tk script that presents and manages the graphic user interface; and, (3.) a C program that defines the execution context and linkages between Tcl/Tk and DX (figure 13). A feature of Tcl/Tk is the availability of a custom command interpreter from within a C program, and an important element of this is the ability to extend the functionality of Tcl by adding custom commands that are defined as C procedures. The DXLink facility of DX provides an interface between a C program and the Data Explorer User Interface and the Data Explorer Executive. Functions are available to load and exit DX programs, set and retrieve named variables, control execution, handle errors, process configuration files and scripting commands, control window visibility, and define messaging between the C program and DX. Creating custom commands that Tcl/Tk interactors can access and use to control DX is accomplished by writing C procedures that invoke DXLink facilities and then adding those procedures to the repertoire of commands recognized by the Tcl/Tk interpreter. `int dxproc(ClientData clientData, Tcl_Interp interp,` `int argc, char argv[]) {` `char sealev;` `char slvl[3];` `sealev = Tcl_GetVar(interp,"sealev",0);` `slvl[0]=sealev;` `++sealev;` `slvl[1]=sealev;` `slvl[2]=0;` `DXLSetValue(conn, "contour_line_value", slvl);` `DXLExecuteOnce(conn);` `return TCL_OK;}` `That procedure is defined to Tcl/Tk as the command, "dx" by this invocation in the C program` `Tcl_CreateCommand(interp, "dx", dxproc, (ClientData) NULL,` `(Tcl_CmdDeleteProc ) NULL);` `Thus, when the Tcl/Tk interpretor executes the following Tcl statement` `button $w.buttons.code -text dx -command "dx"` `it will pass control back to the dxproc procedure which will read the current value of the variable, "sealev" (which the user has somehow defined through the graphic user interface), pass it along to DX in the appropriate form, request a single cycle of execution, and return control to the Tcl interpretter.` If only one possible DX application can be executed, it can be started in the C program and the control of it passed on to the Tcl/Tk interpreter. If more than one DX application is possible, specific individual invocations can be defined and added to the Tcl/Tk interpreter for user selection. Alternatively, a command can be created that uses a character string supplied by the user interface to determine which DX application to invoke. Every user interaction to DX can be managed in this fashion, from simple, context-based scalar input to sophisticated launches of other application programs that recalculate massive streams of data that ultimately arrive back at DX for additional inspection and interaction. Indeed, visualization applications that are authored within a Tcl/Tk context can easily cascade through whatever analysis and display software a user feels is appropriate to the problems at hand. For example, a C program can define, launch and manage a DX application. Depending on the resulting DX analysis, additional C programs, additional Tcl/Tk scripts, and additional applications (say, ArcInfo or Autoclass or even locally-written programs in any language) can be launched either serially or in parallel with the current application, on the local host or on remote resources, hidden or visable to the user. In this manner, the most appropriate visualization software environment for an application can be presented, even when that context is not known ahead of time and/or continually changes throughout the visualization process. This provides a graphic user interface that is intuitive and supportive of the hueristics of the domain expert while defining a flexible, adaptive, control structure for algorithmic processes -- the ideal paradigm for KDD. Want to learn more about IBM Data Explorer work at Penn State? Go here.
	Copyright © 1998-2000 Pennsylvania State University