A window manager is a specialized application. In designing a window manager, you must follow the same principles as for any other application. A window manager must also follow the style guidelines for input, navigation, selection, and activation models as set forth in Chapter 2 through Chapter 5.
There are a few elements of user interface design that are specific to window managers. This chapter discusses the following elements:
This chapter describes only those elements of window manager design that help create a consistent user interface. A window manager can supply a mechanism that allows the user to configure the window manager. The window manager can make any element user-configurable, including key bindings, Menu contents, default window decorations, or any other rules and elements defined in this guide. Any window manager that supplies a configuration mechanism must also include support for toggling between the current user configuration and the default configuration as mandated by this guide. The configuration toggle key press, <Alt> <Shift> <Ctrl> <!>,must initiate a configuration toggle. When the user issues a request to toggle the configuration, the window manager should request user verification before proceeding.
Users communicate with applications by using windows. A window is an area of the screen (usually rectangular) that provides the user with the functional means to communicate with an application and through which an application can communicate with the user.
A typical environment has several applications in operation simultaneously. Each application typically has a main or primary window that displays data and in which the user carries on primary interaction with the application. Applications can have additional windows to communicate context-specific interactions with the user of the application. These additional windows are called secondary windows, or transient windows. DialogBoxes are often used to create secondary windows. Figure 7-1 illustrates a typical OSF/Motif environment.
While each application can be made up of many windows, each window is one of only three basic types:
A window manager must support multiple applications, each with one or more primary windows. The window manager must also recognize and support secondary windows. Also, it must associate each secondary window with a primary window or another secondary window.
A primary window is the window from which all the other windows used by an application are generated. The window manager must support one or more primary windows for each windowing application. When an application has multiple primary windows, the window manager should treat each primary window as if it were an independent application.
When a primary window is iconized (minimized), the window and all of its associated secondary windows must be removed from the display and replaced with a single icon representing the primary window. Iconizing a window must not automatically suspend any processes of the window. However, a client can notice that a primary window has been unmapped and adjust its processing accordingly. When the icon of the window is opened, the primary window and all the current associated secondary windows must be restored. The window manager should try to place the windows in the same position from which they were iconified.
When a primary window is closed, the window and its icon must be removed from the display. All secondary windows associated with the primary window must also be closed. If the last primary window of an application is closed, the application must also be closed. When an explicit focus policy is in use, any secondary windows holding a TearOff Menu can be removed from the display, except when another window of the application has the focus.
Applications use secondary windows to conduct context-specific dialog with the user. Such context-specific dialogs are usually transitory, and the secondary windows can be removed when they are no longer needed. When a secondary window is closed, its parent must not be affected, and any secondary windows that are children of it must also be closed.
Secondary windows are always related to a parent window. Sometimes the parent is a primary window, sometimes another secondary window. Any window can have any number of secondary window children.
Secondary windows are not constrained to be clipped within their parent window, but they must always appear on top of that parent window in the window hierarchy. In a layered window manager, you can think of a primary window and its associated secondary windows as occupying one layer in the window hierarchy. Whenever one window is moved in the hierarchy, all of the associated windows must move accordingly. Thus, lowering a window must move that window and all associated windows to the bottom of the window hierarchy. Giving a window the focus must raise that window and all of the associated windows to the top of the hierarchy.
Secondary windows can limit how a user can interact with windows in order to force the order of interaction. A window manager must support the following four types, known as modes, of interaction with secondary windows:
A window manager must not allow the focus to be given to any window that is not allowed to accept input because of the modality of a DialogBox.
Menu windows are used to present Menus. They are not specifically created by applications but by the components used to create the application. Menu windows are always related to a parent window. The parent can be either a primary window, secondary window, or another Menu window. A window can only have one Menu window child at a time.
A Menu window is very short lived. It is only available to a client while no mouse or button actions are being performed elsewhere on the screen. Once interaction starts in another window on the screen, except a child Menu window, the Menu window must be removed.
Some Menus have a special behavior that allows a user to convert them into a secondary window. These Menus are called TearOff Menus. TearOff Menus can either be torn off in place or torn off and moved simultaneously. The window's title should be the name of the Menu entry that was torn off. The window manager must allow TearOff Menu transformations from Menu window to secondary window.
Menu windows are not constrained to be clipped within their parent window, but they must always appear on top of that parent window in the window hierarchy. The window manager must not supply any window decoration to Menu windows.
A window manager can provide windows with a window frame that contains components called decorations. The window decorations allow user interaction with the window manager. Along with the frame components, a window manager contains a client area. The client area is the display area for an application. Figure 7-2 shows a typical window and its decorations.
A window manager can support any number of window decorations, but it must support the client area and the window frame. A window manager must support the following window frame components:
Each window must have a client area. A window manager must allow each window to choose which combination of decorations to include, except that a window must not have any buttons without a title area. A primary window must by default have all the decorations: window Menu button, maximize button, minimize button, title area, and resize border. A secondary window must by default have a window Menu button and title area. In a secondary window, resize borders and a maximize button can be provided if there is a reason to resize the window.
Clicking BSelect on the window frame should give the window focus and raise the window to the top of the window hierarchy, except when dialog modality disallows focus to be set in the window.
The client area is the portion of the window in which the user performs most application-level tasks. For example, if the user is working with a graphics editor or a text editor, the client area contains the figure or document being edited. The client area is inside the window frame and can be composed of multiple work areas. Figure 7-2 shows the client area in a typical window.
The title area, also called the title bar, supplies a place to identify the window. If a window includes a title area, it must be a horizontal bar at the top of the window. It must be just above the client area and lie horizontally between the window Menu (or other buttons) on the left and the window control buttons on the right. Figure 7-2 shows the title area in a typical window.
The title area should contain a short string called the title that labels the contents of the window. The title must be settable at window startup both by the user and by the application. For applications with a single primary window, the title should be the name of the application. For applications with multiple primary windows, the title should indicate the purpose of the window. The title in secondary windows should indicate the purpose of the window. The title can also contain other useful information, such as the machine on which the application is running, the current directory, or similar relatively static information.
Besides supplying a location for a label, the title area also acts as a position, or handle, for moving a window. Pressing BSelect or BTransfer in the title area and dragging the pointer must move the window relative to the moving pointer.
The maximize button provides mouse users with a shortcut to the Maximize entry in the window Menu. If a window includes a maximize button, it must be just above the client area and its right border must align with the right border of the client area. Figure 7-2 shows the maximize button in a typical window. Primary windows should have a maximize button. Secondary windows generally do not have a maximize button.
The graphic in the maximize button should be a large square or an up arrow. If the maximize button uses an up arrow as its graphic, a maximized window should use a double-headed arrow to indicate that it is maximized. If the maximized button uses a large square as its graphic, a maximized window can show the graphic in a different state. Activating the maximize button must increase the size of the window to the maximum allowable size. As a shortcut for mouse users to the Restore entry in the window Menu, activating the maximize button of a maximized window must restore the window to its size and location before being maximized.
The minimize button provides mouse users with a shortcut to the Minimize entry in the window Menu. If a window includes a minimize button, it must be just above the client area and directly to the left of the maximize button. Figure 7-2 shows the minimize button in a typical window. Primary windows should have a minimize button. Secondary windows must not have a minimize button.
The graphic in the minimize button should be a small square or a down arrow. Activating the minimize button must iconify the window unless the window family contains a system modal DialogBox.
You can bind additional window manager functions to buttons on the window frame. Any additional buttons must be placed directly to the left of the minimize button or directly to the right of the window Menu button and above the client area. Each button action must correspond to a entry in the window Menu.
Applications can suggest the initial size of their windows to the window manager. Window sizes can vary according to the work performed in them. At any time, a user should be able to alter the size of most windows. The Size entry in the window Menu provides a method for the user to alter the size of windows. The resize borders provide a shortcut for mouse users for the Size entry in the window Menu. Resize borders are not generally provided on secondary windows.
The resize borders are the outermost components of the window manager frame. They are made up of two components: the corner handles and the edge handles. If a window includes resize borders, there must be one corner handle in each corner of the window at its extremes, and one edge handle between each pair of corner handles. There must be no window components outside the boundary formed by the resize borders. Figure 7-2 shows resize borders in a typical window.
Pressing BSelect or BTransfer in a corner handle and dragging the pointer must change the height and width of the window relative to the moving pointer without changing the position of the opposite corner. Pressing BSelect or BTransfer in a top or bottom edge handle and dragging the pointer must change the height of the window relative to the moving pointer without changing the width or the position of the opposite edge. Pressing BSelect or BTransfer in a side edge handle and dragging the pointer must change the width of the window relative to the moving pointer without changing the height or the position of the opposite edge.
The window Menu, sometimes called the system Menu or control Menu, is used to display the list of window actions. All actions possible for a window should be displayed in the window Menu because keyboard-only users interact with the window manager through this Menu. Because of this, it is rare that a window does not need a window Menu. The window Menu can be configured out by the application or by the user, but it should not be removed by the window manager.
If a window includes a window Menu, the window Menu button must be located just above the client area, the left edge of the button must align with the left edge of the client area, and the button must be just to the left of the title area, unless other buttons are included between the window Menu button and the title area.
Double-clicking the window Menu button can be used to close the window, unless focus is disallowed in the window. A user must be able to activate the window Menu button for the window with the focus by using <Shift> <Escape> or <Alt> <Space>.
Figure 7-3 shows a typical window Menu.
A primary window Menu must have the following entries in the order listed:
A secondary window Menu must have the following entries in the order listed: Move, Size, and Close. A secondary window Menu can include Restore above Move, Maximize below Size, and Lower above Close, but the lower option on a secondary window lowers all the windows secondary to that window's primary window. A secondary window Menu should not include Restore if it does not include Maximize. A secondary window must not include an entry for Minimize.
A secondary window resulting from a Menu being torn off must have the following entries in the order listed: Move, Lower, and Close. It must not include entries for Restore, Size, Minimize, or Maximize.
Additional Menu items can be added to the window Menus of both primary and secondary windows according to the guidelines for Menus described in Chapter 6, "Application Design Principles."
Moving the focus among windows using the keyboard is called window navigation. Because applications should not warp the mouse pointer, a window manager need not support window navigation when the focus policy is in pointer mode. Window managers must support window navigation when the focus policy is in explicit mode.
The window navigation model can be divided into two levels:
Moving among window families (among primary windows)
Moving within a window family (among secondary windows)
A window family consists of a single primary window and all of its associated secondary windows. A window manager must support moving the keyboard focus among windows in a window family using the <Alt> <F6> key. A window manager can support moving the keyboard focus in the opposite direction from <Alt> <F6> using the <Alt> <Shift> <F6> key.
Moving the focus between window families must be done using <Alt> <Tab> and <Alt> <Shift> <Tab>.<Alt> <Shift> <Tab> should move the focus among the windows in the opposite direction from <Alt> <Tab>.If there is no icon box, <Alt> <Tab> and <Alt> <Shift> <Tab> must move among the icons as well as the windows. When focus moves into a window family, the focus should go to the window in the window family that last had the focus. If no window in the family has ever had the focus, it should go to the most recently opened secondary window.
An icon is a stylized representation of an object. A window icon is a minimized representation of a window or window family that can help organize windows and tasks in the display. Iconifying a window is also known as minimizing a window. The window manager must iconify all windows of a window family together. It must not iconify any single window, primary or secondary, from a window family without also iconifying all the other windows in the window family. The iconic representation of a window family should not change any state in the windows, except the visual representation of the window. The application running inside of a window must continue running even when the application is iconified. The application can adjust its own state when it is iconified.
An icon is made up of an image and a label. Figure 7-4 shows a typical Motif icon.
The image should be surrounded by a border that indicates when the icon has the keyboard focus. The image area can contain text or a bitmap. The label should be located just below the image and its border. The label can also indicate when the icon has the keyboard focus by highlighting with the image area.
The label should contain the same text as the title area of the corresponding primary window, or an abbreviated form of it. When the icon does not have the keyboard focus, the width of the label must be the same as the width of the image area and its border, truncating text if necessary. When the icon has the keyboard focus, the width of the label can expand to display the entire text.
Clicking BSelect in an icon must give the icon the keyboard focus and post the icon Menu. The icon Menu must be the same Menu as the window Menu for the associated primary window. Size should not be available from the icon Menu. Navigating to the icon must also give the icon the keyboard focus and should post the icon Menu.
Double-clicking BSelect anywhere in the icon must restore the window family, just as the icon Menu item Restore does. If the window is currently minimized, but its previous state was maximized, double-clicking BSelect returns it to the maximized state. Selecting Maximize from the icon Menu always maximizes the corresponding window. If the window is minimized, Minimize must not be available in the icon Menu; otherwise, selecting it minimizes the window family. Pressing BSelect or BTransfer anywhere in the icon and dragging the mouse pointer must move the icon to track the pointer, just as the icon Menu item Move does.
If the window manager has been customized by the user so that the icon Menu does not pop up when the icon gets the focus, <Shift> <Escape>,<Alt> <Space>,<Menu>,and BMenu must pop up the icon Menu.
An icon box is a specialized window that acts as a storage location for icons. An icon box acts like a typical window in the sense that it has a window frame and frame components. The client area of an icon box must have an area for holding icons and can have horizontal and vertical scroll bars for moving around the icon area. Figure 7-5 shows a typical icon box.
The icon box must have all the same components as any other primary window. Like other windows it can be sized, moved, minimized, maximized, restored, and lowered. However, the window manager must not allow the icon box to be closed. The system Menu action Close must be replaced with the system Menu action Pack Icons in an icon box. Double-clicking BSelect in the icon box system Menu must only open the icon box system Menu. It must not close the icon box. Pack Icons arranges the icons as close as possible together in the visible icon area if possible. Pack Icons must have the mnemonic P. If Pack Icons has an accelerator, it should be <Alt> <F12> if <F12> is available. When the input focus is in the icon box, <Shift> <Escape> or <Alt> <Space> must pop up the icon box system Menu if the Menu is unposted. If the Menu is already posted, <Shift> <Escape> or <Alt> <Space> must unpost the Menu.
The icon box can contain an icon for each window family, even if it is active. The icon for minimized window families must be the same as the icon would be outside of the icon box. The icon for an active window family should be similar to the minimized icon, deemphasized somehow.
Clicking BSelect in an icon must give the icon keyboard focus and post the icon Menu. The icon Menu must be the same Menu as the window Menu for the associated primary window. If the icon represents an active window family, Restore and Size must not be available from the icon Menu. If the icon represents a minimized window family, Size must not be available from the icon Menu. If the window manager is customized so that the icon with the focus does not have its window Menu automatically posted, BMenu or <Menu> must post its Menu.
Double-clicking BSelect anywhere in an icon that represents a minimized window family must restore the window family, just as the icon Menu item Restore does. Double-clicking BSelect anywhere in an icon that represents an active window family must raise the window family to the top of the window hierarchy. If the window is currently minimized, but its previous state was maximized, double-clicking BSelect returns it to the maximized state. Selecting Maximize from the icon Menu always maximizes the corresponding window. If the window is minimized, Minimize must not be available in the icon Menu; otherwise, selecting it minimizes the window family. Pressing BSelect or BTransfer anywhere in the icon and dragging the mouse pointer must move the icon within the icon area to track the pointer, just as the icon Menu item Move does.
The directional keys <Down arrow>,<Up arrow>,<Right arrow>,and <Left arrow> must navigate among the icons in the icon box. Icon navigation must behave as described in the following text. Note that <Down arrow> and <Right arrow> do not need to traverse icons in the same order.
| <Down arrow> |
| |
| <Left arrow> |
| |
| <Right arrow> |
| |
| <Up arrow> | This key must move the location cursor through the icons in the opposite direction of <Down arrow>. |