Move keyboard focus with tab to any interactive widget

[emoon]

It would be great to have support for keyboard only navigation (i.e a concept of focused widget and the ability to move focus to another one) that would allow "tab" key for example to move to the next widget and "return" would act as press, etc.

This in return would make it quite easy to add gamepad support as it would just behave as a subset of a regular keyboard.

[emilk]

Switching between input fields with tab and shift-tab has now been implemented on master. Pressing enter in a singleline text edit box now sets the kb_focus_lost flag in the Response object, so you can use that.

[emoon]

Tested this today and it seems that I wonder if it would be possible to support for all widgets (such the way it works in a regular gui) and not just for input fields?

[emilk]

That would be nice yes, but it is not very high on my priority list right now

[emoon]

I think I will try to implement this unless it's too complicated. Any pointers before I start?

[emilk]

Wow, that would be great!

The feature that handles focus of TextEdit:s is called "kb_focus".

I think first of all, let's split this into two tasks:

A) tab also moves kb_focus to buttons, checkboxes, sliders etc
B) gamepad support for moving kb_focus up/down/left/right

Let's start with A, and postpone B until A is done.

---

First we have some design problems:

When clicking a TextEdit we get a cursor in it, and it is obvious it has kb_focus. If we then press tab and move focus to a checkbox, how do we indicate it has focus? We need a uniform language for focus. To start, the easiest would probably be some sort of thing colored rectangle around the widget with kb_focus (including TextEdit:s). That or changing its fg_color. This accent could perhaps become confusing when it comes to SelectableLabel which uses color to indicate "this is selected".

We can give kb_focus to a TextEdit by clicking it. Can we give kb_focus to a checkbox or slider by clicking it? I strongly vote no on this one, as it would give add some weird accent to the last button you pressed all the time. Instead I propose that the only way to give kb_focus to a button is by using tab/shift-tab.

What happens when a slider has kb_focus? Arrows to move the slider one pixel? Enter to edit the value?

How do we toggle/click buttons? Enter? Space?

---

As for the implementation:

Look at TextEdit. It uses interested_in_kb_focus to communicate that it want tab to select it. It asks if it has focus with has_kb_focus. So most buttons would just need to call interested_in_kb_focus and then ask has_kb_focus. It should be pretty straight-forward.

For the accent: whatever style you go with, make sure it is stored in struct Visuals

---

Good luck!

If you want to discuss this in more detail, you can find me in the Egui discord channel at https://discord.gg/vY8ZGS292W

[emoon]

Cool. Thanks! I agree with your thoughts on focus above, I will start to hack around and see where I end up and ping you on discord if needed :)

[emoon]

Some initial testing with checkbox (ignore the red colors for the radiobuttons, it was me playing around) :)

[ndarilek]

Any new progress on this? It's something I need too, so I may take a crack at it.

[emoon]

I haven't got around to do it 😞 if you want to take a stab at it that would be great!

[ndarilek]

I'll poke it and try making some progress. Quick semi-related question, though. I've never worked with immediate mode GUIs. I guess the way you respond to widget changes is by checking their properties conditionally, but if you wanted a separate piece of code that responds to all focus changes, how is that done? Di you track the currently focused widget on something like the context, then have code to poll that and react when the value changes? If that's accurate, has something like that been implemented already? And if not, would it be best on the context, memory, or somewhere else? I'll need it for my use case, so I want to get that right if it hasn't already been done. Thanks.

[emilk]

@ndarilek keyboard focus is indeed part of egui::Memory, in particular these functions: https://github.com/emilk/egui/blob/master/egui/src/memory.rs#L202-L244

Basically what is needed for this issue is that all interactive widgets call interested_in_kb_focus, and then checks has_kb_focus to see if they have kb_focus, and if so paint a rectangle around them and maybe response to space/return (e.g. to press the selected button). If you are interested in working on this I suggest you check out how text_edit.rs are calling the kb_focus methods. Since a lot of widgets will do similar things (request focus, check focus, paint frame when selected, ...) it would make sense to create some helper functions for it.

[emilk]

I added the accessibility and high priority labels since this is crucial for the accessibility story (#167)

[emilk]

I'm gonna start working on this

[emoon]

Awesome! Sorry I didn't manage to get around to do it, but real life has gotten a bit in the way :/

[emilk]

@emoon no worries, I know the feeling :)
Please prioritize real life to egui - I sure do!