From the focusables in its domain, a focus manager keeps at most one of them selected. Key events to this manager are routed to the selected focusable. As this focus manager gains and loses focus, it fires focus and blur events on the selected focusable.
To help explain the need for a hierarchy (rather than a flat domain of focusables), and the difference between selected and focused, consider an application with a windowed UI, with a main window and a chat window. In the main window are multiple tabs, including an explorer tab with a tree control of resources, and an editor tab for an open resource. If focus is in the chat window, and some signal occurs to place application focus on a resource in the tree control (e.g., a click event occurs on it), then that resource demands application focus (using {@link #ensureGlobalFocus()}. This causes it to become the selected resource in the domain of the tree control, the explorer tab becomes the selected tab in the domain of tabs, and the main window becomes the selected window in the domain of windows (stealing selection and focus from the chat window). Additionally, each of those objects becomes focused, which means that key events will be routed to them (top down). If application focus is moved back to the chat window, the explorer tab remains the selected tab in its domain, and the clicked-on resource remains the selected resource in its domain. The selected window transitions from the main window to the chat window.
The tree nature of focus managers is to enable modular UIs. The distinction between selected and focused is so that selection can remain persistent despite application focus moving around. The only constraint between selection and focus is that, for the deepest focusable with application focus, all its ancestors (including itself) are both focused and selected.
| |
| |