Motif Programmer's Guide Migration Version

Motif 2.1 Programmer's Guide

A User-Centered Model

A basic principle of Motif and Xt programming is that the user is in charge of the application. Except in unusual circumstances, the program takes action in response to commands or other input from the user. In fact, a typical Motif program spends most of its real time waiting for the user to provide input.

The fundamental object type in a Motif interface is the widget. Some widgets can display output or process input or both; some widgets serve to contain other widgets. A widget is usually associated with a window or a rectangular area of the screen. A widget also has attributes, called resources, which can often be set by the user or the application. An application organizes widgets into one or more hierarchies or trees of parent widgets and their children.

Motif and Xt define a set of widget types or classes. A widget class may be a subclass of another class; in that case it inherits some of the attributes and behavior of the superclass. Motif has three basic classes of widgets:

Primitives are the basic units of input and output. Primitives usually do not have children. Specialized Motif primitives include labels, separators, buttons, scroll bars, lists, and text widgets. Some primitive classes have equivalent objects called gadgets. These are just like primitives except that, to enhance performance, they have no associated windows.

Managers are composite widgets that contain primitives, gadgets, or other managers. Managers are responsible for the geometrical arrangement of their children. They also process and dispatch input to their gadget children. Specialized Motif managers include frames, scrolled and paned windows, menus, constraint-based geometry managers, and several kinds of dialogs.

Shells are widgets whose main purpose is to communicate with the window manager. Most shells have only one child, and they maintain the same size and position as the child. Specialized Motif shells exist to envelop applications, dialogs, and menus.

Defining a widget hierarchy is one of the two main tasks of a Motif application. The other is to define a set of callback procedures. Callbacks are the primary means by which the application responds to user input. When the user takes an action like pressing a key or a mouse button, the X server sends the application an event. Xt dispatches these events to the appropriate widget, usually the one to which the user directed the input. Xt maps the event to one or more widget action routines. The action may change the state of the widget and, if the application has asked to be notified of that action, may "call back" to the program by invoking an application callback procedure.

Many Motif widgets have resources that are lists of callback procedures. Motif invokes a list of callbacks when the user takes an action that has a particular meaning. For example, most buttons have callbacks that Motif invokes when the user activates the button. The user may activate the button in a number of ways, such as by pressing the osfSelect key or the Btn1 mouse button. The events that constitute activation and other meaningful user actions are defined in a general way in the Motif Style Guide and are documented for specific widgets in the Motif Programmer's Reference.

The user action may cause Motif to change to the state and appearance of a widget. For example, when the user presses osfSelect in a PushButton, Motif may make the button appear to be depressed and then released, like a mechanical push button. The action may have other effects depending on the context. For example, Motif has a dialog widget called a FileSelectionBox, used for finding and selecting files. When the user activates the "filter" PushButton in a FileSelectionBox, Motif searches for and displays the names of files that match a pattern displayed elsewhere in the FileSelectionBox.

In general Motif takes care of changing the state and appearance of a widget to correspond to the user's action. By default, though, this action has no effect on the application. The application programmer must interpret the meaning of the action for the application by providing a callback routine, which Motif invokes when the user takes that action. The callback routine may change the state of the application, for example, by changing the value of a variable when the user selects a new value from a Scale widget. The callback may cause the application to take an action. It may also change the state of one or more widgets itself, or it may create an entirely new widget hierarchy.

When both Motif and the application have finished responding to a user action, the application waits for the user to provide more input. Xt provides a routine in which applications spend most of their time. This routine waits for an event, dispatches it to the appropriate widget, and then waits for another event. After initializing the toolkit and creating the initial widget hierarchy, most applications enter this loop and remain there until the user terminates the program.

Motif and Xt provide other ways for applications to direct and respond to events, but for simple programs, virtually the entire interface between the user and the application consists of callback routines.