[_CDCSL_93-16_]<1>Cedar>release>AtomButtons>AtomButtonsDoc.tioga~

AtomButtonsDoc.tioga

Eric Bier, March 1, 1987 11:31:10 pm PST

AtomButtons

CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY

AtomButtons

Part II of the New User Interface Architecture

Eric Bier

Abstract: AtomButtons have replaced the standard Buttons, Labels, editable Text Viewers, TiogaButtons, and Choice buttons, in the new user interface architecture, of which Gargoyle is a first example. The chief idea behind the new architecture is that all user events, whether triggered by menus, mouse actions, or keystrokes should be encoded into a stream of tokens and handled uniformly. Using this interface style, all menu actions can be executed from the keyboard, if desired, by changing only the TIP table for the application. AtomButtons encourage this architecture by generating token streams, instead of calling a wild collection of procedures as the old buttons did. AtomButtons also provide a compact format for building several buttons at once, so building large control panels doesn't take so much code.

AtomButtons is being released at this time so that Solidviews can use it. AtomButtons should be ready for general consumption later in the year.

Created by: Eric Bier and Ken Pier

Maintained by: GargoyleImplementors^.pa

Keywords: user interface, input handling, menus

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

For Internal Xerox Use Only

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 section 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).

2. Using AtomButtons

For now, please see AtomButtons.mesa.

3. Using GraphicsButton

For now, please see GraphicsButton.mesa.

4. Using Feedback.mesa

Feedback is a set of routines for handling error and feedback messages throughout a set of applications. This package handles some of the niceties of sending output to both a Labels.Label (where the user sees it immediately) and to a Typescript (where it can be referred to at leisure). This package performs five functions: First, It uses sensible conventions for when to add CR characters to the Typescript, so the client need not worry about CRs at all. Second, it posts messages to two places at once with only one procedure call. Third, in the case of the PutF constructs it combines the formatting and posting of message statements into one procedure call. Fourth, it allows a single Typescript per application, coupled with a feedback line per viewer. Fifth, it notices when the Typescript has been deleted and stops sending messages to the Typescript until another Typescript is created.

The client simply stores a FeedbackData with the data for each application window. For code deep inside the application where it is inconvenient to pass the FeedbackData as an argument, clients can use the Raw routines to send the message to the MessageWindow instead of the Labels.Label.

Feedback isn't really part of the new User Interface Architecture. It is, however, a new user interface tool that has been split off from the Gargoyle project.