Open tronical opened 1 week ago
For this, the behavior of text editors may be relevant when the end user uses vertical arrow keys. States in chronological order with |
representing the cursor:
abcd|f
ab
abcdef
abcdef
ab|
abcdef
abcdef
ab
abcd|f
The text editor remembers a "theoretical" (as opposed to practical) horizontal cursor position, and, if no horizontal navigation overrode it, it derives the practical cursor position from the theoretical cursor position on every vertical navigation to a new line.
In the same way, Slint could perhaps remember the position and bounds of the element that it navigated away from, and, if another navigation action is what directly follows, this information is used to determine the most suitable next element to focus to stay on the navigation path as best as possible, even if an intermediately focused element had the potential of leading the navigation path astray.
Excellent idea!
As a follow-up to https://github.com/slint-ui/slint/discussions/5550 we could add support for the following feature to Slint:
keypad-navigation: true;
boolean property toFocusScope
.FocusScope
receives an ArrowUp/Down/Left/Right key andkeypad-navigation
istrue
, then we could search from the root of the window through all elements that areFocusScope
instances, havekeypad-navigation
set totrue
, and select the one that is nearest in the given direction.focus()
.