Volume 6A: Motif Programming Manual

A cascading menu

MenuBars, PulldownMenus, and cascading menus are all created in a similar way. Motif provides convenience

functions that create specially configured RowColumn widgets for these menu objects. The RowColumn widget is

then populated with PushButtons, CascadeButtons, ToggleButtons, and Separators, or their gadget equivalents. In the

case of a MenuBar, all of the children must be CascadeButtons, since each button brings up a separate menu. In a

PulldownMenu pane, most of the items are PushButtons or ToggleButtons, although -Separators can be used for

clarity. If an item posts a cascading menu, it must be a CascadeButton. The additional menu is created separately,

populated with its own buttons, and -attached to the CascadeButton.

Motif also supports a construct called an OptionMenu. An OptionMenu is another specially−configured RowColumn

widget, but in this case the behavior is quite different. An OptionMenu is typically used to prompt the user to choose a

value. The RowColumn widget displays a Label and a CascadeButton that shows the current value. When the user

clicks on the button, a menu that contains the rest of the choices is popped up directly on top of the CascadeButton.

Choosing an item from the menu modifies the label of the CascadeButton so that it shows the currently−selected item.

the figure shows an OptionMenu, both before and after it is popped up.

Additionally, Motif provides PopupMenus. Unlike the other types of menus, a PopupMenu is not attached to a visible

interface element. A PopupMenu can be popped up at any arbitrary location in an application, usually as a result of the

user pressing the third mouse button. PopupMenus are meant to provide shortcuts to application functionality, so an

application can use different PopupMenus in different contexts and for different components in an interface.

An OptionMenu

In Motif 1.2, a menu can be torn off from the component that posted it. A menu is normally only displayed for as long

as it takes the user to make a selection. Once the selection is made, the menu is closed. When a menu is torn off, it

remains posted in its own window. Now the user can make as many selections from the menu as she would like

without having to repost the menu each time. For more information on tear−off menu functionality, as well as the

different types of Motif menus, see Chapter 15, Menus.

4.4.3 The Window Manager

To the user, the MainWindow looks like the top−level window of an application. In window−system talk, a top−level

window resides at the top of the window hierarchy for an application. Its parent is the root window, which is what the

4 Overview of the Motif Toolkit 4.4.3 The Window Manager

62

user perceives as the background behind all the windows on the desktop. In the Xt−world, however, things are a little

different. Behind every visible top−level application window is a special kind of widget known as a shell widget.

Every window that can be placed independently on the screen, including top−level windows and dialog boxes, has a

shell widget as its parent. The user does not see the shell because it is obscured by all of the other widgets in the

window. A shell widget can only contain one managed child widget; the shell does not perform any geometry

management except to shrink−wrap itself around this child. The child is typically a manager widget, such as a

MainWindow, that is responsible for managing the layout of the primitive components, such as Labels, Text widgets,

ScrollBars, and PushButtons. The items that the user actually sees and interacts with are descendants of the shell

widget because they are contained within its boundaries.

Aside from managing its single child, the main job of the shell is to communicate with the window manager on behalf

of the application. Without the shell, the application has no idea what else is happening on the desktop. It is very

important for you to understand that the window manager is a separate application from your own. The visual and

physical interaction between an application and the window manager is usually so close that most users cannot tell the

difference between the two, but the distinction is important from a programming perspective.

To get an idea of the relationship between the window manager and an application, let's compare it with the way a bed

is built and how it fits into a room. A bed is made up of a frame, a mattress, and as many accessories as you want to

pile on top of it. The main window is the mattress; the sheets, pillows, blankets, and stuffed animals you throw on it

represent the user−interface controls inside the main window. The whole lot sits on top of the bed frame, which is the

shell widget. When you push a bed around the room, you're really pushing the bed's frame. The rest just happens to go

along with it. The same is true for windows on the screen. The user never moves an application window, she moves

the shell widget using the window manager frame. The application just happens to move with it.

You may have to stretch your imagination a little to visualize a bed resizing itself with its frame, but this is precisely

what happens when the user resizes an application. It is the window manager that the user interacts with during a

resizing operation. The window manager only informs the application about the new size when the user is done

resizing. The window manager tells the shell, the shell communicates the new size to its child, and the change -filters

down to the rest of the widgets in the application.

The window manager frame is composed of window decorations that the window manager places on all top−level

windows. These controls allow the user to interactively move a window, resize it, cause it to redraw itself, or even to

close it. the figure shows the standard Motif window manager (mwm) decorations. For information on how to use

mwm, see Volume Three, X Window System User's Guide, Motif Edition.

4 Overview of the Motif Toolkit 4.4.3 The Window Manager

63

Motif window manager decorations

The window menu displays a list of window manager functions that allow the user to move, resize, and exit the

application. An application does not have access to the menu itself or the items within it; similarly, it cannot get

handles to the minimize and maximize buttons. These objects belong to the window manager and act independently

from an application.

Motif provides window manager protocols that allow menu items like these to affect an application. An application

can also interact with the window manager using many of the same types of protocols. You can specify which of the

items in the window menu you want to appear, whether or not there are resize handles on the window frame, and

whether or not you want to allow the user to iconify the window. However, the user is expecting all of the applications

on her desktop to interact consistently with the window manager. This expectation is magnified by the fact that the

user has probably set quite a few resources for the window manager. Since unexpected interference from an

application rarely makes users happy, you should leave the window manager alone. A technical discussion of the

window manager can be found in Chapter 16, Interacting With the Window Manager.

As we pointed out earlier, it is possible for an application to have more than one independent window. In addition to

the main window, there may be one or more dialog boxes, as well as popup windows, and even independent

application windows that co−exist with the main window. Each of these cases requires different handling by the

window manager, and as a result, there are several different classes of shell widgets. the figure shows the class

hierarchy of the different types of shell widgets available in the Motif toolkit. The Shell widget class is another

metaclass that specifies resources and behaviors inherited by all of its subclasses.

4 Overview of the Motif Toolkit 4.4.3 The Window Manager

64

The Shell widget class hierarchy

In some cases, an application needs to put up a temporary window that is completely free of window manager

interaction. Menus are one such a case. When a user pops up a menu, she typically wants to make a choice

immediately, and she wants that choice to take precedence over any other window system activity. The window

manager does not need to be involved either to decorate or to position the menu, as it is entirely up to the application.

As its name suggests, the OverrideShell widget class is provided for windows that bypass the window manager.

OverrideShells are like futons; you can place them on the floor without using a bed−frame (and without being

tasteless). It doesn't make much sense to use an OverrideShell as the main window for an application, except possibly

for a screen−locking application. The purpose of this type of application is to prevent other applications from

appearing on the screen while the computer is left unattended. Because the window manager is unaware of the

OverrideShell, it does not provide window manager controls, and it does not interpret window manager accelerators

and other methods for bypassing the lock.

The OverrideShell is a generic Xt−based widget class, so the Motif toolkit provides the MenuShell to service the

special interface needs required by the Motif Style Guide. The MenuShell's translation table is set to support keyboard

traversal, its XmNfocusPolicy is set to XmPOINTER, and its XmNallowShellResize resource is set to True.

The MenuShell also makes sure that its child is a RowColumn widget. There is little more to be said about

MenuShells, but for an in−depth discussion on the various types of menus you can use in Motif, see Chapter 15,

Menus. Shell widgets must communicate with the window manager to negotiate screen real estate and a wide variety

of other properties. The information that is exchanged is defined by the X Consortium's Inter−Client Communications

Conventions Manual (ICCCM). The WMShell widget class implements ICCCM−compliant behavior as a standard

part of the X Toolkit Intrinsics, so that it is available to all vendors providing Xt−based widget sets and window

managers. This shell widget is what allows Motif applications to work correctly with virtually any ICCCM−compliant

window manager. In our analogy, a WMShell is a simple, wire bed−frame that doesn't have any special attributes, like

wheels or rollers.

The VendorShell widget class is subclassed from the WMShell class; it allows vendors, such as OSF, to define

attributes that are specific to their own window managers. In our analogy, this widget class is like having a bed frame

that has attached cabinets, shelves above the headboard, or nice wheels that glide on the carpet. The Motif

VendorShell is aware of special features of mwm. The widget does not actually add any functionality to the window

manager, but it is designed for applications that wish to interact with it. For example, all the attributes of window

manager decorations can be modified or controlled through resources specific to the VendorShell.

WMShells and VendorShells are never instantiated directly by an application, but the features they provide are

available to an application. For example, the Motif VendorShell allows an application to specify the items in the

4 Overview of the Motif Toolkit 4.4.3 The Window Manager

65