In native UI, cannot focus most widgets, control them via keyboard, or tab between widgets

[nyanpasu64]

I cloned iced master 2ce5df084456a92ed1a228738816cf8398b2e918 and built the examples on Windows. While testing keyboard-based interaction, I found that iced doesn't perform keyboard interactions for most widgets, that native or desktop-web toolkits generally have.

In Pokedex, when I click on the button (and optionally drag my cursor off of it), it does not put keyboard focus onto the button, and pressing Enter or Space does not activate the button.

You cannot focus a slider and use arrow keys to adjust it either. This can be seen in the second page of the tour app. (#366 says this is fixed, but I haven't had any luck.)

You cannot switch between radio buttons using the keyboard either. (third page of tour)

You cannot focus a checkbox and use Space (or Enter?) to toggle its value.

Page Down, keyboard arrow keys, and space do not move the scroll area either. I'm not sure how people expect native apps to treat this.

• Help browsers and office apps work more like documents or web pages, and respond to Page Down.
• In Okular's settings dialog (Qt), Page Down scrolls the dialog if the background is focused, or changes a spinbox widget value if it's focused. I'm not sure I like how Qt handles keyboard input (Qt's handling of scrolling is worse).

In a text box, Tab doesn't switch to a different widget.

There may be more discrepancies with native UI that I haven't found yet.

[semtexzv]

Commenting a way of approaching this.

Each view has a focusable attribute, which determines whether it can individually hold focus. Primitive edit views like TextInput have set this to true, views performing layout have set this to false.

By tabbing, the focus simply jumps through the widget tree similar to pre-order traversal, with widgets filtered by focusability,

a =  FocusGroup (focusable = true) {
   b = TextInput(focusable = true)
   c = TextInput(focusable = true)
}

In this tree, 4 consequent focus switches will do following actions

No focus => Focus(a)
Focus(a) => Focus(b) 
Focus(b) => Focus(c)
Focus(c) => No focus

If a widget is destroyed while having focus, the focus is lost. Whether the focus continues from similar place in the tree, or starts from root, I don't know.

This is similar to android implementation of focus. However, android supports directional focus navigation, not only ordering of the focus ( think left button focusing what's left of the view spatially).

However, this probably depends on persistent widget tree or something similar #553.

[adsick]

I've got stumbled across this too.