Migrate GTK click dispatch to FrameHitMap

[JDonaghy]

Summary

Replace handle_mouse_click_msg (~1,228 lines) and handle_mouse_drag_msg (~333 lines) with FrameHitMap::hit_test() for zone detection, then per-surface hit_test() methods for fine-grained resolution. Today vimcode manually computes pixel regions for every clickable surface; the new path gets zone identity from the cached FrameHitMap that ScreenLayout::draw() produces.

What exists in quadraui

• FrameHitMap::hit_test(x, y) -> FrameZone — identifies which surface (Editor, TabBar, Palette, ContextMenu, etc.) contains the point
• Per-surface hit-test methods already used by vimcode: CompletionsLayout::hit_test(), ContextMenuLayout::hit_test(), TerminalSplitLayout::hit_test(), EditorLayout::hit_test(), TabBarLayout::hit_test(), PaletteLayout::hit_test()
• ShellContext::in_sidebar(x, y) / in_main(x, y) for panel zone detection

What to do

1. Cache the FrameHitMap returned by ScreenLayout::draw() (Migrate GTK draw wiring to quadraui ScreenLayout::draw() #446)
2. In mouse handlers, call hit_map.hit_test(x, y) to get the FrameZone
3. Match on FrameZone variants to route to existing engine click handlers
4. Delete manual pixel-region computation in handle_mouse_click_msg (~1,228 lines)
5. Delete manual drag region tracking in handle_mouse_drag_msg (~333 lines)

Files

• src/gtk/click.rs — simplify to FrameHitMap dispatch
• src/gtk/mod.rs — delete handle_mouse_click_msg, handle_mouse_drag_msg

Dependencies

• Migrate GTK draw wiring to quadraui ScreenLayout::draw() #446 (draw wiring migration) — must land first since FrameHitMap is produced by ScreenLayout::draw()

Notes

This is issue 4 of 4 in the GTK AppShell consumption series. Depends on #446. Much of the per-surface hit-test wiring already exists from the hit-test dedup sweep (Sessions 379-380); this issue consolidates the top-level zone detection layer.

[JDonaghy]

Coordinator: Assignment Failed

Machine: dellserver
Status: failed
Exit code: 1
Duration: —

Error

Issue premise stale: the two functions are no longer manual pixel-region computation (already migrated onto cached Layout::hit_test()+quadraui dispatch in prior sessions). The one real target, render::screen_zone_hit_test, can't be safely migrated to FrameHitMap because ScreenLayout::draw() inseparably combines painting+hit-map registration, and GTK's live render_content path (draw.rs is dead code) interleaves 9 throwaway single-surface frames with order-sensitive non-Surface paints -- naive consolidation reorders real Cairo painting with zero visual-regression test coverage to catch it. Requesting a new quadraui issue for ScreenLayout::hit_map() (draw()-without-backend-calls) be filed on JDonaghy/quadraui -- full text in body-file. No vimcode code changed; findings pinned via coord context.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

quadraui#425 (ScreenLayout::hit_map()) merged and pulled. Implemented the wiring the earlier blocked session drafted: render_content builds one quadraui::ScreenLayout accumulating ONLY Editor+TabBar surfaces (same objects already painted -- no duplicate construction), calls .hit_map() once (no backend draw pass, so it can't reorder real painting), caches the resulting FrameHitMap + a parallel (GroupId,Rect) table for TabBar idx resolution. click::pixel_to_click_target/resolve_tab_right_click consult the FrameHitMap first for Editor/TabBar zone detection, falling back to the existing screen_zone_hit_test for breadcrumb/divider zones (no FrameZone equivalent) and pre-first-paint. Deliberately scoped OUT: StatusBar/CommandLine/Dialog/ContextMenu (mixing per-window StatusBar into the same hit map would let it win over Editor for a window's bottom row since it's pushed after Editor and hit_test is last-drawn-wins, changing status-bar click resolution); the overlay-arbitration cascade in handle_mouse_click_msg/handle_mouse_drag_msg (dialog/completions/picker/etc.) already uses cached per-primitive Layout::hit_test() + quadraui dispatch_click/ModalStack/DragState and runs before pixel_to_click_target, so it's unaffected and out of scope. Commit 4fd1b8b pushed to issue-449-migrate-gtk-click-dispatch-to-framehitma. cargo build / cargo clippy -- -D warnings / cargo fmt --check / cargo test (bin+lib, 4000+ tests incl. click.rs's own regression tests) all pass clean.

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: —

Summary

Smoke test passed: click-to-cursor, drag-select, tab-bar switching, and context-menu click all verified working with no errors.

[JDonaghy]

Coordinator: Assignment Failed

Machine: dellserver
Status: failed
Exit code: 1
Duration: —

Error

vimcode #449: branch already sits at tip of origin/develop (1 ahead/0 behind, cb9b5ea..2b97cf6 base) so no rebase was needed. cargo test --no-default-features passed clean, nothing to force-push (already up to date on remote). coord verify-merge 8b6074089a3b passed clean (develop-ahead=0, no foreign commits, only 4fd1b8b on top). BUT coord merge --repo vimcode processed the queue and did not include #449 anywhere in --plan output; coord merge --repo vimcode --only 8b6074089a3b and --only a5c3fcf80f4b both errored 'merge-queue: no entry found'. coord status shows #449 as '[awaiting review]', not approved, and no PR appears to exist for this branch yet -- contradicting the assignment brief's premise that the branch is approved and ready to merge. Did not force anything. Needs operator: either dispatch 'coord pr 8b6074089a3b' to open the PR and run review/CI gates, or clarify/fix the board's approval state, then re-run merge-prep.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 8m 19s