Table of Contents 
Previous Chapter
By the mid 1980s the mouse had become the industry device of choice for user input and selection. We quickly adopted it as well. Its precise point and click capabilities allowed us to include many more menu choices (buttons) on the screen. However, even with the mouse, our user interface continued on a separate dedicated screen for some time. This configuration created serious ambiguity problems when we began using one selection device to drive two display screens. It also had the disadvantage of requiring an additional display screen per workstation. Eventually, the separate menu screen was abandoned when windowing technology became available.
With the emergence of the X window system, it became feasible for menus to share the data-display screen. Again, we quickly began to take advantage of this advance in technology. However, the ability to have multiple display windows on a single screen immediately presented us with a fundamental user interface issue: What is the best way to control multiple windows on an operational meteorological workstation? It is typical using X to have multiple windows open simultaneously, each with its own set of menus and controls. Initially, we experimented with three UI approaches: 1) multiple windows each with their own menu, 2) multiple windows loading from a single menu, and 3) a "fixed panes" approach with menus loading to one main window. We tested prototypes of the first 2 of these interfaces in early versions of WFO-Advanced and found that they both presented many difficult operational problems. With multiple windows open, the forecaster faced difficult window management and input ambiguity issues. These problems were exacerbated in the "heat of battle" when they could least be afforded.
We believe that an operational forecast workstation must differ substantially from the standard X philosophy. FSL's approach assumes that a forecaster workstation is not simply a collection of related applications, but should be a tightly integrated system of tools and capabilities in which frequent interaction with displayed data is the norm. If there is little data integration or forecaster interaction with the data, then UI options 1 or 2 (above) would probably be preferable. The forecaster could simply load a particular data set, say an IR image loop, into a window and passively let it run for long periods. We currently see some workstations used this way. However, the forecasting environment as envisioned for the AWIPS era, and more particularly the short-term warning environment, demands a time-efficient and unambiguous user interface.
This experience and user feedback from the first two FX-Advanced prototypes drove us to the latter of the above three options, the fixed panes approach with menus loading to one main window. Although less flexible, this layout provides a more structured environment for operational use. In addition, and to support the need for time efficiency, the single menu/single load window solution best accommodates tear-away menus which allow users to bypass the normal menu hierarchy and quickly load desired products.
The selection of the fixed 5-pane display area involved careful trade-offs. We traded some flexibility for simplicity and efficiency. This approach virtually eliminates window management tasks and searching through window stacks for a desired display or menu, yet it allows multiple datasets to be visible at the same time with the ability to quickly swap between the main window and the smaller monitor windows when needed. It may not be obvious to the casual observer that this trade-off is the optimum, but the experience in real-time forecasting experiments and in actual meteorological operations validates the benefits of this approach over the others that have been tried.
Other configurations are also possible. The keypads can be removed, for instance. The impact is that experienced users are slowed somewhat in their interaction with displayed data. While all of the functions can be exercised via buttons, pop-ups, and menus using the mouse on the display screen, this requires significant additional mouse travel.
Another option is a single mouse/keyboard for two screens. This has been run experimentally at FSL. In this case, a single X server is used for the two display screens. Although forecasters were trained to use this and most felt comfortable, it has not been tested operationally at Denver. The loss of flexibility wherein only one user can operate the two graphic displays raised sufficient concern that it has not been implemented operationally. The ability for another user to operate one of the displays has been considered of such importance to the smooth operation of the office that the single user interface was not set up in Denver.
The library design has three major objectives:
Figure8.1 Overview of major classes and inheritance relations
The object hierarchy of UI lib classes in an application starts with a ManagedWindow which contains a top level PanedPane. This PanedPane can contain additional PanedPanes which can be additionally nested. Any of these PanedPanes can then contain a MenuPane and/or a UIDevicePane. MenuPanes contain menus which in turn contain buttons. UIDevicePanes contain UIDevices including buttons.
The implementation of the library was done with a product called Object Interface (OI), developed by ParcPlace and now maintained by OpenWare. OI running on Unix machines utilizes Xlib for its implementation. It is capable of presenting both a Motif and OpenLook look and feel interface. For the purposes of this design, the Motif style will be used.
Applications built using the library will also be able to use the OI library and the X library for development. Use of X is strongly discouraged since it makes the applications more difficult to maintain and may cause future portability problems
Figure 8.2 Application Access to Libraries
Figure 8.3 Client classes
The constructor uses the user interface library to create a top-level window containing four small display areas and starts an IGC process in each using the UI workspace manager (see below).
It then adds to the window the menu bar. The menu bar contains the fixed menus File and Scale. The singleton ScaleMenuMgr is responsible for building the scale menu. The remaining menus except the Map menu are specified by the dataMenus.txt file. This file tells what pull-down menus, cascade menus, product buttons, application buttons, and title buttons appear in the menu and where. The format of this file is straightforward; comments in the file give details. The constructor adds the map menu, created by the singleton MapMenuMgr, and adds the clock, created by the singleton Clock.
Callbacks for the widgets built by various singletons are the singletons themselves. Callback for application buttons is the AppMgr singleton. Callbacks for the product buttons are objects of class BB2_ProductButtonClient.
Next, the constructor builds the tool bar. The tool bar (also known as the control bar in the code) creates the clear button, frame step buttons, and the controls menu. The TiledDisplayWindow is itself the callback client of these buttons. On the controls menu, three singletons are the callback clients: GraphicsControlsMgr, ImageControlsMgr, and AnimationMgr (the looping controls). It then adds the load mode button, created by the LoadModeMgr singleton. It ends with the WarnGen button; the TiledDisplayWindow is itself the callback client.
Next, the constructor builds the large display area and starts an IGC to serve it.
Finally, the constructor builds the status bar. It contains two display areas: the left for general status, and the right for radar. Two AnnouncementDisplayer objects are created, one to display general messages, the other for radar messages.
The TiledDisplayWindow singleton calls methods in the UI_WSM_Impl singleton to create IGCs by calling createWSMtuple. This method takes a size type (large or small), a Cartesian pixel extent, and the window in which the IGC should display itself. It then creates the underlay window for that IGC as a child of the window passed in and starts the IGC process, passing it the size type.
When the user wants to swap a small IGC with a large one, the small IGC wishing to do the swap sends an IPC message which is received by the workspace manager's swapWithLargeDisplay method. This method initiates the swap: it tells the small IGC and the large, active one to suspend themselves. After responses from both IGCs have been received by the suspendAcknowledged method of this singleton, the singleton workspace manager tells each IGC to transform itself, passing the new window IDs they'll use. The singleton then saves the ID of the new active IGC.
All IGC requests (to load data, for example) are made to the active IGC. By asking the UI_WSM_Impl singleton for a pointer to the active IGC object, user interface callback objects can get the IGC to perform. For example, the BB2_ProductButtonClient callback is invoked when the user selects a product to load. The callback object determines the depict key to load. It then asks the UI_WSM_Impl for the active IGC object, and calls the load method of that object, passing in the depict key.
After determining the scale and the depict key, it tells the IGC to load the product via the LoadModeMgr (described below).
As forecasters change scale, the set of available products changes. Product buttons must enable or disable themselves to reflect this information and also to change the product time displayed. They do so by registering with the ScaleMenuMgr, which notifies every single product button what the new scale is.
Using an object-oriented callback strategy, callback clients can be registered with the ScaleMenuMgr. Whenever the forecaster changes the scale, the ScaleMenuMgr tells every client what the new scale is. Product buttons (described above) register so they can enable or disable themselves and display a new product time. Applications (represented by objects of class App) register to know when to send a scale change update to a running application.
Also, the ScaleMenuMgr sends the new scale to the active IGC whenever it changes. (The IGC will clear its display if there are no products loaded.)
Like the scale menu manager, the LoadModeMgr keeps a set of callback clients to be notified if the load mode changes. The application interface uses this feature to send the load mode update to running applications.
The most important responsibility of the LoadModeMgr is to send load requests to the active IGC process. The parameters in the load request depend on the current load mode, so the LoadModeMgr is uniquely suited to calling IGC::load.
For certain load modes, the forecaster must enter a forecast time. The LoadModeMgr displays a dialog box and sends the request after the selection. For the Inventory load mode, the forecaster must enter both the forecast time and an inventory time. The LoadModeMgr arranges for the inventory time dialog box to appear after the forecaster makes a selection from the forecast time dialog.
Finally, the LoadModeMgr tracks if image combination is on, and sets the appropriate parameter in the load request.
The ImageControlsMgr also tracks the state of the image colors editor, which enables the forecaster to edit color tables. The image colors editor runs as a separate process which operates on the same color table used to render images in the active IGC window.
When the forecaster uses the time setting application, this singleton will instead return the selected time for both display and inventory for loading.
Selecting a map from the menu results in an IGC load request with the selected map's depict key.
Bundles are created by the IGC process and are passed to the fxa process for ownership. They live in the D2D history list until they're copied to a procedure. When the procedure is saved, the bundle files are collected into a single directory named after the procedure. When selected by a forecaster, either from the history list or from a procedure, a bundle is loaded into the active IGC display. The fxa process treats bundle files as opaque data. It only manages them; it never looks inside.
Because both procedures and the history list display a list of bundles, the class Bundle-List is used to manage the list. This class creates a user interface list widget and populates it with text strings representing the bundle names. An object-oriented callback mechanism tells the callback client of the BundleList when bundles in the list are selected.
The singleton class BundleHistory creates a BundleList to display the bundles in the history list. It gets called by the IGC process to "take a bundle" whenever the process completes one. By taking a bundle, the BundleHistory takes ownership of the file and displays the bundle name in its contained BundleList. Selecting a bundle on the list and pressing Load asks the IGC to load it. Pressing Copy Out copies the bundle to every open procedure.
The class ProcedureDialog represents a procedure. It too contains a BundleList plus a number of buttons that operate on the contained bundles. Loading works as for the history list, as does copying out. Pressing Rename opens the bundle rename dialog, contained in class RenameBundleDialog. The other buttons are straightforward.
ProcedureDialogs are tracked by the ProcedureMgr singleton, which is the callback client for the New... and Open... buttons on the Procedures cascade menu.
The UI_KeypadClient passes the request to the appropriate singleton for processing.
The IGC processes link with the class UI_WorkspaceManager. Methods in this class send IPC messages to the fxa process; these are handled by the UI_WSM_Impl (in addition to its function of tracking running IGCs and handling swapping). The fxa-side object passes the requests to the various singletons for handling.
Also, the fxa process links with other receivers that are part of other software interfaces (for example, the data management receiver for inventory notifications).
The script monitors the standard output of fxa: as soon as it sees the text "Ready" it knows the fxa has initialized to the point that it's entered the Event Dispatcher loop. Because the IGCs usually haven't yet initialized at this point, the script waits a bit longer before exiting (and thereby removing the splash page).
The file uiProc/fxa.C contains fxa's main function. It registers a signal client with the signal catcher to handle shutdown (SIGTERM, SIGINTR, etc.) and child died (SIG-CHLD) signals. It parses the command line with the user interface library class UIxConnection. It sets the DISPLAY environment variable for future child processes, creates the EventDispatcher and the TiledDisplayWindow, and enters the dispatch loop.
Table of Contents 
Next Chapter