6.2 OSF/Motif in X-Windows -- Toolboxes in the Trenches

The X-Windows system is a software product that allows programs to be run on computer networks, with the interaction taking place at the user's machine while the main program is running on some other computer. In this approach, the user's local system is called the SERVER, responding to the interface-related needs of the CLIENT program on the remote machine. The user's machine typically has less power than the client that's running the main program. It may even be an "X Terminal," a mouse/monitor/keyboard unit with just enough computing power to buffer i/o and rapidly display graphics. X-Windows was originally developed for academic networking as part of MIT's project Athena, but it has since been adopted as a standard by several major computer manufacturers.

Motif was developed by the Open Software Foundation (OSF) as a standard graphical user interface substrate for X-Windows. Motif consists of a library of C language subroutines that define a toolbox of interface objects and techniques for combining them into a program. The toolbox allows a programmer to create programs that are event-driven, object- oriented, and adaptable through on external resource files. There are full-featured UIMS packages for X-Windows, such as the Garnet system that was discussed in Chapter 3. However, many programmers choose to use the Motif toolkit within their standard C programming environment. We describe that approach in this section to provide a baseline for appreciating more sophisticated approaches. It's not an approach we recommend.

All the graphical objects in Motif are referred to as WIDGETS, which are defined as an object-oriented hierarchy. A typical class in the hierarchy is labels, which has buttons as a subclass, which in turn has individual buttons as instances. The options for each class and instance, such as color, text string, and behavior, are specified as resources in the program's resource database. The database itself is created at program startup by reading in a series of text files that describe the program, the hardware, and the user's preferences.

Widgets within a program are also arranged hierarchically, but in a different sense: The main window of the program is the top widget of the hierarchy, a menu within it is at the next level, and buttons within that window are at the next. Many of the parameters at lower levels are inherited or calculated from the higher levels. Dragging the window changes its location parameters, for example, and this change propagates through the hierarchy to the controls within the window.

The runtime behavior of a Motif program is event-driven, controlled by an event loop that is supplied as part of the toolkit. The system watches for events such as mouse-clicks, cursors moving in or out of windows, and keystrokes. When an event occurs in a widget, the system checks the translation table, a part of the widget's resource list that tells what action to take, if any. Like most other things in the resource database, the translation table can be changed by the program as it runs. This allows the behavior of a control to reflect the current situation. If the translation table indicates that some action is to be taken, the system generates a "callback" to the client program, telling it what needs to be done.

Writing a Motif program is like writing a typical C program, with some additions. You might start by writing a module that defines the program's basic functions, such as search and sort for a database. This can be compiled and debugged independently with a simple command-line interface. The Motif interface code can be written as a separate module.

One part of the Motif code you'll need to create will be the resource files that define all the initial parameters of the on-screen objects. Since this isn't a visual programming environment, each parameter has to be specified textually. The label class of widget has about 45 parameters that can be specified in the resource file. Specifying the controls this way is time-consuming, but it's not as bad as it sounds. A class's parameters are inherited by objects below it, so only parameters unique to a class or instance need to be specified. Also, consistency among similar items can be achieved by using wildcard specifications. For example, the resource specification:

     hello-world.controls.quitButton.XmNhighlightColor:blue

sets the highlight color field for a single widget in the "controls" module of the "hello-world" program. The specification:

     hello-world.main*XmNhighlightColor:blue

sets the same parameter for all widgets in the module.

In addition to the resource files, you might employ the Motif User Interface Language (UIL -- like it or not, it seems that any three-word phrase in programming documentation gets reduced to an acronym). The UIL approach allows the programmer to redefine the widget hierarchy external to the compiled C program, something that can't be done with the resource files.

After defining the resources, you'll have to write the C program that will become the heart of the system. This code will start with header information that references the standard Motif files, including at least 30 libraries of standard widget classes. It will also define the callback procedures that link interface actions to the functions defined in the main module. Then it will specify a series of actions necessary to get the program running: initialize the Motif toolkit, open a network connection to the server, define a top-level widget for the hierarchy, read specifications from the database and define all the widgets in the window, and then display all the widgets. Finally, the code will turn control over to an event loop, supplied as one of the Motif toolbox routines. To produce a simple "hello world" program you might have to write on the order of 100 lines of C code.