Discussion of GTK focus bugs
|Reported by:||Eben||Owned by:||dcbw|
|Deployments affected:||Action Needed:|
As I've been playing around with things, I've seen a lot of entirely non-intuitive shifts in focus. I'm not sure which of these are bugs and which are default GTK behavior, but this ticket serves as a place to report focus issues and sort out which are bugs, which are expected behavior, and what we do about them in either case.
Text fields: As a prime example, I'd like to discuss the basic single line text field. Take, for instance, the text field used to name any activity. When this text field has focus, the left and right arrow keys move the cursor left and right as expected. The up arrow key, which should move the cursor to the beginning of the line, does nothing. The down arrow key, which should likewise move the cursor to the end of the line, instead removes focus from the textfield entirely, jumping instead to a tab, or when there is no tab, into the activity itself.
Popups: Likewise, the search toolbar in the journal allows jumping from one option menu to the next. This should be done with tab. Left and right arrows should not have an action when the popup is closed; They should be reserved to show and hide submenus when it is open. Up and down should, obviously, move through the options in the list when it is opened, as they do now. However, when the list is not open, they should have the action of opening it. Right now, they simply jump through the items without opening the list.
Toolbar: When the focus is inside the toolbar, for instance in the name entry field, the tab button completely bypasses all of the other buttons within the toolbar, jumping immediately to the tabs themselves, and then into the activity. The focus should run through all items in the selected toolbar before dropping down to the tab bar.
Journal List View: I'm not sure how to categorize this, but there is no keyboard support at all, it seems, in the Journal. The up/down arrows jump into and out of the main view, instead of doing any kind of scrolling at all. At the very least, we need to support scrolling in this view. In truth, we need internal focus within the entries in order to allow making selections, resuming activities, and navigating to detail view.
These are a few of the problems I've found so far. Most of these seem to have a common root: As a general rule, the arrow keys should never be used to switch focus between two controls. The tab key serves this purpose nicely. The arrow keys should always be reserved for navigation within the focused widget. This keeps a logical separation between the arrow keys and the tab key, and eliminates the possibility of losing focus, inadvertently switching contexts, or otherwise confusing the navigation of the interface via the keyboard.