Filed on: /cyan/gargoyle/Documentation/NewUIA.tioga version of: February 26, 1986 New User Interface Architecture Eric Bier 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 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). D [Artwork node; type 'ArtworkInterpress on' to command tool] J4JItitleIauthors Ihead IbodyIhead2 NwwNNNONO NNhNNN I artworkFigureG132.2917 mm topLeading 132.2917 mm topIndent 1.411111 mm bottomLeading Bounds:0.0 mm xmin 0.0 mm ymin 147.4611 mm xmax 129.4694 mm ymax Artwork Interpress InterpressInterpress/Xerox/3.0 fjkjWBBbϠrj WBrjWBr玘Xerox PressFonts Helvetica-mrrG6Clear Reset Get GetImpluUrۘ}Ur*}O[Vn?O[\+SKt\+SS ?KtVnyO[VnXeroxResearch RGBLinearMQ"!WFum"!MQMQMQ"!WFum"!MQMQMQ"!umdH"!MQh~MQMQ"!umdH"!MQh~MQ:MQ"!Ãum"!MQQt:MQ:MQ"!Ãum"!MQQt:MQ}rf}r#yۙ\ۏ  Map To Atoms}'}}9InputEDO Notify}'}u}JB/䎘1 Slack ProcessT}}Tέ} ApplicationB<CodeOv`̓}}]롓kI}]mvA F,+,9,,-S3JB/-L2ۏu\u#P. TIP Tablerj#x}}}}}x}x}x}k˙䎘r˗}Ns2o1aFSMrjF}x}}}}}x}x}x}kj}j}d}P5 3 Refreshkkkgn==Icenter-NNNiM N