Discussion of GTK focus bugs

[Eben]

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.

[marco]

Eben, is there any of these which you consider necessary for Trial-2?

[Eben]

Well, obviously implementing proper focus for the canvas is a whole separate mountain to climb. I think the other problems mentioned can be summarized as my strong disfavor for GTKs mixed use of arrow keys and tab for switching focus. It seems unclear and complex to me. Is there a logical approach we can follow to isolate the use of tab for focus switching, and arrows solely for interacting with the currently focused control?

I wouldn't argue that's necessary for trial 2, but we definitely need to get this straightened out thereafter.

[marco]

Moving to Trial-3 then. We can discuss this just after Trial-2.

[Eben]

Another example:

I'm really grateful that you can now scroll the Journal with the arrow keys, but why on earth does the focus jump up to the search field when I reach the top of the list? I'd expect to remain inside the entry list at all times, unless I explicitly decide to focus another control.

[marco]

I'd say FRS. The only thing which we might give a try to for Trial-3 is to not focus the toolbars on click. Eben feel free to open a separate ticket about that if you think it's important and we can triage that open separately.