Volume 6A: Motif Programming Manual

window menu and to control what happens when the user closes the window from the window menu. Chapter 16,

Interacting With the Window Manager, discusses window manager interactions in more detail. You can think of

dialog boxes as an application's secondary windows. Since dialogs are not meant to remain on the screen for very

long, they do not need all of the decorations that are typically provided by the window manager. However, dialogs are

not completely independent like menus, so they do need to be controlled by the window manager. For example, if an

application is iconified, its dialog boxes are typically iconified as well. Dialog boxes are usually implemented in Xt

using TransientShells.

The DialogShell is a Motif−defined widget class subclassed from the TransientShell and VendorShell classes. Motif

functions for creating dialog boxes tend to hide the shell widget side of the dialog. When you make a call like

XmCreateMessageDialog(), you are actually creating a MessageBox widget as a child of a DialogShell widget.

See Chapter 5, Introduction to Dialogs, for details on Motif dialogs. When you initialize the X Toolkit with a call

such as XtAppInitialize(), you are automatically returned an ApplicationShell widget to use as the top−level

widget in your application. If an application uses additional top−level windows, they are typically TopLevelShells.

The differences between these two classes are subtle and deal mostly with how resources are specified in a resource

file. In Chapter 7, Custom Dialogs, we explore some ways in which TopLevelShells can be used as primary windows

apart from the main window.

4.4.4 Dialogs

Some applications can get all their work done in one main window. Others may require multiple windows, so Motif

allows an application to have multiple top−level windows. However, even applications without this level of

complexity need to display transient windows called dialog boxes. Motif provides two main types of dialog boxes:

message dialogs and selection dialogs. Message dialogs are designed to allow an application to communicate with the

user, while selection dialogs prompt the user to enter different types of information. It is also possible to create custom

dialogs for specialized application functionality. Message dialogs simply communicate some kind of message to the

user and include buttons that allow the user to respond to the message. For example, a menu item to delete a file might

issue a dialog with the message, "Are you sure?" with PushButtons labeled Yes, No, and Cancel.

The Motif MessageBox widget that is used to create message dialogs actually comes in seven different guises. The

different styles are meant to be used for different types of messages; some of the styles also display a symbol defined

by the Motif Style Guide. Motif provides convenience routines for creating all of the different styles, so they are often

referred to as if they are distinct widget classes.

ErrorDialog

The ErrorDialog shows a "do not enter" symbol along with a message that the user has made an error. For

example, she may have pressed a PushButton at the wrong time, made an invalid selection in a List widget, or

entered an unknown filename for a Text widget.

InformationDialog

The InformationDialog displays an "i" along with an informational message. These dialogs are usually

displayed in response to a request for help.

MessageDialog

The MessageDialog does not display a symbol by default, although a symbol can be specified using the

XmNsymbolPixmap resource. These dialogs can be used to display any kind of message.

QuestionDialog

The QuestionDialog shows a question mark symbol with a question that the user needs to answer. Questions

are typically of the yes/no form, so the possible answers typically include Yes and No. A QuestionDialog

4 Overview of the Motif Toolkit 4.4.4 Dialogs

66

should not be used for a question that requires an answer in the form of text or a selection from a list of some

kind.

TemplateDialog

Motif 1.2 provides a TemplateDialog to allow an application to create a custom dialog. By default, the

TemplateDialog does not display a symbol or a message, but these items can be added to the dialog.

WarningDialog

The WarningDialog displays an exclamation mark along with a message that warns the user about a particular

situation. These dialogs are commonly used to make sure that the user wants to do something destructive, like

delete a file or exit an application without saving data.

WorkingDialog

The WorkingDialog displays an hourglass with a message indicating that the application is busy processing a

lengthy computation or anything else that requires the user to wait.

the figure shows a typical QuestionDialog in an application. For more information on message dialogs, see

Chapter 5, Introduction to Dialogs.

A QuestionDialog

Selection dialogs are meant to provide the user with a list of choices of some sort. Motif -provides different

styles of selection dialogs for different purposes. For example, a SelectionDialog presents a ScrolledList

containing an arbitrary list of choices that can be selected with the mouse. The dialog also contains a

TextField widget that can be used to type in a choice which may or may not also be on the list. the figure

shows a SelectionDialog.

The PromptDialog, as shown in the figure, is useful for prompting the user to enter some information.

4 Overview of the Motif Toolkit 4.4.4 Dialogs

67

A SelectionDialog

A PromptDialog

The FileSelectionDialog is a more complex cousin to the SelectionDialog. It is used to select a file in the

directory structure. A FileSelectionDialog is shown in the figure.

4 Overview of the Motif Toolkit 4.4.4 Dialogs

68

A FileSelectionDialog

The CommandDialog is an extension of the PromptDialog in that items input to the text entry field are stored

in a ScrolledList. The intent is for the user to provide the application with commands; the list region contains

a history of the commands that have already been typed. The user can select an item in the history list to

reissue a previous command. the figure shows an example of a CommandDialog.

A CommandDialog

For detailed information about all of the different Motif selection dialogs, see Chapter 6, Selection Dialogs.

There are many types of functionality that are not covered by the standard Motif dialog types. Fortunately, it

4 Overview of the Motif Toolkit 4.4.4 Dialogs

69

is fairly easy to create your own dialogs. If you need to create a custom dialog, there are some guidelines in

the Motif Style Guide that you should follow. At the highest level, all dialogs are broken down into two major

components: the control area (or work area) and the action area. These areas are conceptual regions that may

be represented by multiple widgets.

In a message dialog, the control area is used only to display messages, but as you can see from the selection

dialogs, this area can be used to provide a variety of control elements. For example, the SelectionDialog uses

a List widget and a TextField widget. It is also common for a custom dialog to display an array of

PushButtons or ToggleButtons. A communications program might have a setup dialog that allows the user to

set parameters such as baud rate, parity, start and stop bits, and so on, using an array of ToggleButtons. The

controls in the control area provide information that is used by the application once an action area button is

pressed.

the figure shows a custom dialog with a control area that contains many items. Chapter 7, Custom Dialogs,

discusses how to build customized dialogs, which may require the direct creation of widgets in the control

area. Motif dialogs, on the other hand, do not require you to create any of the objects in the control area. The

widgets displayed in that part of the dialog are always predefined and automatically created. One important

concept to be aware of when it comes to dialogs is modality. In general, GUI−based programs are expected to

be modeless. What this ultimately means is that the user, not the application, should be in control. The user

should be able to choose from an array of application functions at any time, rather than stepping through them

in a prearranged sequence, under the application's control.

Of course, there are limits to modelessness. Sometimes one thing has to happen before another. Often,

sequencing can be taken care of simply by nesting graphical user interface elements. For example, faced with

the main window, the user may have only a choice of menu titles; once she pulls down the file menu, she may

have a choice of opening, closing, saving, renaming, or printing the contents of a file. At some point, though,

she goes far enough down a particular path that her choices need to be constrained.

With respect to dialogs, modality allows a dialog box to require and before the user can go back to working

with the application. For example, if the user asks to load a file, she may need to specify a filename in a dialog

before she can edit the file. A modal dialog requires an answer immediately, by disallowing input to any other

part of the application until it is either satisfied or cancelled. There may be other cases, though, where dialogs

are modeless. They can be left up on the screen without an immediate response, while the user interacts with

the main application window or another dialog.

4 Overview of the Motif Toolkit 4.4.4 Dialogs

70