Menu bar keyboard/hover dispatch gaps (GTK arrow keys, TUI Alt conflicts, TUI hover)

[JDonaghy]

Context

Smoke testing the #301 menu bar → quadraui migration revealed three vimcode-side event dispatch gaps. None are quadraui primitive issues — they're all about how vimcode routes events to/from the menu bar.

Issues

1. GTK: Arrow keys don't navigate menu after Alt+F activation

Repro: GTK mode → Alt+F opens File menu → press Right arrow → cursor moves in editor instead of switching to Edit menu.

Cause: The GTK key handler doesn't check engine.menu_open_idx to route arrow keys (Left/Right/Up/Down/Enter/Escape) to the menu system when a dropdown is open. The handle_menu_bar_key() path is likely missing or not wired.

Fix: When engine.menu_open_idx.is_some(), intercept Left/Right (switch menu), Up/Down (navigate dropdown items), Enter (activate), Escape (close) before passing keys to the normal handler.

2. TUI: Some Alt+letter keys are already bound

Repro: TUI mode → Alt+E or other Alt+letter combos may trigger sidebar resize or other existing bindings instead of opening the corresponding menu.

Cause: vimcode's TUI key handler binds Alt+Left/Right for sidebar resize, and potentially other Alt combos. These take priority over menu bar Alt activation.

Fix: When menu_bar_visible, Alt+letter should check MenuBar::find_alt_target() first (or at least for the 7 menu letters: F/E/V/G/R/T/H). This may need a priority decision — menu bar Alt activation vs existing Alt bindings.

3. TUI: Hover-to-switch doesn't work

Repro: TUI mode → click File to open dropdown → move mouse to Edit label → dropdown doesn't switch.

Cause: The TUI mouse handler doesn't wire MouseMoved events to check MenuBarLayout::hit_test() for hover-to-switch when a dropdown is open. GTK has this via EventControllerMotion::connect_motion but TUI lacks the equivalent.

Fix: In the TUI handle_mouse() for MouseEventKind::Moved, when engine.menu_open_idx.is_some() and row == 0, hit-test against the cached menu_bar_layout and switch menus on MenuBarHit::Item(idx) where idx != current.

Notes

• All three are pre-existing behavior gaps, not regressions from Migrate TUI menu bar to quadraui::MenuBar primitive #301. The old bespoke code had the same issues (GTK arrow keys never worked in menus, TUI never had hover-to-switch).
• These are vimcode event-routing issues, not quadraui primitive gaps. quadraui#51 (CommandCenter) is correctly scoped to paint+layout+hit_test.

Priority

Low — menu bar keyboard navigation is a polish item, not a blocker for the Cross-Platform UI Crate milestone.

[JDonaghy]

Partial resolution from Session 353:

• Item 3 (TUI hover-to-switch): Shipped — MouseEventKind::Moved on the menu bar row hit-tests against MenuBarLayout and switches menus when a dropdown is open. 18 lines in src/tui_main/mouse.rs.

• Item 1 (GTK arrow keys): Deferred to Migrate menu dropdown from bespoke DrawingArea to quadraui::ContextMenu #319. Attempted bespoke key interception in GTK but it fights with the dropdown DrawingArea's redraw cycle (highlights flash then disappear). The proper fix is migrating the dropdown to quadraui::ContextMenu, which gives keyboard nav for free — same pattern as the working quadraui samples.

• Item 2 (TUI Alt+letter clashes): Filed as TUI: default Alt+letter keybindings clash with menu bar shortcuts #318. The Alt+letter menu activation already works when menu_bar_visible; the issue is that other Alt bindings (Alt+T for tab switcher) shadow menu shortcuts when the bar is hidden.