[Contents] [Index] [Next] [Previous]

The Keyboard Focus Model


A typical workspace can contain many windows. Each window will receive input from the keyboard, the mouse, or both. The window that receives keyboard events has the input focus. Indeed, when keyboard input is directed to a window, it is actually received by some control within the window. The keyboard focus model determines which window in the workspace and which component within that window gets each keyboard input. The keyboard focus may also be referred to as the input focus.

In order to avoid conflicts, the window manager must allow only one window to have the keyboard focus at a time. The window with the keyboard focus must be highlighted in some way, usually by a change in shade or color to the window border. Each application must allow only one component at a time to have the keyboard focus within the window that has the keyboard focus.

The keyboard focus model is defined by a focus policy. A focus policy is a specific mechanism for moving the focus among windows and components. The focus policy can be different between windows than it is within windows. This section only attempts to describe the focus policies; however, their impact on window managers, applications, and components is described in detail where it applies. It is sufficient at this point to note that window managers, applications, and new components must support both explicit and implicit focus policies. Window Manager Design Principles describes in detail how to move the focus among windows that use explicit and implicit focus policies.

Implicit Focus

In the implicit focus policy, the keyboard focus tracks the mouse pointer. No explicit action (other than mouse motion) is performed to set the keyboard focus in the implicit focus model. When an implicit focus policy is used at the window level, keyboard events are sent to the window that the mouse pointer is in. When an implicit focus policy is used within a window, keyboard events are sent to the component that the mouse pointer is in. In implicit mode, the keyboard focus tracks the mouse pointer. Because of this, there is no way to move the keyboard focus from the keyboard using implicit mode. Implicit focus is sometimes referred to as pointer, track pointer, or track listener policy, or as being real-estate driven. In this focus policy, the location cursor for keyboard events does not need to be shown except in components like Text, in which keyboard input is common; however, the application can show it.

Explicit Focus

The explicit focus policy requires the user to explicitly select which window or component receives the keyboard focus. In explicit focus mode at the window level, a user moves the keyboard focus to a window by pressing BSelect while the mouse pointer is over the window. Simply moving the mouse pointer over a window does not give the window the keyboard focus. Because of this, explicit mode is often called click-to-type. In explicit mode within a window, a user generally moves the keyboard focus to a specific component within a window by pressing BSelect over the component. Pressing BSelect must not move focus to a component that is not traversable or does not accept input. Pressing BSelect in a component that is used only to change the visible portion of another component, such as a ScrollBar or Sash, should act on that component but should not move focus to it. In this focus policy, the location of keyboard focus must be shown by a location cursor.

In explicit mode, focus can also be moved among windows by the keyboard using , , , and .

In explicit mode, keyboard focus moves explicitly among the components in a window as well as among the windows. Moving the keyboard focus among components in a window using the keyboard is called component navigation. Keyboard events go to the component in the window with the keyboard focus. Keyboard focus is moved among components using , , , , , , , , , and Internal window navigation is described in detail in Navigation.

If the focus policy is implicit, an implementation can still enable keyboard-based operations that explicitly move the location cursor. It must at least implement the special cases for Menu traversal as described in Navigation. (or if is not available) moves the cursor to the MenuBar. (or if is not available) pops up a Popup Menu.