Kaz Wesley 828d160c56 Introduce new focus APIs, and use for CB (#7167) ... Introduce new APIs for managing focus and using focus to inform delivery of keyboard events. Use new APIs to implement the following behavior: Focus: - If the component browser is opened, its initial state is *focused*. - If the node input area's text component is clicked, the component browser's state becomes *blurred*. - If a click occurs anywhere in the component browser, the component browser's state becomes *focused*. Event dispatch: - When the component browser is in the *focused* state, it handles certain keyboard events (chiefly, arrow keys). - If the component browser handles an event, the event is not received by other components. - If an event occurs that the component browser doesn't handle, the node input area's text component receives the event. [vokoscreenNG-2023-06-29_10-55-00.webm](https://github.com/enso-org/enso/assets/1047859/f1d9d07c-8c32-4482-ba32-15b6e4e20ae7) # Important Notes Changes to display object interface: - **`display::Object` can now be derived.** - Introduce display object *focus receiver* concept. Many components, when receiving focus, should actually be focused indirectly by focusing a descendant. - For example, when the CB Panel receives focus, its descendant at `self.model().grid.model().grid` should be focused, because that's the underlying Grid View, which has its own event handlers. By allowing each level of the hierarchy to define a `focus_receiver`, focus can reach the right object without the CB panel having to know structural details of its descendants. - When delegating to a field's `display::Object` implementation, the derived implementation uses the child's `focus_receiver`, which will normally be the correct behavior. **Changes to `shortcut` API**: - New `View::focused_shortcuts()` is a focus-aware alternative to `View::default_shortcuts()` (which should now only be used for global shortcuts, i.e. shortcuts that don't depend on whether the component is focused). It's based on the *Keyboard Event* API (see below), so events propagate up the focus hierarchy until a shortcut is executed and `stop_propagation()` is called; this allows sensible resolution of event targets when more than one component is capable of handling the same keypress. Keypress dataflow overview: DOM -> KeyboardManager -> FrpKeyboard -> KeyboardEvents -> Shortcut. Low-level keyboard changes to support Focus: - New `KeyboardManager`: Attaches DOM event handlers the same way as `MouseManager`. - New *Keyboard Event* API: `on_event::<KeyDown>()`. Events propagate up the focus hierarchy. This API is used for low-level keyboard listeners such a `Text`, which may need complex logic to determine whether a key is handled (rather than having a closed set of bindings, which can be handled by `shortcut`). - FRP keyboard: Now attaches to the `KeyboardManager` API. It now serves primarily to produce Keyboard Events (it still performs the role of making `KeyUp` events saner in a couple different ways). The FRP keyboard can also be used directly as a global keyboard, for such things as reacting to modifier state. Misc: - Updated the workspace `syn` to version 2. Crates still depending on legacy `syn` now do so through the workspace-level `syn_1` alias.		2023-07-26 22:13:48 +00:00
..
src	Introduce new focus APIs, and use for CB (#7167)	2023-07-26 22:13:48 +00:00
Cargo.toml	Vector Editor first visual implementation (#6245)	2023-04-19 04:26:01 +02:00