Slint UI that can be controlled using 6 buttons (arrows, enter and escape)

[tjallingt]

Hi,

I would like to know if there is more information (or just peoples ideas) regarding using SLint for a UI that can be controlled using just 4 arrow keys and enter and back.

Slint does have virtual keyboard support, which will help a lot for this project but I was wondering if there are recommendations for managing and moving focus. Ideally it should be possible to control the focus in a more advanced way than the standard accesibility options from slint.

Some way of having a vertical list, horizontal list and a grid in which the focus of items can be controlled?

Would slint be a good fit for such an interface? Should the focus management be implemented in the slint language or would it be recommended to implement it in rust? could we add (custom) primitives to allow more control over focus than slints built-in accesibilty layer?

[ogoffart]

Right now Slint can only do tab. So if you'd like to do that, you'd need to implement that keyboard navigation yourself by handling the key up/down/left/right events to change the focus.

[bart-sensirion-qm]

That seems logical, but filtered for FocusScope elements with keypad-navigation: true; the same edge case where one such element has no way to be reached from one of those other elements could still appear (I think).

[tronical]

Hmm, could you describe how such a scenario would look like, in terms of placement on the screen?

[bart-sensirion-qm]

Depending on how the next element is determined, the corner elements could move focus to each other which makes the middle element unreachable.

[tronical]

Yes indeed. This would require say pressing two keys at the same time (diagonal movement). But I guess what you're saying is that the application should be able to decide if say the bottom right element is focused and the user presses left, if that should or should navigate via the center element or not?

Maybe for such setups it would make sense to allow an optional override? But I see there are also gaps. So for example:

top-left := FocusScope {
    // ...
    keypad-navigation: true;
}
top-right := FocusScope {
    // ...
    keypad-navigation: true;
}
center := FocusScope {
    // ...
    keypad-navigation: true;
    // What should be the override here? Up or down?
}
bottom-left := FocusScope {
   // ...
    keypad-navigation: true;
    keypad-navigation-right-towards: center; // right should navigate via center
}
bottom-right := FocusScope {
    // ...
    keypad-navigation: true;
    keypad-navigation-left-towards: center; // left should navigate via center
}

[bart-sensirion-qm]

I don't know if you should fix it that way but I do think that some automated analysis should be done e.g. looking up all the targets for each node on a screen and building a graph to see if all nodes are connected. Maybe even add a viewer for that graph.

For the fix, maybe just showing a warning for unconnected elements will be enough and people should fix it themselves by changing their UI. Nudging elements or invisibly extending the middle element into a horizontal or vertical line so it will 'naturally' get focus from other elements. Or we could explicitly name the element to go to for each direction to override automatic selection.

I don't think this is an issue that will pop up often as most UI is easily navigable with four directions. It's just that we'd need to make sure it doesn't happen when this is our only way to navigate the page so some automated way to detect it is crucial.