This appendix gives an overview of the widgets available in the Sun's OPEN LOOK widget set (also known as OLIT, the OPEN LOOK Intrinsics Toolkit) and the OSF/Motif widget set. It gives a sense of the look and feel of applications developed with each set, and provides the inheritance hierarchy and overview of the available widgets.
This section provides an overview and comparison of the widgets in MIT's Athena widget set, Sun's OPEN LOOK widget set (also known as OLIT), and the Open Software Foundation's Motif.[103]
As we've already discussed, the Athena widgets were developed to test and demonstrate the Xt Intrinsics. They are used as the basis for some of the standard MIT clients and many public domain applications, but are not expected to be used for most commercial applications because Xaw is not a complete environment.
A number of vendors have developed proprietary widget sets. For example, Sony Microsystems offers S-windows, a widget set for its News workstations. However, given that one of the purposes of widgets is to provide a common look and feel for X applications, it is natural there should be a shakeout as vendors align themselves with one or two major contenders.
As it has turned out, the two major contenders for a graphical user-interface standard, OPEN LOOK and Motif, are put forth by the two major contenders for an underlying UNIX operating system standard, AT&T and the Open Software Foundation.
It is theoretically possible to write an application that will run under either of these widget sets, using one set of source code interspersed with #ifdef symbols for conditional compilation. This becomes difficult when you use any of the Xt-level features Motif alone provides, however.
OPEN LOOK is somewhat unusual in that it started out not as a set of widgets, but as a user-interface specification. The specification, originally developed by Sun Microsystems with AT&T backing, was widely circulated for comment before any implementations were begun. The objective was to develop a graphical user-interface standard for UNIX workstations--one that would be implementation-independent, and, it was hoped, implemented separately by many different vendors.
At present, the two major implementations of OPEN LOOK are Sun's XView toolkit (which is not based on Xt, but instead provides an application-programmer's interface similar to Sun's proprietary SunView windowing system), and AT&T's OPEN LOOK Xt-based widget set. XView is on the R4 distribution from MIT. Both of these toolkits will be available to all AT&T UNIX System V Release 4 licensees. In our discussions, we are referring specifically to AT&T's OPEN LOOK toolkit, which does not necessarily include every OPEN LOOK feature. Nor should its implementation be considered the only way to provide features called for by OPEN LOOK.
The Open Software Foundation's Motif toolkit is based on a combination of widget sets originally developed by two OSF sponsors, Digital and Hewlett Packard. The look and feel of the widget set was proposed by HP/Microsoft. It is designed to emulate the look and feel of the IBM/Microsoft Presentation Manager standard widely expected to be adopted in the microcomputer world. Motif 1.1 is fully compatible with the MIT Release 4 Intrinsics. Motif 1.2 is fully compatible with the MIT Release 5 Intrinsics. Motif 1.2, released in May 1992, is described here.
Tables A-1 through A-3 compare the widgets available in Athena, AT&T OPEN LOOK set, and Motif.
Simple widgets (mostly controls):
Table A-1. Comparison of Athena, OPEN LOOK, and Motif Widgets
Athena | OPEN LOOK | Motif | Description |
|---|---|---|---|
Command | OblongButton | PushButton | Invokes a command |
-- | -- | DrawnButton | Invokes a command |
Toggle | RectButton | ToggleButton | Chooses a setting |
-- | CheckBox* | CheckBox, RadioBox | Alternate way of choosing a setting |
MenuButton | ButtonStack | CascadeButton | Invokes a menu, displays label |
-- | AbbrevStack | OptionMenu | Invokes a menu, displays default |
-- | -- | ArrowButton | Reverses direction of movement |
-- | ScrollingList* | List | Displays a list of selectable strings |
Scrollbar | Scrollbar | ScrollBar | Scrolls through an associated window |
-- | Slider | Scale* | Sets (or displays) an analog value |
Grip | -- | -- | Resize point for panes in VPaned |
Label | StaticText | Label | Displays a fixed string |
Text | Text | Text | Displays editable text |
-- | TextField | TextField | Displays a single line of editable text |
-- | -- | Separator | Displays a line or other separator |
*CheckBox, ScrollingList, and Scale are technically composite widgets.
Table A-2. Comparison of Athena, OPEN LOOK, and Motif Widgets: Popups (subclasses of shell)
Athena | OPEN LOOK | Motif | Description |
|---|---|---|---|
SimpleMenu | Menu | MenuShell | Parents a popup menu |
-- | Notice | DialogShell | Displays a dialog requiring input |
-- | PopupWindow | MessageBox | Displays a more complex dialog |
-- | Help | MessageBox | Displays a help window |
Table A-3. Comparison of Athena, OPEN LOOK, and Motif Widgets: Composite and Constraint Widgets
Athena | OPEN LOOK | Motif | Description |
|---|---|---|---|
-- | BulletinBoard | BulletinBoard | Free-form placement area |
-- | -- | DrawingArea | Free-form drawing area |
Box | -- | -- | Displays children in order added |
-- | ControlArea | RowColumn | Arranges children in rows or columns |
Form | Form | Form | Manages children relative to each other |
-- | Exclusives | RadioBox | Makes RectButton children exclusive |
-- | Nonexclusives | CheckBox | Makes RectButton children nonexclusive |
-- | FooterPanel | -- | Provides a consistently-sized message area |
-- | -- | Frame | Gives consistent border to enclosed widgets |
-- | ScrollingList* | SelectionBox | Provides a selectable list of strings, plus a text area for entering a new value |
-- | -- | Command | Provides a selectable list of commands |
-- | -- | FileSelectionBox | Provides a selectable list of filenames |
-- | Caption | -- | Displays a label and one child widget |
Viewport | ScrollingWindow | ScrolledWindow | Displays a scrollable child window |
-- | -- | MainWindow | ScrolledWindow with special appearance |
VPaned | -- | PanedWindow | Displays panes resizable in one direction |
|
|
|
|
*Checkbox, ScrollingList, and Scale are technically composite widgets.0
Comparable widgets share a line in the table. Widgets for which no equivalent occurs in a given set are indicated by a hyphen in the appropriate column. Note that comparisons are approximate only, since widgets have complex behavior that may distinguish them significantly from another widget with an ostensibly similar purpose.
The following sections provide an overview of the widgets available in the OPEN LOOK and Motif widget sets. Throughout, we contrast them with the Athena widgets, which have been used as examples in this book, to give you an idea of the additional features provided by the commercial widget sets.
Keep in mind that the look and feel of an application is controlled by the window manager as well as by the widget set. Both AT&T and OSF supply window managers to complement their widgets.
Note that both widget sets make additions to the basic X Toolkit API. In the AT&T OPEN LOOK widget set, these API additions are rather minor. There is one essential function, OlInitialize, which sets initial values needed by other routines and by certain widgets. OlInitialize creates a base window, which from the programmer's point of view is identical to the Intrinsics-supplied TopLevelShell widget class, but which automatically handles certain features of the OPEN LOOK interface. There are also several convenience functions, mostly having to do with conversions between pixel sizes and various standard units. More importantly, there is a facility for registering help screens for each element in an application.
In addition, Motif makes heavy use of convenience functions. Rather than using XtCreateManagedWidget() to create each widget, there is a separate creation routine for each widget. In some cases, a convenience routine creates more than one widget. Rather than using separate calls to XtCreatePopupShell() and XtCreateManagedWidget() to create a popup shell and the dialog box it displays, you might call a function such as XmCreateMessageDialog() to create both widgets at once. Some convenience routines create special configurations of a single, complex widget (e.g., a composite widget with specific children.)
In Motif, all resources are referred to by names beginning with XmN or XmC rather than the familiar XtN and XtC.
Motif also uses the call_data argument of callback functions extensively. Almost every widget has a structure defined as widgetclassCallbackStruct (e.g., XmToggleButtonCallbackStruct). This struct contains different fields for each widget, but each contains a field called reason. The reason field defines which callback has been called. So using this feature allows you to have a single piece of code to handle all callbacks for a widget.
Both Motif and OPEN LOOK offer clear advantages over Xaw. Unfortunately, however, the choice of which one to use may depend on company marketing goals and politics rather than on clear technical merit. We encourage independent developers to try both and to base your opinions on the ease of programming and the preferences of your users, rather than on marketing hype by one side or the other. Both Motif and OPEN LOOK come with their own window manager and have defined their own protocols for communication between their Shell widgets and their window manager. By setting resources of Shell widgets you can control some aspects of how these window managers will handle your application.
Figure A-1 shows the overall look and feel of an OPEN LOOK application.
The base window of an application always has these elements:
A title bar, or header, with a title supplied by the application centered in the bar. The title might be the application name, or the name of a file being edited. If the application doesn't provide a title, the title bar displays the string “Untitled.”
A “window mark” on the left side of the title bar. If the user clicks on this mark with the first (leftmost) pointer button, the window closes.
A window menu that comes up automatically when you click on the title bar with the third (rightmost) pointer button.
One or more panes for input and display of application data.
One or more control areas, containing buttons that invoke application actions or menus containing additional actions. Control areas can be horizontal, vertical, or both.
Optional elements include resize corners (which allow the user to resize the application by dragging them with the first pointer button), horizontal and/or vertical scrollbars, and a footer area for displaying messages.
Some of these elements do not correspond to widgets, but are produced by the OPEN LOOK window manager, olwm, as window decoration. For example, the header, including title bar, window mark and window menu, are provided by the window manager, as are the optional resize corners. However, control areas, panes, scrollbars, and the footer area do correspond to particular widgets.
In addition to base windows, applications may have several kinds of popup. Both pulldown and pure popup menus are supported, as well as several standard kinds of notices and dialogs. Probably OPEN LOOK's best-known feature is the “pushpin” metaphor that allows frequently-accessed popup menus to be kept on the screen rather than hidden again after they have been used.
The following sections discuss some of the widgets AT&T has provided to support the OPEN LOOK user interface. Figure A-2 shows the overall widget inheritance hierarchy.
Note that there are a number of widgets that are never instantiated by the application programmer, but are used by other widgets. For example, the checkbox is actually a composite widget that manages a check widget as its child! The Pushpin used in popups and the Magnifier used in Help windows (and the Help window itself) are examples of other widgets that are not instantiated directly.
Most applications will have at least one control area, with pointer-selectable buttons that invoke commands or menus, or choose settings.
One of the areas where OPEN LOOK clearly stands out over the Athena widgets is in the rich set of controls it provides. Athena has one kind of Command widget; OPEN LOOK has six.
The Athena Command widget implements one of the most basic user-interface idioms--a button that invokes an action when you click on it with the pointer. The Athena widgets include a subclass of Command, the MenuButton widget, which includes code for placing a popup menu.
The OPEN LOOK widget set implements similar functions using the OblongButton and ButtonStack widgets. Figure A-3 shows a Control Area containing OblongButton and ButtonStack widgets.
The OblongButton widget provides many niceties lacking from the Athena Command widget. One of the most important is that OblongButton has a resource that allows one button among several to be designated as the default, in which case the button is bordered by a double line, to give the user immediate visual feedback about which button to choose when several are available.
The OblongButton also has the notion of a “busy” state in which it cannot perform the action because it is already doing it. (This is different from a widget that is insensitive (meaning its function is unavailable), though in practice the effect is quite similar.) The label and border of an insensitive button are dimmed; the background of a busy button is filled with a stippled pattern.
The ButtonStack widget is similar to the OblongButton but invokes a menu rather than a single command. Clicking on it with one mouse button (usually Button 3) pops up a menu (which may in turn include other ButtonStack widgets, for cascading popups.) Clicking on the ButtonStack with another mouse button (usually Button 1) activates the default item for the menu. Visually, a ButtonStack is differentiated from an OblongButton by the presence of an arrowhead that points in the direction that the menu will pop up.[104]
In addition, there is an AbbrevStack widget, which performs similar functions as the ButtonStack widget, but shows up only as a small unlabelled box with the default choice for the menu displayed beside it.
The Athena Toggle widget provides the concept of a button that establishes a setting (for example, sets an application resource) instead of performing an action. It highlights itself when selected, but remains highlighted until selected again. However, in the Athena Widget set, there is no visual distinction between a Command widget and a Toggle widget.
OPEN LOOK provides such a distinction. In contrast to OblongButton, which always indicates that an action will be performed, a RectButton indicates that an option setting will be chosen. This setting may be exclusive or nonexclusive, as determined by the RectButton widget itself, depending on whether the widget is managed by an Exclusives, or Nonexclusives composite widget. The RectButton widget class will not work correctly unless managed by one of these two composite widgets. The Exclusives and Nonexclusives widgets are themselves usually children of a Menu or ControlArea widget.
In an Exclusives widget, RectButton widgets are laid out side by side in one or more columns. One or none of the RectButton widgets is chosen as the default, which is indicated by a double border. Once a RectButton is selected, it is shown with a dark border. The Exclusives widget makes sure that no more than one RectButton is selected at a time.
In a Nonexclusives widget, RectButtons are displayed with separation between each button. As when used in an Exclusives widget, a dark border indicates that the option has been chosen. However, more than one button may be chosen at a time.
Figure A-4 shows examples of exclusive and nonexclusive settings on menus. Note that, like the OblongButton, a RectButton may display a pixmap instead of a label. This makes the RectButton useful for a palette in a paint program.
The CheckBox widget provides an alternate way to display nonexclusive settings to the user. It displays a small box next to the label and displays a checkmark in the box when the option is selected. Checkboxes appear in ControlAreas rather than on menus. Figure A-5 shows examples of CheckBox widgets.
In addition to the various kinds of buttons outlined above, OPEN LOOK provides an analog control called a Slider. A Slider widget is used analogously to a Scrollbar but is used for setting a numeric value. Figure A-6 shows a Slider widget.
Composite widgets are in many ways the most important widgets in any widget set. They define the way that widgets work together, and they give consistency to an application.
As we've already discussed, command buttons of any kind are usually displayed as part of a menu or control area.
Menus can either pop up below a ButtonStack or an AbbrevStack, or if the button is itself displayed on a menu, to the right, in a menu cascade. Figure A-4 showed examples of menus.
The Menu widget is a popup widget created with XtCreatePopupShell(). It has a single child, which is a ControlArea widget.
The ControlArea widget places its children in rows or columns. Resources allow the application to specify a fixed width and/or height, or a fixed number of rows or columns. ControlArea widgets are usually used as the parent of OblongButton, ButtonStack, Exclusives, or Nonexclusives widgets (which in turn manage RectButton widgets, as described in the next section).
We've already discussed the Composite widgets relating to control areas and menus. However, there are several general-purpose composite widgets in the OPEN LOOK set as well.
The BulletinBoard widget provides a free-form area for placing subwindows. Widgets can be placed on a BulletinBoard at arbitrary x and y coordinates; if no coordinates are specified, they appear in the upper left corner. The BulletinBoard provides no management of its children, and is often used to establish the base frame for an application, since it allows the application programmer to place the major components of the application, rather than having to go by some Composite widget's arbitrary placement decisions.
A BulletinBoard is often used as the main window of an application.
The Form widget is a constraint widget similar to the Athena Form widget. It allows the placement of widgets to be specified relative to each other, and with rules governing their separation or relative position.
The Caption widget is like an Athena Label widget turned inside out. Like the Label widget, it prints a string. However, while the label widget's string is printed inside a visible widget border, a Caption string appears outside a bordered area. Caption is a composite widget class, and its label typically refers to a child widget of any size, which the Caption widget manages. The label can be aligned on either the right, left, top or bottom of the child widget.
The FooterPanel widget provides a consistent method for placing a footer along the bottom of another window. The footer panel takes two children. The top child is typically the main composite widget of the application; the bottom widget may contain a control or message area. The basic feature of the FooterPanel widget is that when the widget is resized, it applies all the change in the vertical direction to the top child, maintaining the bottom child at a constant height.
OPEN LOOK scrollbars use the visual metaphor of an elevator on a cable, but functionally they are similar to the Athena Scrollbar widget. The drag area (the thumb in an Athena Scrollbar widget) doesn't change size; instead, as shown in Figure A-7, there is a separate area that indicates the proportion of the data that is currently being displayed.
Scrollbars may be oriented either horizontally or vertically.
Scrollbars are used as a component of a ScrolledWindow widget, which, like the Athena Viewport widget, provides a scrollable view of a data area in a child widget. The child widget is typically larger than the view area, but only the area in the parent's view area can be seen at any one time. Figure A-1 showed a ScrolledWindow widget as the main application pane. The ScrollingList widget displays a scrollable list of editable text fields, and provides facilities for choosing and displaying one of the fields as “currently selected.” Items can be selected from the list, changed, copied, and so on. This widget is useful for providing an interface to select a file for reading or writing.
Figure A-8 shows a ScrollingList widget.
In addition to Menu widgets, the OPEN LOOK widget set contains three other special types of popup widgets: Notices, PopupWindows, and Help windows. A Notice is used to request confirmation or other information from the user. The widget contains a text area, where the message to the user is displayed, and a control area containing one or more buttons, one of which must be the default button.
Figure A-9 shows an OPEN LOOK Notice widget.
A Notice grabs the pointer. The only input allowed is to the Notice. Once the user has clicked a button, the Notice disappears.
The second special popup type is a PopupWindow, which can be used for more complex popups. Unlike a Notice, which is a subclass of OverrideShell, a PopupWindowShell is a subclass of WMShell, and so is decorated by the window manager. It has all the visual attributes of a top-level window, including resize corners, etc. In addition, it displays a pushpin in the upper left corner. If the user clicks on the pushpin with the pointer, the menu doesn't go away when its action has been performed, but stays on the screen. This allows the user to keep menus (and other frequently-referenced popups, such as help screens) “pinned” on the display, where they can be moved like regular windows. (Menus can also display a pushpin; its presence or absence is controlled by a widget resource.)
A PopupWindow typically contains an upper control area that may include menus, and a lower control area that may be used for buttons invoking widget actions. Resources allow for automatic creation of several buttons, including a “reset to factory” button, a “set defaults” button, and several other ways of setting standard properties for an application.
Figure A-10 shows a PopupWindow.
A Help window is not instantiated in the usual way. Instead, an application uses the OlRegisterHelp function to register help text with the toolkit. Text can be associated with a widget class, a widget instance, or a window. When the user clicks the second pointer button on an object, the Help widget is automatically displayed by the toolkit. The Help widget includes a Magnifier subwidget, which displays a magnifying glass containing an image of the part of the screen on which the user clicked the pointer. Figure A-11 shows a Help window.
OPEN LOOK offers three separate text widgets. The StaticText widget is similar to the Athena Label widget in that it displays a fixed text string. However, it can handle longer strings by using wordwrapping to break the string onto multiple lines.
The OPEN LOOK Text widget is very similar to the Athena Text widget. It provides a general-purpose editable text widget, with editing commands customizable via a translation table.
One of the annoying weaknesses of the Athena Text widget is that it is difficult and inefficient to use as a single-line editable field. (A program can add translations for the Return key to limit the text to a single line.) OPEN LOOK addresses this need with the TextField widget, useful for developing form-driven applications. TextField widgets were shown in Figure A-11.
The TextField widget provides simple editing commands, and scrolling if the string is too long to be displayed. When the keyboard focus leaves the widget, or when the Tab or Return key is pressed, it passes the data in the field to the application for validation.
Like the Athena widget set, the AT&T OPEN LOOK widgets provide no widget explicitly labeled as a drawing area. As described in this book, one is expected either to create a custom widget for an application's main window, or to use a very basic widget class, and add actions for drawing.
The AT&T OPEN LOOK widget set does include a Stub widget class (which is not documented in the manual, but is included in the source), which is useful for providing a window for drawing.
Figure A-12 shows the general look of a Motif application, the Motif Reference Editor, mre. mre, developed by Mitch Trachtenberg, was OSF demo software in Motif 1.1, but is no longer provided in the Motif distribution.
As with the AT&T OPEN LOOK widget set, some of the features of a main application window are actually decoration provided by the window manager, mwm. As shown in Figure A-11, these include the title bar, which displays:
The title provided by the application.
A Menu button, which drops down a menu containing basic window manipulation commands.
A “Minimize” button, which iconifies the application.
A “Maximize” button, which causes the application window to fill the entire screen.
You will also recognize Motif's version of many of the common controls discussed in the section on the AT&T OPEN LOOK widget set.
Figure A-13 shows the inheritance hierarchy of the Motif widgets. The Intrinsics-supplied widget classes are shaded grey.
The Primitive and Manager widgets are not generally instantiated and exist only to provide resources and other features inherited by other widgets.
In addition, Motif supports a Gadget class, which, as described in Chapter 13, Menus, Gadgets, and Cascaded Popups, is subclassed from RectObj rather than Core. Gadget equivalents exist for the Label widget, some classes of Button widgets, and the Separator widget. Gadgets are not shown in Figure A-13.
Like OPEN LOOK, Motif has a much richer set of application controls than Athena.
Motif's PushButton is equivalent to Athena's Command widget and OPEN LOOK's OblongButton. It has a 3-D appearance and seems to be depressed when clicked on. It invokes separate callbacks for button up, button down, and button click, much like the equivalent widgets in other sets.
The DrawnButton works similarly, but allows the programmer to provide a pixmap for the appearance of the button.
Figure A-14 shows a DrawnButton and a PushButton.
The CascadeButton is similar in effect to OPEN LOOK's ButtonStack--it can have a particular appearance that indicates that a menu is invoked, rather than a single callback. Typically, this is simply an arrow pointing in the direction where the menu will appear.
A ToggleButton is used for option setting, much like OPEN LOOK's RectButton or CheckBox. Figure A-16 shows a box containing a set of ToggleButtons.
The Separator widget can be used to draw a line or other separator between a group of widgets in a menu or other box. It is typically used in menus.
The List widget displays a list of strings set by the application and allows the user to select one or more of the strings. The selected data is passed to a callback function. (We'll talk more about this widget in the section on scrolling.)
As with OPEN LOOK, we've divided the discussion of Composite widgets into three areas: Menus and Control Areas, General-Purpose Composite Widgets, and Scrollable Windows. These distinctions are somewhat arbitrary and with menus the sections overlap with the one on popups, which appears later.
Motif provides a special Shell widget class called MenuShell for managing popup menus. However, most actual menu displays are managed by the RowColumn composite widget, which, like OPEN LOOK's ControlArea, displays buttons in rows or columns.
Through resources, the RowColumn widget can be configured to create such specialized, predefined elements as a MenuBar (which can only accept CascadeButton widgets as children), several different styles of pulldown or popup menu panes, and several preconfigured control areas, such as a “Radio Box” containing multiple exclusive ToggleButton gadgets.
Here you can begin to see the wide divergence in programming style made possible by the Xt Intrinsics. It is possible to create a hierarchy of relatively simple widgets to perform separate parts of a task, or a single, very complex widget which is highly configurable. In one of its incarnations, the RowColumn widget is equivalent to an OPEN LOOK ControlArea plus an Exclusives widget; in another, a ControlArea plus a Nonexclusives.
In general, Motif widgets are more complex and have many more resources than widgets provided in other widget sets. To simplify their use, though, Motif provides numerous convenience functions. For example, XmCreateRadioBox() will create a RowColumn widget with one specialized set of resources, while XmCreateMenuBar() will create one that is entirely different in appearance and function.
Figure A-15 shows a RowColumn widget configured as a MenuBar and Figure A-16 shows one configured as a RadioBox (each with appropriate children).
Figure A-17 shows a RowColumn widget implementing a pulldown menu.
Items on Motif menus can be selected by dragging the pointer down the menu and releasing it when the chosen item is highlighted. Alternately, the pointer can simply be clicked on the menu title to drop down the menu. Clicking on an item in the menu selects it; clicking anywhere other than in the menu pops the menu down without executing any item.
Note also that as a general feature, Motif menus support accelerators. That is, there are keyboard equivalents for every menu item. These keyboard accelerators are listed after the menu label, as shown above. In addition, typing the underlined letter in any menu item label when the pointer is in the menu will select that menu item. These underlined letters are called “mnemonics.”
The items on a menubar or menu pane simply appear as labels but when selected take on the 3-D appearance of a PushButton.
The BulletinBoard widget provides simple composite management, allowing widgets to be placed arbitrarily anywhere within its confines. The only constraint is that they are not allowed to overlap.
The Form widget is a subclass of BulletinBoard that, like the widgets of the same name in other sets, allows children to be laid out relative to each other or to one or another of the sides of the Form. The children will thus always maintain their proper relative position when the application is resized.
Figure A-18 shows a fully configured Form.
The Frame widget is used simply to provide a consistent border for widgets that might not otherwise have one. One use is to give a RowColumn widget a border with a 3-D appearance.
A Motif ScrollBar is illustrated in Figure A-19.
Like the Athena Scrollbar widget, the scrollbar has a “thumb” or slider that can be dragged up and down to scroll the associated window. You can also click above or below the thumb to move it a screenful at a time. Unlike the Athena widget, it also displays arrows at either end that can be used to scroll line by line. The associated window scrolls in the indicated direction as long as the pointer button is held down in one of the arrows.
There are several different types of scrolling windows. The ScrolledWindow widget, like Athena's Viewport, provides a general mechanism for attaching scrollbars to some other window.
The MainWindow widget is a subclass of ScrolledWindow with a special appearance reserved for application main windows. Figure A-14 showed a MainWindow widget.
Using the XmCreateScrolledList() function, a List widget can be created as a child of a ScrolledWindow, giving the effect of a simple scrolled list. In addition, there are several flavors of more complex scrolling lists. These include the SelectionBox widget, and its two subclasses, Command and FileSelectionBox.
A general-purpose SelectionBox is akin to a ScrolledWindow/List combination, but adds a Text widget for entering additional data not on the list. The SelectionBox also adds at least three buttons labeled by default OK, Cancel, and Help.
Figure A-20 shows a SelectionBox.
A FileSelectionBox is a SelectionBox specially designed to present a list of filenames for selections. A Command widget is a special kind of SelectionBox whose list consists of the history of commands entered in the Text widget. Each time a new command is entered, it is added to the history list.
Motif defines two classes of Shell widgets: DialogShell, which is used for parenting Dialog boxes, and MenuShell, which is used for menus. These classes are rarely instantiated directly, but are instead created by convenience functions that also create their composite children.
For example, functions exist to create a DialogShell with a variety of pre-configured MessageBox widgets as the visible child.
As we've already discussed, a specially configured RowColumn widget is used to create a menu pane as the visible child of a MenuShell widget.
Like Athena and the AT&T OPEN LOOK widgets, Motif provides a Text widget that supports a complete editing command set. Like Athena, and unlike AT&T's OPEN LOOK widget set, both single- and multiline editing is supported by a single widget. But arranging for single-line editing is easier with Motif than with Athena.
As you may recall, to do drawing in the Athena widgets we either created a custom widget or instantiated a Core widget in order to obtain a window for drawing. The Motif DrawingArea widget class answers this need in Motif. It provides a window for drawing and provides very simple, bulletin-board like composite management of children.
Though the name of this widget class sounds promising, you should be aware that Motif really provides no more sophisticated drawing capabilities than Athena or the AT&T OPEN LOOK widget set. In each case, once you have selected the widget to draw on, you simply draw in its window using Xlib calls.
[103] OPEN LOOK is a registered trademark of AT&T and Motif is a registered trademark of Open Software Foundation, Inc.
[104] In an earlier implementation of the toolkit, a ButtonStack widget had a double border on its bottom half, giving it the appearance of a stack of regular buttons. Hence its name, which is now merely historical.