The OSF/Motif Style Guide provides a framework of behavior specifications to guide application developers, widget developers, user interface system developers, and window manager developers in the design and implementation of new products consistent with the OSF/Motif[tm] user interface. This OSF/Motif Style Guide is also closely consistent with Microsoft Windows, Presentation Manager, and Common User Access (CUA).
The OSF/Motif Style Guide establishes a consistent behavior among new products by drawing out the common elements from a variety of current behavioral models. The OSF/Motif Style Guide anticipates the evolution of graphical user interfaces as new technology becomes available and as the use of the Motif[tm] user interface spreads. Behavioral guidelines will be added over time as they become stable.
For specific details of coding the implementation into an application program, widget, or window manager, see the other volumes of the OSF/Motif documentation set.
This document is written for four audiences. The following text suggests the sections in this guide that are relevant to each audience. We recommend that you read through the entire OSF/Motif Style Guide once to familiarize yourself with all user interface design concepts and to ensure that you do not miss anything.
Application Designers
Should be familiar with the contents of Chapter 1, Chapter 6, Chapter 8, Appendix A and Appendix B.
Widget Designers
Should be familiar with the contents of Chapter 1 through Chapter 6, Chapter 8, Chapter 9, Appendix A and Appendix B.
User Interface System Designers
Should be familiar with the entire contents of this guide.
Window Manager Designers
Should be familiar with the contents of Chapter 1, Chapter 6, Chapter 7, Chapter 8, and Appendix A.
This is Revision 1.2 of this document. It applies to Release 1.2 of the OSF/Motif software system.
The purpose of this guide is to explain how to create OSF/Motif compliant applications, window managers, controls, and systems.
This document is organized into nine chapters and two appendixes.
Chapter 1, "User Interface Design Principles" provides general user interface design principles. Everyone should read this chapter.
Chapter 2, "Input Models" describes the input model. New widget designers and user interface system designers should read this chapter.
Chapter 3, "Navigation" describes the navigation model. New widget designers and user interface system designers should read this chapter.
Chapter 4, "Selection" describes the selection model. New widget designers and user interface system designers should read this chapter.
Chapter 5, "Component Activation" describes the activation model. New widget designers and user interface system designers should read this chapter.
Chapter 6, "Application Design Principles" describes user interface component choices, layout, and interaction. Everyone should read this chapter.
Chapter 7, "Window Manager Design Principles" describes window manager design. Window manager designers and user interface system designers should read this chapter.
Chapter 8, "Designing for International Markets" introduces and briefly describes internationalization and localization concepts and issues as they relate to user interface design. Everyone should read this chapter.
Chapter 9, "Controls, Groups, and Models Reference Pages" provides reference information for concepts described in earlier chapters, and provides detailed information about components. This chapter should be read by new widget designers and can by used as a reference by everyone.
Appendix A, "OSF/Motif Widgets and Components Correspondence" shows the correspondence between OSF/Motif widgets and components described in this guide.
Appendix B, "OSF/Motif Level One Certification Checklist" contains the Level One Certification Checklist, which is based on this guide.
For additional information about OSF/Motif, refer to the following documents:
The Application Enviroment Specification (AES) User Enviroment Volume defines a stable set of routines for creating user interface applications.
The OSF/Motif User's Guide explains how to interact with OSF/Motif based applications.
The OSF/Motif Programmer's Guide explains how to write applications using the OSF/Motif widget set.
The OSF/Motif Programmer's Reference provides detailed reference information for programmers writing Motif applications.
This document uses the following typographic conventions:
| Bold | Bold words or characters represent system elements that you must use literally, such as commands, flags, and pathnames. Bold words also indicate the first use of a term included in the glossary. | |
| Italic | Italic words or characters represent variable values that you must supply. | |
| < > | Angle brackets enclose the name of a key on the keyboard. |
Components of the user interface are represented by capital letters on each major word in the name of the component, such as PushButton.
See "Compliance Conventions" later in this Preface for an explanation of the asterisks (*) that appear in the margins.
Since not all keyboards are the same, it is difficult to give style guidelines that are correct for every manufacturer's keyboard. To solve this problem, this guide describes keys using a model keyboard mechanism. Wherever keyboard input is specified, the keys are indicated by the engraving they have on the OSF/Motif model keyboard. The model keyboard does not correspond directly to any existing keyboard, rather it assumes a keyboard with an ideal set of keys.
In addition to the standard letter, number, and character keys, the OSF/Motif model keyboard is composed of the following special keys:
The special printing characters </>,<\>,and <!>
The standard modifier keys <Ctrl>,<Alt>,and <Shift>
Ten function keys <F1> through <F10>
The arrow keys <Down arrow>,<Left arrow>,<Right arrow>,and <Up arrow>
<Backspace>
<Cancel>
<Delete>
<End>
<Escape>
<Help>
<Home>,<Begin>, or both
<Insert>
<Menu>
<PageDown>
<PageUp>
<Return>
<Space>
<Tab>
The OSF/Motif model keyboard also contains the following optional keys, which, although useful, are either not necessary or may be created by combinations of other keys:
<CapsLock>
<Copy>
<Cut>
<Enter>
<ModeSwitch>
<NumLock>
<PageLeft>
<PageRight>
<Paste>
<ScrollLock>
<Select>
<Undo>
Throughout this guide, behavior is described in terms of model keyboard keys. When a behavior takes advantage of an optional key from the model keyboard, it is also described in terms of the required special keys. Each of the keys described on the OSF/Motif model keyboard must be available either as specified or using other keys or key combinations if the specified key is unavailable. A few of the more important alternative key bindings are described here for your convenience.
If <Cancel> does not exist, <Escape> can be used in its place.
If <Help> does not exist, <F1> can be used in its place.
If <Menu> does not exist, <Shift> <F10> can be used in its place.
If <F10> does not exist, <Shift> <Menu> can be used in its place.
If <Home> or <Begin> does not exist, <Alt> <Left arrow> can be used in its place.
If <End> does not exist, <Alt> <Right arrow> can be used in its place
Wherever <Select> and <Space> can be used for a selection action, <Ctrl> <Space> can be used as well.
Wherever <Enter> and <Return> can be used for activation, <Ctrl> <Return> can be used as well.
Mouse buttons are described in this guide using a virtual button mechanism to better describe behavior independent from the number of buttons on the mouse. This guide assumes a 3-button mouse. On a 3-button mouse, the leftmost mouse button is usually defined as BSelect, the middle mouse button is usually defined as BTransfer, and the rightmost mouse button is usually defined as BMenu. Details about how virtual mouse buttons are usually defined are given in Section 2.2, "The Input Device Model."
Throughout the guide "must," "should," and "can" have special meanings. Guidelines with "must" in them are requirements for OSF/Motif Style Guide compliance. Any guideline with "must" is included in the "OSF/Motif Level One Certification Checklist" for OSF/Motif Style Guide compliance. Guidelines with "must" are marked in the margin with an asterisk (*). Guidelines with "should" in them are recommendations. We consider them important for interapplication consistency, but we do not require them for compliance. You should follow them as closely as you are able. Guidelines with "can" in them indicate optional elements of user interface style.
The process for how OSF/Motif Style Guide elements migrate from options to requirements is described in the "OSF/Motif Level One Certification Checklist" (see Appendix B, "OSF/Motif Level One Certification Checklist" ).
Note that by default this guide assumes your application is being designed for a left-to-right language direction environment, and that the application is written in English. Many of these guidelines can, and in fact should, be modified based on both language and scanning direction.
As of the 1.2 release, regions of this guide are designated with a support level. This support level system, which closely parallels the current Application Enviroment Specification (AES) User Enviroment Volume support level system, specifies the commitment OSF makes to the guidelines in that region. The higher the support level, the longer the warning period required before OSF can delete the guidelines, or make an incompatible change in the guidelines. (An incompatible change is one that might require compliant applications to be rewritten.) Support levels, therefore, serve as advisories for application developers because they indicate the length of time that a guideline is guaranteed to remain stable.
During the OSF/Motif Style Guide development process, OSF staff members propose support levels for guidelines, based on criteria defined later in this Preface. OSF members review and comment on these support levels and the rest of the document.
In general, membership review proceeds as follows:
OSF prepares a list of proposed changes to the OSF/Motif Style Guide, and circulates it to OSF members. This review period may last from one to several months.
Members submit comments.
OSF responds to members' comments in the next version of the document, or in a discussion that takes place in an electronic news group or at a meeting.
OSF considers all review comments during the development of the OSF/Motif Style Guide and brings important or controversial issues up for further discussion. However, the review process is not a voting process, and OSF does not wait for consensus among the membership before adding new interfaces to the OSF/Motif Style Guide or making other technical decisions.
This section defines the support levels assigned to the guidelines. As previously mentioned, support levels define OSF's commitment to interface definitions by indicating the warning period required to make an incompatible modification or deletion of the guideline. New OSF/Motif Style Guide revisions may introduce upwardly compatible changes at any time, regardless of the support level.
The support levels are as follows:
Full use
Trial use
The following sections explain each support level, and how guidelines move from proposed status (in drafts) to final status (in published versions).
A full-use guideline has the highest support level, so it is the most protected from incompatible modification or deletion.
OSF assigns a support level of full use to guidelines for the following reasons:
The guideline already exists in an approved de jure standard. (A de jure standard is one that is set by an official standards body.)
The guideline as specified in the OSF/Motif Style Guide is considered stable and already in widespread use in applications.
The guideline has been upgraded to full-use status after a period of trial-use status in an earlier OSF/Motif Style Guide revision.
There should rarely be a need to remove a full-use guideline, or make incompatible modifications to it. However, if this ever becomes necessary, a full-use guideline keeps its full-use status, but we will publish a warning describing the proposed future change in at least two successive revisions of the OSF/Motif Style Guide before we make the change. This provides time for applications to be altered to deal with a different guideline, and for implementations to prepare for the change.
For example, suppose it becomes necessary to modify a full-use guideline that appeared in Release 1.2 of the OSF/Motif Style Guide. The draft for Release 1.3 shows the guideline as "proposed-for-modification/removal." Assuming the review concludes that this change is appropriate, the guideline in Release 1.3 still has full-use status, but is accompanied by a warning. The warning states that the guideline is scheduled for modification after Release 1.4, and describes the modified behavior. Application developers can now allow for either the original or the modified guideline. Release 1.4 contains the same warning. Release 1.5 provides the modified definition only.
A trial-use guideline is easier to modify or delete than a full-use guideline. There are several reasons why OSF classifies guidelines as trial use instead of full use. A guideline may be under consideration for inclusion in a de jure standard and so may possibly change as a result of the standards process. Or, OSF may perceive that the guideline is new compared to other included guidelines and, therefore, the implementation and use of the guideline may suggest revisions in its definition.
If it becomes necessary to modify or delete a trial-use guideline, it keeps its trial-use status, with warnings about its removal or incompatible change, for one full revision of the OSF/Motif Style Guide. In the preceding example, if the guideline to be modified were a trial-use guideline, Release 1.3 would include the unmodified definition with a warning and description of the change, and Release 1.4 would include the modified definition only.
Draft versions of the OSF/Motif Style Guide give newly added or changed guidelines a "proposed-for-level" status, where level is full- or trial-use. In final versions, these guidelines move from "proposed-for-level" status to level status. Most existing guidelines retain their support level from the previous revision. A few may carry a proposed-for-change status (described as follows). New guidelines carry a proposed-for-level status.
The following list defines more exactly the AES proposed-for-inclusion and proposed for-change levels.
| Proposed-for-level-use |
| |
| Proposed-for-modification/removal |
| |
| Proposed-for-correction |
| |
| Proposed-for-enhancement |
|