Keyboard event handling

[dhardy]

The current model:

1. The active window calls EventMgr::start_key_event
2. A shortcuts look-up table is used to optionally produce a cmd: Command
3. Given a cmd, try sending to the following targets, stopping after the first to handle the event:
   • The widget with character input focus, if any [e.g. text input in an EditField]
   • The widget with selection focus, if cmd.suitable_for_sel_focus() [e.g. text is selected, Ctrl+C is pressed]
   • The navigation focus, if Alt is not pressed [e.g. a button has focus, Enter is pressed]
   • The active pop-up parent, if any [e.g. a ComboBox menu is open; Down is pressed]
   • The navigation fallback [e.g. ScrollRegion uses register_nav_fallback, allowing scrolling via arrow keys when no other widget handles those keys]
4. If not yet handled and Alt is pressed (or alt_bypass is enabled): look for a matching accelerator key, starting from the deepest open menu
5. If not yet handled:
   • Tab navigates to the next (or previous) target
   • Esc closes the deepest pop-up window, if any

This is reasonably capable, but...

Issue: modifiers

Accelerator keys currently match if other modifier keys such as Ctrl are pressed. Easy to fix (if we have a fixed list of modifier keys).

Issue: custom shortcuts

It should be possible to add applicaiton-defined shortcuts with custom action (not accelerator keys, which are situational and always send Event::Command(Command::Activate)).

These could be used for context menus too. #153

Issue: fallback target

The "one registered navigation fallback" strategy is too limited: it doesn't support multiple fallbacks which handle different keys, nor does it help with programmatic calling with undefined target.

Proposed alternative: use a depth-first search of visible children to look for a handler, per key. This is O(n) in the number of visible widgets (not a problem). It could be implemented by EventMgr, but requires some new API to find only "visible children".

[dhardy]

See also: #404