Keyboard navigation is unintuitive

[Aloso]

If I don't know which shortcuts I have to press (e.g. Esc to move focus away from a text input), this GUI framework is not usable with a keyboard. Please make sure it behaves the same as other GUI frameworks, so it can be used without reading a manual.

Here are some things I expect from a GUI:

• When a text input is focused, Tab focuses the next widget and Shift+Tab focuses the previous widget. There should not be the need to press Esc
• When pressing Tab and there is no next widget, focus the first widget. Pressing Shift+Tab when there is no previous widget focuses the last widget.
• Clicking (or pressing the left mouse button down) on a widget focuses the widget
• Activating a widget with a keyboard shortcut (e.g. Alt+1 in the gallery) focuses the widget
• The menu bar usually isn't part of the tab order, it can only be focused with Alt+...
• When opening a menu in the menu bar and closing it again, focus is returned to the previously focused widget
• Pressing Esc doesn't remove focus from the active widget

Please consider adopting this behaviour.

[dhardy]

Great feedback!

When a text input is focused, Tab focuses the next widget ...

This precludes being able to insert tab stops... except where specially handled (e.g. a text editor), thus leading to surprisingly different behaviour there. But sure, existing tools are this way for a reason.

Clicking (or pressing the left mouse button down) on a widget focuses the widget

This conflicts with the design goal of not making multiple input methods (keyboard, mouse, touch) interfere with one another — though probably that goal is mis-guided.

What if no widget is yet focused — should it set focus?

[Aloso]

What if no widget is yet focused — should it set focus?

Yes; I believe that's what browsers and other toolkits do.

[dhardy]

Clicking (or pressing the left mouse button down) on a widget focuses the widget

What about touchscreen input? The problem here is that one can potentially touch multiple controls at once, potentially even from multiple users. But, I guess for consistency it makes sense to set nav focus on touch input too, and can't really see any problems (other than simultaneous keyboard and touchscreen input, which doesn't usually happen).

Edit: I've implemented this with config options.

[dhardy]

@Aloso this should all be done. Would you like to test? There are a lot of finicky details so I may have missed some.

[Aloso]

@dhardy thanks for working on this! I now tried it with the latest commits. Almost all my concerns have been addressed!

Here are the remaining issues I identified:

• When clicking somewhere outside of focusable widgets, the previously focused widget loses focus. Most other GUIs don't lose the focus in that situation (the exception being websites).

• When clicking on a menu item and then moving the cursor to the right side of the menu bar, the menu is closed:
  

• When opening a menu item with the keyboard, Esc restores focus to the previously focused widget. However, if the menu item is opened and/or closed by clicking on it, the focus isn't restored afterwards.

[dhardy]

Thanks for the additional reports; these should be addressed by #236.

One thing I'm not quite sure what to do about: focus regarding the ScrollLabel. It is not a key_nav widget so cannot receive focus via the keyboard, but does take selection focus when text is selected, which updates key-navigation focus (to point to itself — though not visually represented, it means that the next Tab widget will be the one after the scroll-label). The next PR makes it only take focus when selecting, not when clicking or deselecting. Is this appropriate?

Another slight oddity is making sure commands like Ctrl+C and Escape affect selected text even though another widget may have navigation focus. I think I got this right. Curiously a ScrollLabel supports Ctrl+A to select all text, but only when it has navigation focus.

[dhardy]

Found another issue:

• clicking on the slider track causes nav focus, but clicking on the slider handle does not

Edit: fixed by #240.

[dhardy]

I believe all issues are fixed.