Migrate GTK draw wiring to quadraui ScreenLayout::draw()

[JDonaghy]

Summary

Replace src/gtk/draw.rs surface-by-surface delegation (~3,874 lines) with quadraui's declarative ScreenLayout::draw() + FrameHitMap. Today each surface is individually positioned, measured, and drawn via a separate call; the new path pushes Surface entries in z-order and calls .draw(backend) once.

What exists in quadraui

• quadraui::ScreenLayout — push Surface entries (Editor, TabBar, StatusBar, Palette, ContextMenu, etc.) in back-to-front z-order
• ScreenLayout::draw(&self, backend: &mut dyn Backend) -> FrameHitMap — renders all surfaces, returns hit map
• FrameHitMap::hit_test(x, y) -> FrameZone — highest-z zone at point (consumed by fix: dedupe terminal pane focus + selection into engine method (#429) #445)
• Proven in gtk_frame_demo / tui_frame_demo examples

What to do

1. Build a quadraui::ScreenLayout in vimcode's GTK draw path, pushing each surface with its rect
2. Call .draw(backend) instead of individual draw_* calls
3. Cache the returned FrameHitMap for click dispatch (fix: dedupe terminal pane focus + selection into engine method (#429) #445)
4. Delete the per-surface draw wiring in src/gtk/draw.rs

Files

• src/gtk/draw.rs — bulk of the deletion (~3,874 lines → near-zero)
• src/render.rs — may need to produce Surface entries instead of / alongside current ScreenLayout struct

Dependencies

• quadraui GTK explorer scrollbar: clicking on track outside the thumb should page-scroll #199 (ScreenLayout + FrameHitMap) ✅ landed

Notes

vimcode has its own render::ScreenLayout struct — naming collision with quadraui::ScreenLayout. Will need a qualified import or rename.

This is issue 1 of 4 in the GTK AppShell consumption series. Should land before #445 (click dispatch migration).

[JDonaghy]

Implementation notes (2026-05-17, coordinator)

This is the big one. Replace surface-by-surface draw delegation in src/gtk/draw.rs (~3,874 lines) with quadraui's ScreenLayout::draw().

quadraui infrastructure (all landed):

• quadraui::frame::ScreenLayout — push Surface entries in z-order
• ScreenLayout::draw(&self, backend) -> FrameHitMap — renders all, returns hit map
• FrameHitMap::hit_test(x, y) -> FrameZone — highest-z surface at point
• Proven in gtk_frame_demo / tui_frame_demo examples
• Pull quadraui first: cd ~/src/quadraui && git pull

Naming collision: vimcode has its own render::ScreenLayout struct. Use qualified imports: quadraui::ScreenLayout as FrameLayout or similar.

Approach — incremental, not big-bang:

1. Start by building a quadraui::ScreenLayout alongside the existing draw calls
2. Migrate one surface at a time (e.g., status bars first, then tab bars, then editor)
3. Each surface migration: remove the manual draw call, push a Surface entry instead
4. Cache the returned FrameHitMap for Migrate GTK click dispatch to FrameHitMap #449 (click dispatch migration)
5. Once all surfaces are pushed, delete the per-surface draw functions

Files: src/gtk/draw.rs (bulk deletion), src/render.rs (may need to produce Surface entries). Possibly src/gtk/mod.rs (FrameHitMap caching).

Do NOT touch: src/tui_main/ (separate migration later), src/core/engine/keys.rs.

Reference: ~/src/quadraui/quadraui/examples/common/frame_demo.rs — shows the end-to-end pattern.

[JDonaghy]

Blocked on quadraui#210

Starting work surfaced a gap: Surface::StatusBar/TabBar/ActivityBar in ScreenLayout::draw() discard the layout return values that vimcode's click dispatch consumes (StatusBarLayout, TabBarHits, Vec<ActivityBarRowHit>). Without those, migrating those surfaces silently breaks tab close clicks, activity row clicks, breadcrumb hit-test, etc.

Filed quadraui#210 requesting status_bar_layout() / tab_bar_layout() / activity_bar_layout() on the Backend trait — consistent with existing msv_layout/tree_layout/form_layout/text_display_layout/menu_bar_layout/etc. pattern. Once that ships, this issue migrates 5 surfaces (global status bar, wildmenu, per-window status bars, breadcrumbs, tab bars, activity bar, debug toolbar — picking ~5) onto ScreenLayout::draw() and caches both the FrameHitMap and the per-primitive layouts for #449's click dispatch.

Claim branch issue-446-screen-layout-draw pushed empty as the parking spot.

[JDonaghy]

Resume attempt (2026-05-18) — 5-surface chrome migration broke smoke test; design review needed

Resumed work on issue-446-screen-layout-draw (commit 0803fcd, pushed) after quadraui#210 landed. Migrated 5 chrome surfaces:

1. Global status bar (no-terminal branch in draw_editor) — Surface::StatusBar push, layout discarded.
2. Wildmenu (both branches: terminal-open + no-terminal) — Surface::StatusBar push, layout discarded.
3. Breadcrumb bar (in draw_breadcrumb_bar helper) — Surface::StatusBar push + post-paint b.status_bar_layout(rect, bar) to recover the StatusBarLayout that was previously returned by b.draw_status_bar.
4. Tab bars (in draw_tab_bar helper, used for single-group + multi-group cases) — Surface::TabBar push + post-paint b.tab_bar_layout(rect, bar) to recover TabBarHits for slot positions / close bounds / right-segment bounds / correct_scroll_offset.
5. Activity bar (in widgets.activity_bar.set_draw_func closure in mod.rs) — Surface::ActivityBar push + post-paint b.activity_bar_layout(rect, &bar) to recover row hits.

Build + clippy + fmt + 1989 lib tests all pass.

Smoke-test regressions

User-observed in GTK:

1. Wildmenu doesn't appear at all. Paint regression, not hit-test. The Surface::StatusBar push for the wildmenu should be byte-equivalent to the old direct b.draw_status_bar(rect, &bar, None, None) call — frame.draw(b) dispatches to the same trait method with the same args. No theory for what's different; would need to debug locally with a print/log.
2. Tab close buttons don't work. Clicks register but the close-button hit-test doesn't fire. Tab close bounds in vimcode's cached map come from TabBarHits.close_bounds. New path takes them from b.tab_bar_layout() instead of b.draw_tab_bar()'s return.
3. Tab hit-test off — clicking tab N activates tab M. Same root: slot_positions from b.tab_bar_layout() doesn't match what b.draw_tab_bar() actually painted.
4. Tab overflow broken — newly opened tabs not visible. correct_scroll_offset from b.tab_bar_layout() doesn't match the rasteriser's scroll-into-view computation.
5. Breadcrumb segments not clickable. StatusBarLayout.hit_regions from b.status_bar_layout() doesn't match the rasteriser's segment x positions.

Root cause

Issues 2–5 share one cause: quadraui's _layout() methods don't reproduce the rasteriser's geometry byte-for-byte.

Specifically, in quadraui/src/gtk/backend.rs:

• status_bar_layout calls bar.layout(rect.width, lh, char_w * 2.0, measure) where measure uses self.pango_str_width(&pango_layout, &seg.text, char_w). The pango_layout here is built from self.pango_ctx, which vimcode sets once at startup to the UI font (UI_FONT() = sans-serif, see src/gtk/mod.rs:2225-2235). But the rasteriser (gtk::draw_status_bar) measures via the cairo context's layout, which inside draw_editor has the editor monospace font active. Different fonts → different segment widths → segment x positions drift → clicks land on the wrong segment.
• tab_bar_layout calls bar.layout(rect.width, rect.height, lh * 1.5, ...) — the cross-backend primitive layout. The rasteriser (gtk::draw_tab_bar) does its own measurement with tab_pad / tab_inner_gap / tab_outer_gap constants, applies italic font for preview tabs, computes effective_tab_area = width - reserved_px after measuring right-segments. The primitive layout doesn't replicate any of this — slot widths and positions are necessarily different.
• activity_bar_layout calls activity_bar_hits(rect, bar, lh) (a free function in quadraui). I didn't observe the activity bar break in the smoke test, but the same geometry-mismatch class likely applies if any sizing depends on Pango widths vs. layout-fn approximations. User didn't include it in the broken list; may be that the activity bar's row geometry is simple enough that the mismatch doesn't manifest visibly.

The fundamental problem: b.draw_X() returns hits derived from the rasteriser's own measurement path; b.X_layout() returns hits derived from the primitive's layout() fn with simplified closures. They're not the same algorithm.

What quadraui#210 should have asked for (in hindsight)

quadraui#210 requested the _layout() methods exist. It didn't require:

• Same measurement source (Pango from cr's layout vs. self.pango_ctx).
• Same geometry algorithm (rasteriser's per-tab math vs. primitive's generic layout).
• Same font (UI vs. editor monospace, italic-for-preview handling).

For the migration to actually work, one of these must hold:

Option A — Single geometry source. The rasteriser is refactored to consume the layout return from bar.layout(...), so paint and _layout() are guaranteed to agree. This is what MultiSectionView / TreeView / Form do, and what the harness lessons in quadraui's CLAUDE.md prescribe ("paint and click consume one layout per frame").

Option B — Symmetrically duplicated. b.X_layout() is implemented by calling the same per-backend free function as b.draw_X() minus the painting. Acceptable but fragile (two parallel implementations must stay in sync).

Either way, status_bar_layout / tab_bar_layout / activity_bar_layout on GtkBackend need to share the rasteriser's measurement context — specifically, the Pango layout has to be obtained from the current frame's cairo context (the enter_frame_scope pointer), not from self.pango_ctx, so font/size matches what the rasteriser actually drew with.

Outstanding: wildmenu paint regression

The wildmenu not painting is a separate puzzle. The old call was:
```rust
b.draw_status_bar(quadraui::Rect::new(0.0, next_y as f32, width as f32, line_height as f32), &bar, None, None);
```
The new call is:
```rust
let rect = quadraui::Rect::new(0.0, next_y as f32, width as f32, line_height as f32);
let mut frame = ScreenLayout::new();
frame.push(Surface::StatusBar { rect, bar: &bar, hovered: None, pressed: None });
frame.draw(b);
```
`frame.draw(b)` dispatches to the same backend.draw_status_bar(rect, bar, None, None) via the trait. Should be identical. Build + clippy clean; not a compile-time bug. No theory for what's different at runtime — needs local debug session.

The global status bar (same code shape, same migration) does paint per the user's report, which makes this even more puzzling. The only material difference is wildmenu's bar is owned (let bar = wildmenu_to_status_bar(...)) vs. global status bar's bar is a borrow (if let Some(ref bar) = screen.global_status_bar). Should not matter, but flagging.

Branch state

Branch issue-446-screen-layout-draw left at commit 0803fcd (wip(gtk): #446 5-surface ScreenLayout migration — known-broken) with all 5 migrations applied. Do not merge.

Recommend: design review to choose between:

• (a) File new quadraui issue to refactor the _layout() methods to share rasteriser geometry (Option A above); re-park Migrate GTK draw wiring to quadraui ScreenLayout::draw() #446 until that lands.
• (b) Partial vimcode-side fix: revert tab bar + breadcrumb to use b.draw_X(...)'s return for hits while keeping the Surface::X push for paint. Tab bar + breadcrumb wouldn't actually unify hit dispatch in this PR, but paint goes through the frame.
• (c) Treat as failed attempt; reset branch.

[JDonaghy]

Split plan (2026-05-18, coordinator)

Based on Desktop A's smoke-test findings, #446 needs to be split. The core blocker is quadraui#211 — rasterisers need to consume their own layout before hit-test surfaces can migrate.

Chunk A: Scaffolding + paint-only surfaces (no hit-test needed)

Can land NOW. Surfaces where we only need paint, no cached layout for clicks:

• Wildmenu (debug the paint regression — may be a frame scope issue)
• Global status bar (paints correctly per report — verify clicks aren't needed)
• Activity bar (if hit-test works — report says no visible break)

Chunk B: Hit-test surfaces (blocked on quadraui#211)

Tab bars, breadcrumb bars, per-window status bars — all need the rasteriser-consumes-layout fix before migration.

Chunk C: Complex surfaces

Editor viewport, scrollbars, terminal — these have their own layout patterns already. Assess after B.

Chunk D: Popups and overlays

Tooltip, completion, context menu, dialog, rich text popup — these use pre-computed layout already (TooltipLayout, CompletionsLayout, etc.). May be migratable now.

Recommendation

1. Desktop A: revert the broken tab bar + breadcrumb + status bar migrations. Keep only what works (activity bar, possibly wildmenu after debug). Land that as chunk A.
2. Quadraui agent: work on GTK debug panel: variable tree clicks land on row ~2 above the clicked one #211.
3. After GTK debug panel: variable tree clicks land on row ~2 above the clicked one #211 lands: resume with chunk B.
4. Chunk D (popups) can be done in parallel — different files, different pattern.