[ Previous | Next | Contents | Glossary | Home | Search ]
Motif 2.1 Programmer's Guide

Chapter 13. Input, Focus, and Keyboard Navigation

The X server communicates with clients by means of various classes of events. Among these are events denoting input from the keyboard and mouse (and, in some X extensions, input from other devices). Each event is associated with a window, and the X server sends the event to any client that has expressed interest in events of that type on that window.

In the simplest case, when a keyboard or pointer event occurs, the X server sends the event to the client that has expressed interest in events of that type on the window that contains the pointer. If no such client exists, the server searches up the window's hierarchy until it finds a client that has expressed interest in events of that type on an ancestor window. In many cases, however, event processing is more complex:

  1. A client can grab a pointer button or key, the pointer or keyboard, or the entire server. The grabbing client then receives the relevant events for the duration of the grab.

  2. A client can set the keyboard focus to some window. Keyboard events that would normally be reported to this window or one of its inferiors are reported as usual, but other events are reported with respect to the focus window. Window managers typically use this technique to implement a "click-to-type" interaction style, in which the user clicks the pointer on some window, and that window retains the keyboard focus regardless of the position of the pointer. Other clients, often in cooperation with the window manager, can set the focus to a particular window within the application hierarchy.

    To insulate applications from the complexities of X event handling, Xt and Motif have developed higher-level facilities based on widgets:

    1. Motif supplies a VendorShell resource, XmNkeyboardFocusPolicy, to allow a user or application to control the model of keyboard focus in the VendorShell and its descendants. Keyboard focus can be with the widget the contains the pointer or with the widget in which the user presses Btn1.

    2. In the click-to-type model, the user can also use keys to navigate from widget to widget. Motif provides a model of tab groups, which are widgets or sets of widgets to which the user moves by using osfNextField and osfPrevField. Within a tab group, the user traverses between widgets by using osfUp, osfDown, osfLeft, and osfRight. Motif supplies resources to control whether or not a widget constitutes a tab group and whether or not the user can traverse to it using the keyboard. Motif also has a general routine, XmProcessTraversal, for use by the application in moving keyboard focus to a widget or tab group. The Motif menu system has a specialized traversal mechanism.

    3. Xt provides the basic event-dispatching loop used by most applications. Xt takes events out of the application's queue and dispatches them to the appropriate widget, usually the widget that has input focus. Xt usually invokes an action associated with the particular event through a table of translations from event specifications to action routines. The action, in turn, often invokes a callback list. An application primarily responds to events by means of its callback routines. At a lower level, it can also provide its own event handler, a routine invoked by the Xt dispatching loop when the widget receives events of the specified type.

    4. Motif and Xt provide mnemonics and accelerators, which are shortcuts for taking actions associated with a widget when the widget does not have input focus. A mnemonic is a keysym for a key that activates a visible button in a menu. An accelerator is a description for an event that invokes an action routine through a translation.

    5. [ Previous | Next | Contents | Glossary | Home | Search ]