Table of Contents
GNOME provides a set of controls, also known as widgets, which allow users to interact with your applications. Using these controls appropriately and not altering their standard behavior is important. This allows users to predict the effects of their actions, and thus learn to use your application more quickly and efficiently. Controls that behave in non-standard ways break the user's mental model of how your application works, and dilute the meaning of the interface's visual language.
Although they are known as "widgets" in the GNOME APIs and developer documentation, do not use this term in your user interface or user documentation. Refer to them by their specific names (for example, "buttons" or "menus"), or by the generic name "controls".
Sometimes it does not make sense to allow the user to interact with a control in the current context, for example, to press a Paste button when the clipboard is empty. At these times, make the control insensitive to minimize the risk of user error. While a control is insensitive, it will appear dimmed and will not be able to receive the focus, although assistive technologies like screenreaders will still be able to detect and report it.
It is usually better to make a control insensitive than to hide it altogether. This way, the user can learn about functionality they may be able to use later, even if it is not available right now.
Figure 6.1. Two check boxes: sensitive (top) and insensitive (bottom)
In a network-managed environment, like a computer lab, system administrators usually want to "lock down" the values of certain settings, or remove them from the user interface altogether. This makes it easier for them to troubleshoot any problems that their users may encounter. In GNOME, the correct way for the system administrator to do this is by restricting write access to the GConf keys corresponding to those settings.
When you are designing your application, consider which settings a system administrator might want to make unavailable to users. These may typically include:
Settings that, if set wrongly, could prevent the application from functioning at all. For example, proxy settings in a network application.
Settings that could refer to networked resources. For example, the Templates directory in an office application, where shared stationery such as fax cover sheets might be stored.
Settings that customize the user interface, other than those required for accessibility. For example, certain menu, keyboard or toolbar customization options.
Your application needs to decide every time these controls are displayed whether or not they are available for editing, depending on the writeable state of the GConf key that holds its value. In the simplest case, your code for each control could look like that in the example below.
Example 6.1. Sample code fragment showing how to make a GConf-locked control insensitive
if (!gconf_key_is_writable (http_proxy)) gtk_widget_set_sensitive (http_proxy_field, FALSE);
Include a section for system administrators in your user guide, explaining which settings they can lock, and their corresponding GConf keys.
Explain to the user why these controls cannot be edited at this time. You can do this with static text, tooltips or online help, depending on the situation. For example:
Figure 6.2. Example of a dialog with locked controls
Note that although they cannot be edited, the settings are still visible and selectable, and may be copied to the clipboard.
Text entry fields are used for entering one or more lines of plain text. In GTK 2, the GtkEntry control is used for single-line text entry, and GtkTextView for multiple-line text entry.
Figure 6.3. Single and multi-line entry fields
Guidelines
Label the entry field with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the entry field.
Right-justify the contents of entry fields that are used only for numeric entry, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned.
When the user gives focus to an entry field using the keyboard, place the text cursor at the end of the existing text and highlight its contents (but don't overwrite the existing PRIMARY clipboard selection). This makes it easy to immediately overtype or append new text, the two most common operations performed on entry fields.
Size text entry fields according to the likely size of the input. This gives a useful visual cue to the amount of input expected, and breaks up the dialog making it easier to scan. Don't make all the fields in the dialog the same width just to make everything line up nicely.
In an instant-apply property or preference window, validate the contents of the entry field when it loses focus, not after each keypress.
Provide a static text prompt for text boxes that require input in a particular format or in a particular unit of measurement. For example:
Figure 6.4. Text entry field with static text prompt
Where possible, provide an additional or alternative control that limits the required input to the valid range. For example, provide a spinbox or slider if the required input is one of a fixed range of integers, or provide access to a GtkCalendar control if the user has to enter a valid date:
Figure 6.5. Text entry field requiring a date as input, with a button beside it to pop up a GtkCalendar control to simplify the task
This is less error-prone than expecting the user to format their text input in some arbitrary format. You may still want to provide the entry field control as well, however, for expert users who are familiar with the required format.
If you implement an entry field that accepts only keystrokes valid in the task context, such as digits, play the system warning beep when the user tries to type an invalid character. If the user types three invalid characters in a row, display an alert that explains the valid inputs for that textfield.
Normally, pressing Return in a dialog should activate the dialog's default button, unless the focused control uses Return for its own purposes. You should therefore set the activates-default property of most entry fields to TRUE. (Note that GtkTextView does not have such a setting— pressing Return always inserts a new line.).
However, if your dialog contains several entry fields that are usually filled out in order, for example Name, Address and Telephone Number, consider setting the activates-default property on those entry fields to FALSE. Pressing Return should then move focus on to the next control instead. Doing this will help prevent the user from accidentally closing the window before they have entered all the information they wanted to.
As a further safeguard, remember not to set the default button in a dialog until the minimum amount of required information has been entered, for example, both a username and a password in a login dialog. Again, in this case you should move focus to the next control when the user presses Return, rather than just ignoring the keypress.
If you need to provide a keyboard shortcut that activates the default button while a GtkTextView control has focus, use Ctrl-Return.
Note
Gtk does not currently move focus to the next control when Return is pressed and either activates-default=FALSE, or there is no default button in the window. For now, Return does nothing in these situations, so remember to implement the focus change behavior yourself.
Normally, pressing Tab in a single-line entry field should move focus to the next control, and in a multi-line entry field it should insert a tab character. Pressing Ctrl-Tab in a multi-line entry field should move focus to the next control.
If you need to provide a keyboard shortcut that inserts a tab character into a single line entry field, use Ctrl-Tab. You are unlikely to find many situations where this is useful, however.
A spin box is a text box that accepts a range of values. It incorporates two arrow buttons that allow the user to increase or decrease the current value by a fixed amount.
Figure 6.6. Example of a spin box
Guidelines
Use spin boxes for numerical input only. Use a list or option menu when you need the user to select from fixed data sets of other types.
Use a spin box if the numerical value is meaningful or useful for the user to know, and the valid input range is unlimited or fixed at one end only. For example, a control for specifying the number of iterations of some action, or a timeout value. If the range is fixed at both ends, or the numerical values are arbitrary (for example, a volume control), use a slider control instead.
Label the spin box with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the spin box.
Right-justify the contents of spin boxes, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned.
A slider allows the user to quickly select a value from a fixed, ordered range, or to increase or decrease the current value. The control looks like the type of slider that you might find on an audio mixing desk or a hi-fi's graphic equalizer. In gtk, you implement a slider using the GtkHScale or GtkVScale controls, for horizontal or vertical sliders respectively.
Guidelines
Use a slider when:
adjusting the value relative to its current value is more important than choosing an absolute value. For example, a volume control: the average user will usually think about turning the volume up or down to make a sound louder or quieter, rather than setting the peak output to a specific decibel value.
it is useful for the user to control the rate of change of the value in real time. For example, to monitor the effects of a color change in a live preview window as they drag the RGB sliders.
Label the slider with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the slider.
Mark significant values along the length of the slider with text or tick marks. For example the left, right and center points on an audio balance control in Figure 6.7.
For large ranges of integers (more than about 20), and for ranges of floating point numbers, consider providing a text box or spin box that is linked to the slider's value. This allows the user to quickly set or fine-tune the setting more easily than they could with the slider control alone.
Figure 6.8. Slider controls with linked spin boxes
A button initiates an action when the user clicks it.
Figure 6.9. Typical buttons in a modal dialog
Guidelines
Label all buttons with imperative verbs, using header capitalization. For example, Save, Sort or Update Now. Provide an access key in the label that allows the user to directly activate the button from the keyboard.
After pressing a button, the user should expect to see the result of their action within 1 second. For example, closing the window or opening another. See Chapter 7 for guidance on what to do if your application cannot respond this quickly.
Use an ellipsis (...) at the end of the label if the action requires further input from the user before it can be carried out. For example, Save As... or Find.... Do not add an ellipsis to commands like Properties, Preferences, or Settings, as these open windows that do not require further input.
Once a dialog is displayed, do not change its default button from one button to another. You may add or remove default status from the same button if it helps prevent user error, however. Changing the default from one button to another can be confusing and inefficent, especially for users relying on assistive technologies.
If your button can display text, an icon, or both, choose which label to display at runtime according to the user's preference in the GNOME Menus and Toolbars Preferences dialog. However, you may over-ride this preference when there is no suitable icon to describe the button's action graphically, for example.
Do not use more than one or two different widths of button in the same window, and make all of them the same height. This will help give a pleasing uniform visual appearance to your window that makes it easier to use.
Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover these actions, and if they do, it will distort their expectations of other buttons on the desktop.
Make invalid buttons insensitive, rather than popping up an error message when the user clicks them.
In a dialog, one button may be made the default button, which is shown with a different border and is activated by pressing Return. Often this will be the OK or equivalent button. However, if pressing this button by mistake could cause a loss of data, do not set a default button for the window. Do not make Cancel the default button instead. See the section called “Default Buttons” for more information.
If it does not make sense to have a default button until several fields in the dialog have been correctly completed—for example, both the Username and Password fields in a login dialog—do not set the default button until they have both been completed.
Check boxes are used to show or change a setting. Its two states, set and unset, are shown by the presence or absence of a checkmark in the labelled box.
Figure 6.10. A typical group of check boxes
Guidelines
Do not initiate an action when the user clicks a check box. However, if used in an instant-apply property or preference window, update the setting represented by the check box immediately.
Clicking a check box should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.
If toggling a check box affects the sensitivity of other controls, place the check box immediately above or to the left of the controls that it affects. This helps to indicate that the controls are dependent on the state of the check box.
Use sentence capitalization for check box labels, for example Use custom font.
Label check boxes to clearly indicate the effects of both their checked and unchecked states, for example, Show icons in menus. Where this proves difficult, consider using two radio buttons instead so both states can be given labels. For example:
Figure 6.11. Ambiguous check box (top), radio buttons work better in this case (bottom)
The single check box in this example is ambiguous, as it is not clear where the "progress indicator" will go if the box is unchecked. Two radio buttons are better in this case, as they make the options clear.
Provide an access key in all check box labels that allows the user to set or unset the check box directly from the keyboard.
If the check box represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the check box in its mixed state. For example:
Figure 6.12. Check boxes (right) showing properties for a multiple selection of files in Nautilus (left)
In this example, both selected files are hidden (since their filenames start with "."), and the emblems on their icons show that neither file is writeable, but one is readable. The Readable check box is therefore shown in its mixed state. .
When a check box is in its mixed state:
clicking the box once should check the box, applying that setting (when confirmed) to all the selected objects
clicking the box a second time should uncheck the box, removing that setting (when confirmed) to all the selected objects
clicking the box a third time should return the box to its mixed state, restoring each selected object's original value for that setting (when confirmed)
Label a group of check boxes with a descriptive heading above or to the left of the group.
Use a frame around the group if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.
Do not place more than about eight check boxes under the same group heading. If you need more than eight, try to use blank space, heading labels or frames to divide them into smaller groups. Otherwise, consider using a check box list instead— but you probably also need to think about how to simplify your user interface.
Try to align groups of check boxes vertically rather than horizontally, as this makes them easier to scan visually. Use horizontal or rectangular alignments only if they greatly improve the layout of the window.
Radio buttons are used in groups to select from a mutually exclusive set of options. Only one radio button within a group may be set at any one time. As with check boxes, do not use radio buttons to initiate actions.
Figure 6.13. A typical group of radio buttons
Guidelines
Only use radio buttons in groups of at least two, never use a single radio button on its own. To represent a single setting, use a check box or two radio buttons, one for each state.
Exactly one radio button should be set in the group at all times. The only exception is when the group is showing the properties of a multiple selection, when one or more of the buttons may be in their mixed state.
Do not initiate an action when the user clicks a radio button. However, if used in an instant-apply property or preference window, update the setting represented by the radio button immediately.
Clicking a radio button should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.
If toggling a radio button affects the sensitivity of other controls, place the radio button immediately to the left of the controls that it affects. This helps to indicate that the controls are dependent on the state of the radio button.
Use sentence capitalization for radio button labels, for example Switched movement. Provide an access key in the label that allows the user to set the radio button directly from the keyboard.
If the radio button represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the radio button in its mixed state. For example:
Figure 6.14. Radio buttons (right) showing properties for a multiple selection of shapes in a drawing application (left)
. In this situation, clicking any radio button in the group should set the clicked button, and unset all the others. Thereafter, the group should behave like a normal radio button group— there is no way to reset a radio button to its mixed state by clicking on it. Provide a Reset button or equivalent in the window that allows the previous mixed settings to be restored without closing the window or cancelling the dialog.
Label a group of radio buttons with a descriptive heading above or to the left of the group.
Use a frame around the group if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.
Do not place more than about eight radio buttons under the same group heading. If you need more than eight, consider using a single-selection list instead— but you probably also need to think about how to simplify your user interface.
Try to align groups of radio buttons vertically rather than horizontally, as this makes them easier to scan visually. Use horizontal or rectangular alignments only if they greatly improve the layout of the window.
Toggle buttons look similar to regular Buttons, but are used to show or change a state rather than initiate an action. A toggle button's two states, set and unset, are shown by its appearing "pushed in" or "popped out" respectively.
Figure 6.15. A typical group of toggle buttons
Guidelines
Do not use groups of toggle buttons in dialogs unless space constraints force you to do so, or you need to provide consistency with a toolbar in your application. Check boxes or radio buttons are usually preferable, as they allow more descriptive labels and are less easily-confused with other types of control.
Only use toggle buttons in groups, so they are not mistaken for regular buttons. Make the group behave like either a group of check boxes or a group of radio buttons, as required.
Provide an access key in the label of all toggle buttons that allows the user to set or unset the button directly from the keyboard.
Label a group of toggle buttons with a descriptive heading above or to the left of the group, as you would with a group of check boxes or radio buttons.
Use a frame around the group of buttons if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.
Try to align groups of toggle buttons horizontally rather than vertically. This is how toggle buttons normally appear on a toolbar, so the user will be more familiar with this arrangement.
Do not leave any space between toggle buttons in a group, otherwise they may look unrelated or may be mistaken for regular buttons.
Use header capitalization for toggle button labels, for example No Wallpaper, Embossed Logo.
If your toggle button can display text, an icon, or both, choose which to display at runtime according to the user's setting in the GNOME Menus and Toolbars preference dialog.
Use the same text or graphical label for a toggle button whether it is set or unset.
If the toggle button represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the button in its mixed state. For example:
Figure 6.16. Toggle buttons (right) showing properties for a multiple selection of shapes in a drawing application (left)
Option menus are used to select from a mutually exclusive set of options. They can be useful when there is insufficient space in a window to use a group of radio buttons or a single-selection list, with which they are functionally equivalent.
Figure 6.17. An option menu showing current selection (left) and the list of available choices when clicked on (right)
Recommendations:
Do not use option menus with fewer than three items, or more than about ten. To offer a choice of two options, use radio buttons or toggle buttons. To offer a choice of more than ten options, use a list.
Do not initiate an action when the user selects an item from an option menu. However, if used in an instant-apply property or preference window, update the setting that the menu represents immediately.
Selecting an item from an option menu should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.
Label the option menu with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the option menu.
Use sentence capitalization for option menu items, for example Switched movement
Assign an access key to every option menu item. Ensure each access key is unique within the enclosing window or dialog, not just within the menu.
Do not assign shortcut keys to option menu items by default. The user may assign their own shortcut keys in the usual way if they wish, however.
Do not use an option menu in a situation where it may have to show a property of a multiple selection, as option menus have no concept of mixed state. Use a group of radio or toggle buttons instead, as these can show set, unset or mixed states.
You should normally use radio buttons or a list instead of option menus, as those controls present all the available options at once without any further interaction. However, option menus may be preferable in a window where:
there is little available space
the list of options may change over time
the contents of the hidden part of the menu are obvious from its label and the one selected item. For example, if you have an option menu labelled "Month:" with the item "January" selected, the user might reasonably infer that the menu contains the 12 months of the year without having to look.
Option menus can also be useful on toolbars, to replace a group of several mutually-exclusive toggle buttons.
Combo boxes combine a text entry field and a dropdown list of pre-defined values. Selecting one of the pre-defined values sets the entry field to that value.
Figure 6.18. A combo box before and after its dropdown list is displayed
Guidelines
Only use a combo box instead of a list, option menu or radio button group when it is important that the user be able to enter a new value that is not already amongst the list of pre-defined choices.
Do not initiate an action when the user selects an item from the list in a combo box. If used in an instant-apply property or preference window, update the setting represented by the combo box immediately if possible. If this isn't possible due to the contents of the entry field being invalid while the user is still typing into it, update the related setting when the combo box loses focus instead.
If the user types a value into the combo box that is not already in the drop-down list, add it to the list when the combo box loses focus so they can select it next time.
Interpret user input into a combo box in a case-insensitive way. For example, if the user types blue, Blue and BLUE into the same combo box on different occasions, only store one of these in the combo's dropdown list, unless your application makes a distinction between the different forms (which is usually a bad idea).
Label the combo box with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the combo box.
Use sentence capitalization for the dropdown list items, for example Switched movement.
A list control allows the user to inspect, manipulate or select from a list of items. Lists may have one or more columns, and contain text, graphics, simple controls, or a combination of all three.
Figure 6.19. A simple two column list
Guidelines
Always give list controls a label, positioned above or to the left of the list, in sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the list.
Make the list control large enough that it can show at least four items at a time without scrolling. For lists of ten or more items, increase this minimum size as appropriate.
If the list appears in a dialog or utility window, consider making the window and the list within it resizable so that the user can choose how many list items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.
Do not use lists with less than about five items, unless the number of items may increase over time. Use check boxes, radio buttons or an option menu if there are fewer items.
Only use column headers when:
the list has more than one column, or
the list has only one column, but the user may wish to re-order the list. (This is rarely useful with single column lists).
In most other situations, column headers take up unnecessary space, and the extra label adds visual clutter.
Always label column headers when used. If the column is too narrow for a sensible label, provide a tooltip for the column instead. Apart from its obvious use, this will help ensure that assistive technologies can describe the use of the column to visually impaired users.
Consider using a check box list for multiple-selection lists, as these make it more obvious that multiple selection is possible:
Figure 6.20. A simple check box list
If you do this, you should normally set the list control itself to be single-selection, but this depends on the particular task for which it will be used.
For multiple selection lists, show the number of items currently selected in a static text label below the list, for example, Names selected: 3. Such a label also makes it more obvious that multiple selection is possible.
Consider providing Select All and Deselect All buttons beside multiple selection lists, if appropriate.
A tree control allows the user to inspect, manipulate or select from a hierarchichal list of items. Trees may have one or more columns, and contain text, graphics, simple controls, or a combination of all three.
Use trees with care!
Because of their complexity compared to other controls, novice and some intermediate users often have problems using and understanding tree controls. If your application is designed for that type of user, you might want to consider alternative ways of presenting the information, such as the Nautilus list or icon view, or the hierarchical browser lists found in GNUstep's File Viewer.
Figure 6.21. A simple tree control with one level of hierarchy
Guidelines
Always give tree controls a label, positioned above or to the left of the tree, in sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the tree.
Use column headers when:
the tree has more than one column
the tree has only one column, but the user may wish to re-order the tree. This should rarely be true of single column trees.
In most other situations, column headers take up unnecessary space, and the extra label adds visual clutter.
Always label column headers when used. If the column is too narrow for a sensible label, provide a tooltip for the column instead. Apart from its obvious use, this will help ensure that assistive technologies can describe the use of the column to visually impaired users.
Consider using a check box tree for multiple-selection trees, as these make it more obvious that multiple selection is possible:
Figure 6.22. A simple check box tree
If you do this, you should normally set the tree control itself to be single-selection, but this depends on the particular task for which it will be used.
For multiple selection trees, show the number of items currently selected in a static text label below the tree, for example, Names selected: 3. Such a label also makes it more obvious that multiple selection is possible.
Consider providing Select All and Deselect All buttons beside multiple selection trees, if appropriate to the task.
A tabbed notebook control is a convenient way of presenting related information in the same window, without having to display it all at the same time. It is analagous to the divider tabs in a ring binder or a file cabinet.
Figure 6.23. A typical notebook control with four tabs
Guidelines
Do not put too many pages in the same notebook. If you cannot see all the tabs without scrolling or splitting them into multiple rows, you are probably using too many and should use a list control instead. See the example below.
Label tabs with header capitalization, and use nouns rather than verbs, for example Font or Alignment. Try to keep all labels in a notebook the same general length.
Do not assign access keys to tab labels, as this means you cannot use those access keys for any control on any of the tabs. Assign an access key to every other control on each page, however.
Do not design a notebook such that changing controls on one page affects the controls on any other page. Users are unlikely to discover such dependencies.
If a control affects only one notebook page, place it on that notebook page. If it affects every page in the notebook, place it outside the notebook control, for example beside the window's OK and Cancel buttons.
Use tabs that are proportional to the width of their labels. Don't just set all the tabs to the same width, as this makes them harder to scan visually, and limits the number of tabs you can fit into the notebook without scrolling. For example:
Figure 6.24. Fixed- and proportional-width tabs (preferred)
Although the contents of each page in a notebook will take up a different amount of space, do not use larger than normal spacing around the controls in the "emptier" pages, and do not center the controls on the page.
If your tab labels include icons, choose whether or not to show the icons at runtime based on the user's preference in the GNOME Menus and Toolbars desktop preferences dialog. Always show the text part of the label, however.
If you have more than about six tabs in a notebook, use a list control instead of tabs to switch between the pages of controls. For example:
Figure 6.25. Use of list control where there would be too many tabs to fit comfortably in a notebook
As in this example, place the list control on the left-hand side of the window, with the dynamic portion of the window immediately to its right.
Progress bars are visual indicators of the progress of a task being carried out by the application.
There are two types of progress indicator: "measured" progress, which shows what proportion of the task has been completed, and "indeterminate" progress, which only shows that the application is busy. The progress bar control is used to show measured progress. (For more information on indeterminate progress indicators, see the section called “Indeterminate-progress indicator”.)
Figure 6.26. A measured ("time remaining") progress dialog
There are three styles of measured progress indicator in which you would typically use a progress bar control:
Always use a measured progress bar when the length of a task can be precisely or approximately predicted. Otherwise, use an indeterminate progress indicator or a progress checklist.
See Chapter 7 for more details on when and how to use progress bars.
A status bar is an area at the bottom of a window that can be used to display brief information about the status of the application.
Figure 6.27. A simple status bar
Guidelines
Use status bars only in application or document windows. Do not use them in dialogs, alerts or other secondary windows.
Only place a status bar along the bottom of a window.
Only use status bars to display non-critical information. This might include:
general information about the document or application. For example, current connection status in a network application, or the size of the current document in a text editor.
information about the task the user is currently performing. For example, while using the selection tool in a drawing application, "Hold Shift to extend the selection"
progress of a background operation. For example, "Sending to printer", "Printing page 10 of 20", "Printing Complete".
a description of the control or area of the window under the mouse pointer. For example, "Drop files here to upload them"
Remember that status bars are normally in the user's peripheral vision, and can even be turned off altogether using the application's View->Status Bar menu item. The user may therefore never see anything you display there, unless they know when and where to look for it.
When there is no interesting status to report, leave a status bar panel blank rather than displaying something uninformative like "Ready". This way, when something interesting does appear in the status bar, the user is more likely to notice it.
If you want to make all or part of your status bar interactive, use the following conventions:
Inlaid appearance for areas that respond to a double click
Flat appearance for areas that are not interactive
In Figure 6.28, the appearance indicates that the left area would respond to a double click (perhaps by saving the document), and the progress indicator on the right is non-interactive.
Ensure that double-clicking in the status area does not provide any functionality that is not also available in the main application menu bar, or by some other accessible means.
A frame is a box with a title that you can draw around controls to organise them into functional groups. A separator is a single horizontal or vertical line that you can use to divide windows into functional groups.
Frames with a border around their perimeter have traditionally been used for denoting groups of related controls. This is advantageous because it physically seperates disimilar controls, and also avoids repitition of the frame's label in individual member control labels. Unfortunately, they add visual noise that can both make a window appear more complex than it really is, and reduce the ability to quickly scan window elements.
Rather than using bordered frames, use frames without borders, bold labels to make the categories stand out, and indented contents. This, combined with good layout and spacing, is usually a better alternative to bordered frames.
Figure 6.29. Preferred frame style, using bold labels, spacing and indentation
Figure 6.30. Traditional frame style, using borders (deprecated)
See the section called “Spacing and Alignment” for technical details on implementing the preferred frame style in gtk.
Guidelines
Before you add a frame with a visible border or separator to any window, consider carefully if you really need it. It is usually better to do without, if the groups can be separated by space alone. Do not use frames and separators to compensate for poor control layout or alignnment.
Do not mix framed and unframed groups in the same window.
Do not nest one frame inside another. This results in visual clutter.