George C. Moon
Geographic information is represented as a series of simple objects--points, lines, surfaces and solids. Operations on these objects can compute areas, perimeters, intersections, etc. Significant spatial entities are represented as objects composed of these primitives. A server maintains the spatial models in a relational database, and clients can connect to access information. The Tcl/Tk core was extended to support message management, graphical viewing and session management. Message management provided support for messages in English, German, etc. Graphical objects are supported on a modified canvas widget. [Incr Tcl] was used to build mega-widgets.
In the demonstration, a rainfall simulation was projected onto a city map. The rainfall was increased to flooding proportions, and damaged properties were displayed on the map. The BLT toolkit was used to plot rainfall versus time and damage.
(Talk presented interactively via the Pad++ package)
TkReplay records a interactive session with a program, and replays the actions later. This is useful for demonstrations and regression testing. There are three levels at which events can be replayed: the user level (keystrokes and mouse clicks), the lexical level (widget commands), and the syntactic level (object manipulation). All of these eventually feed down to the semantic level, where the program performs some desired action. The event stream coming from the X server can be easily intercepted and recorded. At the next level down, events can be captured as they are dispatched to widgets. You could go even further and capture the callbacks. In this work, events are captured as they are dispatched to widgets. The TkReplay panel looks like a tape recorder. You can record, rewind, and play. The event stream is summarized in a listbox.
The event stream is captured by wrapping all of the bindings for each widget to record the event and then invoke the usual binding. There are a number of special cases that must be handled. Along the way, all percent fields are captured so that events can be replayed exactly. Widget creation has to be monitored. Canvases and text widgets also have internal bindings that need to be monitored. Bindings can go by different names (e.g., <1> or <Button-1>) so they must be mapped to a single "official" name. On the canvas, the "current" tag has to be captured when the event occurs. Some event handlers call tkwait, waiting for another event to occur.
FIX THIS!!
After you do a replay, how do you know if the result was "right"?
This program is not a regression testing facility. It only addresses replay.
Why do you redefine widget creation commands?
I need to fix up bindings for new widgets.
This project supports user-interface development by having the user develop an object-oriented model of the interface, captured in a declarative description. PLUG-IN generates on-line help pages in HTML and generates an animation sequence that illustrates the actions of the user.
The example shows an ISDN telephone mock-up with a handset, a pushbutton keypad and some extra control buttons. The handset can be taken off hook, and a number can be keyed in to initiate a call. The user interface can be easily changed to support a different paradigm, like a task-directed set of menus.
Tcl/Tk is used as a communication language, and as a way of visualizing the state transition diagrams that capture the system behavior. On-line help pages can be generated on the fly, depending on the current state of the application. All possible paths away from the current state are summarized. For each task, a "show how" button initiates an animation sequence that warps the mouse button over to the graphical interface to perform the task. As each task is completed, the on-line help is updated to walk the user through the next task.
In the future, this work could be extended to support the object-oriented paradigm with task descriptions. State transition diagrams could be generated based on object/task models.
SpecTcl is a table-based graphical user interface builder for Tcl/Tk. It tries to preserve familiar UI builder paradigms, while at the same time supporting intelligent layout facilities that Tk provides. In the future, it will support high-level building blocks, like mega-widgets. It is currently written in ~6000 lines of Tcl code.
The demo shows a canvas area containing an empty table and a palette of widget types on the left. New widgets can be dragged from the palette and dropped onto the table. Selected elements have grips to adjust their row/column span. Common options (text, font, etc.) can be configured from the toolbar at the top. Other properties can be adjusted through a pop-up property sheet. When a design is complete, the "build & run" button invokes a wish to run the application. Instead of using automatically-generated widget names (like ".button#2") in command callbacks, a tag like "%R" can be used to refer to a toplevel.
A web browser was built by dragging over a text widget, scrollbar, some control buttons, and an entry field for URL page names. After bringing up a property sheet and fixing a few command hooks, the "build & run" button brought up a working browser.
The output of the GUI builder can be saved in a simple ASCII format, showing properties and their values. It can also generate Tcl code containing a procedure to build the interface. Each toplevel window has a bunch of siblings that can be moved about without reparenting.
For future work, property sheets could be restructured or streamlined. The undo feature could be enhanced to support multiple-level undo. The builder should also support mega-widget building and editing.