AtomButtons is being released at this time so that Solidviews can use it. AtomButtons should be ready for general consumption later in the year.
1. The New User Interface Architecture
Introduction
In the next few months, the Gargoyle project will release, in addition to Gargoyle itself, three of the building blocks upon which it was built: AtomButtons, GraphicsButtons, and SlackProcess. It is hoped that user interfaces in the near future will take advantage of these modules instead of rebuilding them. This report explains what the new modules are trying to accomplish, and how they fit together with each other and with application code.
AtomButtons
AtomButtons is a veneer on top of Buttons, Labels, TiogaButtons, and ViewerTools. It addresses the following problems:
1) Making a line of buttons, labels, and text viewers takes too much source code. For the common case where the buttons are arranged left to right with a constant amount of space between them, building a line of buttons should take no more than one line of source code per button.
2) Actions which come from buttons are processed differently from actions which come from the TIP table. This has two negative results. First, there is no straightforward way to allow the user to tailor his TIP table to provide arbitrary menu actions from the keyboard. (Tioga does allow this. The New UIA tries to make Tioga-type functionality universal.) Second, it becomes difficult to understand how actions are synchronized. (MBQueues was a step in the right direction. SlackProcess replaces MBQueues. See below.)
The AtomButtons interface lets you create a row of Buttons, Labels, and ViewerTools, or a row of TiogaButtons. To create a button, the user must specify what atoms to send to a NotifyProc when that button is pressed (different atoms may be generated depending on which mouse button is used and whether SHIFT or CTRL is down), and must name the NotifyProc to call with these atoms.
GraphicsButtons
GraphicsButtons is a new package providing buttons that display an arbitrary Imager illustration, and update that illustration in response to button clicks.
SlackProcess
SlackProcess replaces MBQueues and provides functionality which has being reinvented many times in CSL. It addresses these problems:
1) It is polite to allow the Notifier process to return quickly. Hence, a second process is necessary.
2) For very interactive actions, such as dragging a graphical object around a scene, the program can get very far behind if it tries to draw the object once for every time the mouse position is polled. If the queue gets filled which such repaint actions, old undone actions can be flushed from the queue to "take up the slack" between where the user has moved the cursor and where the objects are being painted.
3) It would be nice to be able to keep a log of the actions which were actually performed, in order to help the programmer tune the interface, and to serve as a test suite.
The SlackProcess interface allows the user place the atoms received by the InputNotify proc on a slack process queue. At the time they are enqueued, the caller names the procedure to call to handle the action, and specifies whether or not the action is essential. The slack process may skip non-essential actions if it gets behind. A more elaborate scheme is planned where the caller can pass in a procedure which examines the whole queue and chooses which actions to flush.
The Pipeline
[Artwork node; type 'ArtworkInterpress on' to command tool]
The new user interface architecture pipeline.
Both mouse actions and menu actions are piped through the same Input Notify procedure and placed on the slack process queue. When the slack process is ready to handle a new action, it examines the queue to see what is most urgent, and calls the appropriate application code procedure to handle it.
The AtomButtons code or GraphicsButton code handles the Map to Atoms (see figure). The slack process code handles taking actions off of the queue.
There is no longer any need for MBQueues, because the slack process queue sequences all actions properly.
Extensions
It is easy to imagine using more than one slack process. A second slack process might be used to queue up all screen refresh calls in a graphics application. Such a process would be able to flush the queue more drastically, since the user almost always wants to see the most up-to-date version of his scene. The main slack process cannot flush so drastically because most actions make important changes to scene state (even if the user would be willing to miss the screen refresh associated with that action).