Change focused widget with arrow keys

[TimonPost]

We have the use case of gamepad control for a user-facing game menu. This PR makes it possible to change widget focus with the keyboard arrows. It allows integrations to convert joysticks to arrow keys in order to toggle between menu items. It does not add support for gamepad events in egui as this seems like a bigger topic that I desire not to touch.

Initially, I examine the currently focused widget to determine the one with the highest dot product when compared to the desired focus direction. Subsequently, I identify the widget that is nearest to the current one. This process enables the selection of the widget in the desired direction which not only possesses the smallest angle relative to the current widget but also maintains the closest proximity.

The widget selection code can be improved over time ofcourse, there are some potential issues right now:

• This solution has no sense of the window it exists in, so if a focusable widget in another window is a better candidate it will pick that one.
• If I click in an input box the Focus::interested_in_focus is not called and thus I do not know what the interactable widgets and their rectangles are. I only know this after using a key like arrow or tab (+shift).

Closes #1250

[emilk]

Exciting!

The navigation works okish, but I left some ideas on how to improve it

[emilk]

please revert the changes in this file. Use egui_demo_app (cargo r) for a better test of your code!

[TimonPost]

Thanks a lot for the feedback!

I updated the selection metric to use the ratio and rectangles but it is still not perfect.

focus_candidates.sort_by(|(_, dot1, len1), (_, dot2, len2)| {
    (len1 / dot1).partial_cmp(&(len2 / dot2)).unwrap()
});
focus_candidates.sort_by(|(_, dot1, _), (_, dot2, _)| dot2.partial_cmp(dot1).unwrap());

Not sorting by dot product afterward results in close-by widgets being picked even while they have a big angle. But sorting by dot product sometimes results in widgets further away but higher dot products being selected.

I wonder if other context needs to be brought in to make a better decision.

I don't know how perfect this feature is to be. It mostly works well. For our use case, we probably design the UI to be simple so that this algorithm works fine.

Another issue is that sometimes it's hard to tell where the focus went as it might be a window behind the current window or some widget in a different panel.

The rectangle thing improves the overall behavior so that was a nice change.

[emilk]

Ah, no that makes sense 👍

[emilk]

There is still plenty of room for improvement, but this is a good start!

[Jakkestt]

It allows integrations to convert joysticks to arrow keys in order to toggle between menu items.
How do you do that?

[TimonPost]

Gotta make some custom logic to achieve that. E.g detect the cardinal directions of the joystick and map them to key combo's