Keyboard navigation #24

New issue

Open

opened 2025-01-15 06:29:50 +00:00 by abart27 · 1 comment

abart27 commented

2025-01-15 06:29:50 +00:00

(Migrated from github.com)

Implement tab focusing and focus outlines.

FramePerfection commented

2025-08-30 16:42:36 +00:00

(Migrated from github.com)

"Focus next element" and "Focus previous element" should be registered as actions in the action registry.
The UID of a control may be used as a simple "default" mechanism to determine the focus order.
Optional next_focus_element_uid and previous_focus_element_uid parameters could be assigned to override specific tab focus order. (It'd be the user's responsibility to connect controls "properly", such that going back and forth works as expected, though.)
Optionally, a control grouping system could be implemented, where the group itself is an invisible control (so that it has a uid) and additionally identified by a path (similar to action paths), with special additional actions "Enter group" and "Exit group".
Controls would get an additional optional parameter group_path to identify which group they belong to.
The "Focus next element" and "Focus previous element" actions would then only cycle through controls that belong to the currently selected group.

If the last point turns out to be too complicated in design, it may be better to handle that in a separate issue. However, I do believe that streamlined grouping of controls is essential to making keyboard navigation intuitive and fast, so it should be considered eventually.

This has become relevant to me now that the Action API exists, in that this would greatly supplement keyboard control in the SM64Lua (and probably everywhere else as well). I have some thoughts on the details for how this could be implemented: - "Focus next element" and "Focus previous element" should be registered as actions in the action registry. - The UID of a control may be used as a simple "default" mechanism to determine the focus order. Optional `next_focus_element_uid` and `previous_focus_element_uid` parameters could be assigned to override specific tab focus order. (It'd be the user's responsibility to connect controls "properly", such that going back and forth works as expected, though.) - Optionally, a control grouping system could be implemented, where the group itself is an invisible control (so that it has a uid) and additionally identified by a path (similar to action paths), with special additional actions "Enter group" and "Exit group". Controls would get an additional optional parameter `group_path` to identify which group they belong to. The "Focus next element" and "Focus previous element" actions would then only cycle through controls that belong to the currently selected group. If the last point turns out to be too complicated in design, it may be better to handle that in a separate issue. However, I do believe that streamlined grouping of controls is essential to making keyboard navigation intuitive and fast, so it should be considered eventually.