#592-B: GTK live path — paint the panel surfaces (quickfix, bottom_tabs, debug_toolbar, panel_hover, ai_panel)

[JDonaghy]

Sub-task 2/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 five panel surfaces from the orphaned src/gtk/draw.rs path onto the live GTK ShellApp::render_content path.

screen.* field	dead GTK site	Note
quickfix	draw.rs:2389
bottom_tabs	draw.rs:2283, :591/595/612	terminal / debug-output panel
debug_toolbar	draw.rs:2448
panel_hover	draw.rs:3484
ai_panel	draw.rs:3868	GTK has no PANEL_AI arm at all — mod.rs:8207 reads "not yet migrated"

Why this group

These are panel-region surfaces rather than editor overlays: they paint into the bottom
panel and the sidebar, and they share the SidebarSystem / TabBar / StatusBar idiom.
ai_panel is the odd one out and is called out deliberately — it is not merely an
unpainted field, it has no GTK panel arm, so expect it to be the bulk of this issue.
If it proves larger than the other four combined, split it out into its own issue rather
than letting it swallow the session; say so in a comment and carry on with the other four.

Design

• Same rule as GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-A: these fields are already populated. Read from ScreenLayout, build
  the primitive through the existing shared adapter in render.rs, call Backend::draw_*
  inside render_content's frame scope.
• If an adapter exists only inside draw.rs, lift it to render.rs rather than copying it.
• 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 five 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, which is already true today and is why this went unnoticed.
• Each test fails if its paint call is removed. State in the PR how you verified that.
• No new per-backend geometry or layout logic. New adapters land 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), remaining chrome (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-C), 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 #670: #592-B: GTK live path — paint the panel surfaces (quickfix, bottom_tabs, debug_toolbar, panel_hover, ai_panel)

Sub-task 2/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 five panel surfaces from the orphaned src/gtk/draw.rs path onto the live GTK ShellApp::render_content path.

screen.* field	dead GTK site	Note
quickfix	draw.rs:2389
bottom_tabs	draw.rs:2283, :591/595/612	terminal / debug-output panel
debug_toolbar	draw.rs:2448
panel_hover	draw.rs:3484
ai_panel	draw.rs:3868	GTK has no PANEL_AI arm at all — mod.rs:8207 reads "not yet migrated"

Why this group

These are panel-region surfaces rather than editor overlays: they paint into the bottom
panel and the sidebar, and they share the SidebarSystem / TabBar / StatusBar idiom.
ai_panel is the odd one out and is called out deliberately — it is not merely an
unpainted field, it has no GTK panel arm, so expect it to be the bulk of this issue.
If it proves larger than the other four combined, split it out into its own issue rather
than letting it swallow the session; say so in a comment and carry on with the other four.

Design

• Same rule as GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-A: these fields are already populated. Read from ScreenLayout, build
  the primitive through the existing shared adapter in render.rs, call Backend::draw_*
  inside render_content's frame scope.
• If an adapter exists only inside draw.rs, lift it to render.rs rather than copying it.
• 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 five 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, which is already true today and is why this went unnoticed.
• Each test fails if its paint call is removed. State in the PR how you verified that.
• No new per-backend geometry or layout logic. New adapters land 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), remaining chrome (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-C), 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: 34m 13s
Log: /home/john/.coord/logs/350397c5b53c.log

[JDonaghy]

Coordinator: Assignment Complete

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

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

• src/gtk/mod.rs (bottom-panel content block, content_y = terminal_y + 2.0 * lh / content_h = (el.terminal_h - 2.0 * lh).max(0.0)): this offset is applied uniformly for both BottomPanelKind::Terminal and BottomPanelKind::DebugOutput, but the TUI counterpart (src/tui_main/shell_app.rs, the if chrome.bottom_panel.height > 0 block) only reserves one header row (the tab bar) before DebugOutput content — content_area = Rect{ y: chrome.bottom_panel.y + 1, height: chrome.bottom_panel.height.saturating_sub(1) } — and reserves a second row (the toolbar) only for the Terminal branch. So on GTK the debug-output text now starts one row later than on TUI, with a wasted blank row between the tab bar and the text, and one fewer visible line for the same panel height. This is a real, verifiable backend behavior divergence for a surface this issue explicitly covers (bottom_tabs), and it's new geometry logic written directly in gtk/mod.rs rather than a shared render.rs helper (contrary to the issue's "No new per-backend geometry" design rule) — TUI's per-kind row-reservation logic isn't itself in render.rs either, but the PR's uniform GTK offset doesn't match it. Not blocking because the surface still paints and the acceptance criteria ("all five surfaces paint", tests, TUI unchanged) are still met — this is a one-row cosmetic/content-capacity mismatch, easy to fix in a follow-up by branching content_y/content_h on screen.bottom_tabs.active the way TUI does (or better, lifting that branch into a shared render.rs helper both backends call).

• src/gtk/mod.rs (new "Sidebar-item hover popup" block, inside if let Some(q_sb) = layout.sidebar_content_bounds): self.panel_hover_popup_rect.set(None) / self.panel_hover_link_rects.borrow_mut().clear() only run when the sidebar is visible (q_sb is Some). If the sidebar closes while a hover popup was cached, panel_hover_popup_rect/panel_hover_link_rects keep the stale Some(...) value indefinitely (never reset), since the whole reset-and-repaint block is nested under if let Some(q_sb). Verified with git grep that Msg::PanelHoverClick (the only consumer of panel_hover_link_rects) is never actually emitted anywhere in the current codebase, so this is inert today and not a live bug — but it's a latent trap for whoever wires up that click dispatch next. Low priority; worth a one-line fix (move the two reset lines above the if let Some(q_sb)) whenever that wiring lands, not necessarily in this PR.

Nits

• The commit message / code comments say ai_panel "was split into its own follow-up issue per #592-B: GTK live path — paint the panel surfaces (quickfix, bottom_tabs, debug_toolbar, panel_hover, ai_panel) #670's own escape hatch" but don't cite an issue number anywhere in the diff (gtk/mod.rs comment, testing.rs module doc). The issue's escape hatch only requires "say so in a comment," which is technically satisfied, but a concrete issue number would make this traceable — worth confirming a tracking issue actually exists and referencing it.
• Nothing else structurally wrong: verified by reading the diff against the pinned commit's actual source (not just the diff hunks) that (a) render.rs's only additions are the two new panel_hover_* functions — compute_editor_layout, EditorLayout, and all the quickfix_to_list_view/build_bottom_panel_tab_bar/build_terminal_toolbar/build_terminal_draw_data/debug_output_to_text_display/draw_debug_toolbar adapters used from gtk/mod.rs were all pre-existing and already shared with TUI; (b) the editor_area_h/status_y layout fix is a real, correctly-derived bug fix (old code omitted quickfix_h from the reservation and mis-subtracted terminal/debug-toolbar/separated-status heights from status_y, which the new el.editor_bottom/h - status_bar_h formulation fixes — verified against compute_editor_layout's formula line by line); (c) all engine/App fields referenced (bottom_panel_geometry, bottom_tab_bar_hits, terminal_toolbar_hits, terminal_split_layout, debug_toolbar_y_offset, panel_hover_popup_rect, panel_hover_link_rects, show_panel_hover, etc.) pre-date this PR, confirming no new per-backend state was invented; (d) the four new gtk/testing.rs GtkDriver tests use a sound methodology (compare two open states differing only in content, not open-vs-closed, with the reasoning for why spelled out in the module doc) and the PR states each was verified red by temporarily deleting its paint call — satisfies the repo's black-box coverage and "must be able to fail" requirements. No security issues; no scope creep beyond the five listed surfaces (ai_panel correctly deferred per the issue's own explicit escape hatch).