This chapter describes the component activation model, which determines how to act upon previously selected elements.
Once users select an object, they can perform an action on it by using the components available in the application, or by using one of the selection actions described in Chapter 4, "Selection." Using components to perform actions on a selection is called activation.
Components are used to send information to the underlying application. For example, a Text component is used to send complicated information to the application, but most components (for example, PushButtons) are simply used to start an application process. In fact, even a complicated component like Text may need to tell the application that the user is finished entering information.
Components that start some application process are used following the activation model, which this chapter divides into the following areas:
The basic activation model mimics real-life button activation in that pressing on a button activates it. The user selects a button with the location cursor, which can be moved among components following the navigation model described in Chapter 3, "Navigation."
Clicking BSelect on the button must activate the button.
<Select> or <Space> on a button with the focus must activate the button.
<Select>,<Space>,<Enter>,or <Return> on an activatable Menu entry with the focus must activate the entry.
When BSelect is pressed over a button, the appearance of the button must change to indicate that releasing BSelect activates the button. If, while BSelect is pressed, the pointer is moved outside of the button, the visual state must be restored. If, while BSelect is still pressed, the pointer is moved back inside of the button, the visual state must again be changed to indicate the pending activation. If BSelect is pressed and released within a button, the button must be activated, regardless of whether the pointer has moved out of the button while it was pressed.
An implementation can allow BSelect Click 2+ (multiple mouse button clicks) to be treated as a single mouse button click on a per-component basis; that is, all clicks except the first are discarded. In an application where double-clicks are used heavily, this can help prevent the user from unintentionally activating a button twice.
A selectable element of a collection can be activatable; for example, a link icon, or an audio annotation in Text. If so, BSelect Click, <Select>,and <Space> (except in Text) must select it. BSelect Click 2 must select and activate it.
An accelerator is a key or key combination that invokes the action of some component regardless of the position of the location cursor when the accelerator is pressed. Accelerators are most commonly used to activate Menu items without first posting the Menu.
If the button with the accelerator is within a primary or secondary window, or within a Pulldown Menu system from its MenuBar, it must be activatable whenever the input focus is in the window or the MenuBar system. If the button with the accelerator is within a Popup Menu system, it must be activatable whenever the focus is in the Popup Menu system or the component with the Popup Menu.
Applications can provide accelerators for any button component. Implementations must support accelerators in PushButtons and ToggleButtons that are in Menus. If a button has an accelerator, the accelerator must be shown following the label of the button.
A mnemonic is a single character that can be associated with any component that contains a text label. The label must contain the character, and the character must be underlined within the label, except in language environments in which underlining is unavailable. If a label does not naturally contain the character of the mnemonic, the mnemonic must be placed in parentheses following the label. Labels can also be sequentially numbered, and the number can serve as the mnemonic. Labels that are duplicated within an application should be given the same mnemonic. Mnemonics must be case insensitive for activation. Either an uppercase or lowercase letter can be underlined in the label.
When the location cursor is within a Menu or a MenuBar, pressing the mnemonic key of a component within that Menu or MenuBar must move the location cursor to the component and activate it. If a mnemonic is used for an OptionButton or for a CascadeButton in a MenuBar, pressing <Alt> and the mnemonic anywhere in the window or its Menus must move the cursor to the component with that mnemonic and activate it. Implementation must support mnemonics for OptionButtons, PushButtons in a Menu, ToggleButtons in a Menu, and CascadeButtons in a Menu or MenuBar.
Mnemonics can also be used to select and deselect elements within a component as described in Section 4.1.10, "Using Mnemonics for Elements."
Some Menus have TearOffButtons as their first elements. A TearOffButton is like a PushButton with the special interaction of converting a Menu into a DialogBox; that is, tearing off the Menu from its CascadeButton. TearOffButtons must follow the rules for the basic activation model described in Section 5.1, "Basic Activation." For example, pressing and releasing BSelect in a TearOffButton tears off the Menu and transforms it into a DialogBox.
TearOffButtons also have a second activation mechanism. Once a Menu with a TearOffButton is posted, pressing BTransfer in the TearOffButton must start a TearOff action. As long as BTransfer is held, a representation of the Menu must follow the movements of the pointer. Releasing BTransfer must end the TearOff action by unposting the Menu system, creating a new window at the current pointer location with the contents of the Menu, and give focus to the new window in explicit pointer mode. The contents of the new window should not include the TearOffButton.
Pulling down or popping up a Menu that is currently torn off should not affect the torn off Menu. If the same Menu is torn off again, using either basic activation or TearOff activation, the existing torn off window should be removed prior to the creation of the new window. A torn off Menu is closed by pressing <Cancel> while focus is in the window or by using the TearOff Menu's window Menu.
Help is generally invoked from selections in the Help Menu of the MenuBar. In addition, <Help> on a component must invoke any context-sensitive help for the component or its nearest ancestor with context-sensitive help available. Within DialogBoxes, applications should provide context-sensitive help for the DialogBox as a whole. <Shift> <Help>
should switch into context-sensitive help mode if it is available. In the context-sensitive help mode, the pointer shape changes to show the mode, and help is provided for the next component that the user selects, after which context-sensitive help mode is exited.
Any window can have a default action, although default actions are most frequently used in DialogBoxes. A DialogBox should have a default action associated with it. The default action in a window can change depending upon which component has the focus. The current default action should correspond to the action of some PushButton, called the current default PushButton of the window.
The current default PushButton must be highlighted in some way, usually by displaying a border around it. When the focus is on a PushButton, its action must be the default action, and the PushButton must show default highlighting. If the default action in a window varies, some PushButton must always have default highlighting, except when there is no current default action.
In a DialogBox, default PushButtons should be in the bottom area of PushButtons of the DialogBox. However, if a particular default action is associated with a cluster of controls in a window, the corresponding default PushButton can be located adjacent to the cluster.
When an explicit focus policy is in use, and the focus is outside the window, default highlighting should be placed on the PushButton whose action corresponds to the default action that would result from moving the focus to the window by using keyboard navigation among windows.
The default action of a DialogBox is activated according to the following rules:
If the focus is in a window, <Enter> and <Ctrl> <Return> must invoke the default action, and, if the focus is in a component in a window other than multiline Text, <Return> must invoke the default action. These actions must have no other effect on the component with the focus, unless the default action has some effect.
In list-like and graphics-like collections, when the location cursor is not on an activatable element, BSelect Click 2 should act like BSelect Click, followed by invocation of the default action.
When the focus is on a ToggleButton not used for expert activation, BSelect Click 2 should activate the ToggleButton and then perform the default action.
Except in the middle of a button motion operation, <Cancel> anywhere in a DialogBox must be equivalent to activating the Cancel PushButton in the DialogBox.
Some activatable elements, usually PushButtons and ToggleButtons, can have expert activation actions associated with them. BSelect Click 2 (that is, double-clicking the element) should activate any expert action for the element. Expert actions should only be available in a Panel of PushButtons or in a Panel of RadioButtons where one of the RadioButtons is always on. When the focus is on a button used for expert activation, there must be no default action available, unless the default and expert actions are the same.
The expert action should include the regular action of the component in a more global manner. For example, a Panel of RadioButtons in a drawing application could include a tool for turning on the erase cursor. Selecting the
turns on the erase cursor. Double-clicking the RadioButton could erase the drawing area.
If a component with an expert action is selectable, activating the expert action must first select the component and then perform the expert action.
To support new users and keyboard-only users, expert actions must only be shortcuts to application features available elsewhere.
Two special actions can be used with activation: previewing and autorepeat. When BSelect is pressed and held over a PushButton or ToggleButton, the application can present information in some way that describes the effect of activating the button. This is called previewing. The information must be removed when the user releases BSelect. Applications should provide a means to disable previewing for experienced users.
PushButtons can also autorepeat; that is, when BSelect is pressed and held, the PushButton activates and continues to activate at regular intervals until the PushButton is released. Autorepeating buttons should continue to repeat even when the pointer moves outside the button while the button is pressed; however, applications can suspend the activation of the button until the pointer is moved back inside of the button. While the button is active, it should be drawn in the active state.
<Cancel> is available in most contexts to stop or cancel the current interaction. <Cancel> has an impact on the following contexts:
Pressing <Cancel> during a mouse-based selection or drag operation must cancel the operation.
Pressing <Cancel> during a mouse-based scrolling operation must cancel the scrolling action and return the system to its state prior to the start of the scrolling operation.
Pressing <Cancel> anywhere in a DialogBox must be equivalent to activating the Cancel PushButton, if one exists, except during a mouse-based selection or drag operation, in which case it should cancel the operation.
Pressing <Cancel> in a Pulldown Menu must either dismiss the Menu and move the location cursor to the CascadeButton used to pull it down or unpost the entire Menu system. <Cancel> in a Popup Menu, Option Menu, TearOff Menu, or MenuBar must unpost the Menu system.
Pressing <Cancel> while the focus is in a torn off Menu window must close the torn off Menu window.