#592-C: GTK live path — paint the remaining chrome (find_replace, tab_switcher, separated_status_line, tab_tooltip)

[JDonaghy]

Sub-task 3/4 of #592. Read #592 first — it holds the root cause, the full 13-field table, and the evidence that src/gtk/draw.rs has no live callers.

What

Port the remaining four chrome / transient surfaces from the orphaned src/gtk/draw.rs path onto the live GTK ShellApp::render_content path. These are the last of #592's thirteen.

screen.* field	dead GTK site
find_replace	draw.rs:1833
tab_switcher	draw.rs:1896
separated_status_line	none — never had a GTK painter
tab_tooltip	none — never had a GTK painter

Why this group

Two of these four have no dead GTK painter to port from at all, so they are a different
job from #592-A / #592-B: rather than reviving an orphan, you are writing the first GTK paint
call, using the TUI call site as the reference for which shared adapter to use. Grouped
together so that difference is faced once.

find_replace was confirmed empirically in #592 the same way the command palette was in
#587 — trigger "Edit: Find & Replace" and the overlay state opens while nothing paints:

KEYDBG: OVERLAY STATE OPEN: ["find_replace"]

Design

• Same rule as GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-A/B: fields are already populated. Read from ScreenLayout, build the
  primitive through the shared adapter in render.rs, call Backend::draw_* inside
  render_content's frame scope.
• For the two with no dead painter, find the shared adapter the TUI call site uses and call
  the same one. If no shared adapter exists, add it to src/render.rs — not to
  src/gtk/. Writing a GTK-only painter here would recreate the exact debt this issue
  retires (see the Platform-Neutrality Rule in CLAUDE.md).
• Do not delete src/gtk/draw.rs here — GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-D does that.

⚠ The TUI line numbers in #592's table are pre-#634. The TUI cutover to run_with_shell
moved those paint sites into src/tui_main/shell_app.rs. Locate the current TUI call site by
symbol, not by the line numbers in that table.

Acceptance criteria

• All four surfaces paint on GTK, proven by GtkDriver black-box tests (src/gtk/testing.rs,
  harness from Adopt quadraui's GtkDriver — vimcode has zero GTK black-box tests though the harness shipped in quadraui#301 #646) asserting on rendered output — not on ScreenLayout field
  population.
• Each test fails if its paint call is removed. State in the PR how you verified that.
• The find/replace overlay opens and paints on GTK — the KEYDBG line above is no longer
  the only evidence it exists.
• No GTK-only painter added. Any new adapter lands in src/render.rs.
• TUI behaviour unchanged.
• cargo build && cargo test EXIT=0.

Files

• src/gtk/mod.rs
• src/render.rs
• src/gtk/testing.rs

Out of scope

• Overlay popups (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-A), panels (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-B), scroll surfaces + deleting draw.rs (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-D).

[JDonaghy]

Coordinator Assignment

Machine: dellserver
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

Issue #671: #592-C: GTK live path — paint the remaining chrome (find_replace, tab_switcher, separated_status_line, tab_tooltip)

Sub-task 3/4 of #592. Read #592 first — it holds the root cause, the full 13-field table, and the evidence that src/gtk/draw.rs has no live callers.

What

Port the remaining four chrome / transient surfaces from the orphaned src/gtk/draw.rs path onto the live GTK ShellApp::render_content path. These are the last of #592's thirteen.

screen.* field	dead GTK site
find_replace	draw.rs:1833
tab_switcher	draw.rs:1896
separated_status_line	none — never had a GTK painter
tab_tooltip	none — never had a GTK painter

Why this group

Two of these four have no dead GTK painter to port from at all, so they are a different
job from #592-A / #592-B: rather than reviving an orphan, you are writing the first GTK paint
call, using the TUI call site as the reference for which shared adapter to use. Grouped
together so that difference is faced once.

find_replace was confirmed empirically in #592 the same way the command palette was in
#587 — trigger "Edit: Find & Replace" and the overlay state opens while nothing paints:

KEYDBG: OVERLAY STATE OPEN: ["find_replace"]

Design

• Same rule as GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-A/B: fields are already populated. Read from ScreenLayout, build the
  primitive through the shared adapter in render.rs, call Backend::draw_* inside
  render_content's frame scope.
• For the two with no dead painter, find the shared adapter the TUI call site uses and call
  the same one. If no shared adapter exists, add it to src/render.rs — not to
  src/gtk/. Writing a GTK-only painter here would recreate the exact debt this issue
  retires (see the Platform-Neutrality Rule in CLAUDE.md).
• Do not delete src/gtk/draw.rs here — GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-D does that.

⚠ The TUI line numbers in #592's table are pre-#634. The TUI cutover to run_with_shell
moved those paint sites into src/tui_main/shell_app.rs. Locate the current TUI call site by
symbol, not by the line numbers in that table.

Acceptance criteria

• All four surfaces paint on GTK, proven by GtkDriver black-box tests (src/gtk/testing.rs,
  harness from Adopt quadraui's GtkDriver — vimcode has zero GTK black-box tests though the harness shipped in quadraui#301 #646) asserting on rendered output — not on ScreenLayout field
  population.
• Each test fails if its paint call is removed. State in the PR how you verified that.
• The find/replace overlay opens and paints on GTK — the KEYDBG line above is no longer
  the only evidence it exists.
• No GTK-only painter added. Any new adapter lands in src/render.rs.
• TUI behaviour unchanged.
• cargo build && cargo test EXIT=0.

Files

• src/gtk/mod.rs
• src/render.rs
• src/gtk/testing.rs

Out of scope

• Overlay popups (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-A), panels (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-B), scroll surfaces + deleting draw.rs (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-D).

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 28m 54s
Log: /home/john/.coord/logs/6ac8454e6ede.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 11m 21s
Log: /home/john/.coord/logs/fb1ba2f5a9dd.log

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: request-changes

Review findings

Blocking findings

• src/gtk/mod.rs:8517-8540 (tab_hover_tooltip_paint call in render_content): the tooltip's Y position is computed as (y + lh) as f32, where y is main.y — the very top of main_content_bounds, i.e. the top of the tab bar row, not the top of "the editor column" as the comment claims. But GTK's own tab row is tab_row_h = (lh * 1.6).ceil() tall (tab_bar_h is even taller when breadcrumbs are on) — computed a few lines earlier in the very same function (let tab_row_h = (lh * 1.6).ceil(); let tab_bar_h = render::tab_bar_height_px(lh, engine.settings.breadcrumbs);). Offsetting by only one lh (≈62% of the tab row's height) lands the tooltip's top edge inside the tab row's own vertical span, not below it — the tooltip band (itself unit_h = lh tall) will paint across the bottom portion of the tab bar (behind/over tab labels) before extending into the editor area, rather than appearing as a clean band below the tab bar the way the comment says it mirrors TUI's area.y + 1. TUI's equivalent works correctly only because its tab bar is exactly one cell-row tall, so +1 row does clear it — that assumption doesn't hold in GTK's pixel space where the tab row is 1.6× (or more) a line height. Fix: offset by tab_bar_h (or tab_row_h if intentionally ignoring breadcrumb height, matching TUI's row-based semantics) instead of lh. The new tab_hover_tooltip_paints test (src/gtk/testing.rs) samples a broad 0–200px band and won't catch this — it only proves some pixels changed, not that they changed in the right place, so it stays green with this bug present.

Non-blocking concerns

• src/gtk/mod.rs:9367-9394 (tab switcher popup sizing/positioning: max_visible, popup_w, popup_h, popup_x, popup_y): this ~20-line geometry block is per-backend layout code beyond thin wiring, per the repo's Platform-Neutrality Rule ("if a feature requires new code in src/gtk/ … beyond thin event-to-engine wiring, STOP … build the shared function in render.rs"). It isn't a new pattern this PR invents — src/tui_main/render_impl.rs:908-940 already does the equivalent inline math (in cell units) for the same popup, pre-dating this PR — but propagating that duplication to a second backend, rather than factoring shared geometry into render.rs (the way dialog_generic_layout/context_menu_generic_layout already do for other popups), continues an anti-pattern the project's own conventions treat as tech debt, not precedent. Worth a follow-up: extract a tab_switcher_layout(viewport_w, viewport_h, unit_w, unit_h, item_count) -> Rect-style shared helper so a third backend doesn't have to duplicate this a third time. Not blocking this PR since it matches existing (if imperfect) precedent and the issue is scoped to reaching GTK/TUI parity, not an architecture cleanup.

Nits

• src/gtk/testing.rs's new chrome_surfaces::small_engine() duplicates the identical helper already present in the sibling editor_popups module (src/gtk/testing.rs:1306) verbatim. Minor — test-module-local fixture duplication is an established pattern in this file already (multiple modules each have their own copy), so not asking for a change, just noting it.