#592-A: GTK live path — paint the five editor overlay popups (completion, hover, editor_hover, diff_peek, signature_help)

[JDonaghy]

Sub-task 1/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 editor overlay popups from the orphaned src/gtk/draw.rs path onto the live GTK ShellApp::render_content path, so GTK paints them again.

screen.* field	dead GTK site	TUI reference
completion	draw.rs:1332	quadraui_tui::draw_completions
hover	draw.rs:1406	—
editor_hover	draw.rs:1552	render_editor_hover_popup
diff_peek	draw.rs:1697	—
signature_help	draw.rs:1792	—

Why this group

All five are popup-shaped surfaces the engine already populates and TUI already paints
through a quadraui primitive (Completions, Tooltip, RichTextPopup). They share a
paint idiom, so porting them together is one pattern applied five times rather than five
investigations. They are also the five most visible: on GTK today, completion, hover,
signature help and diff peek simply do not appear, with no error.

Design

• These fields are already populated on the GTK path — the engine computes them and
  ScreenLayout carries them. Nothing needs computing; this is purely a missing paint call.
• Mirror what TUI does: read the field off ScreenLayout, build the quadraui primitive via
  the existing shared adapter in render.rs, and call the corresponding Backend::draw_*
  inside render_content's frame scope. Do not re-derive geometry per backend.
• If a needed adapter turns out to live only inside draw.rs, lift it to render.rs rather
  than copying it — that is the whole point of the issue.
• Do not delete src/gtk/draw.rs here. It is the reference implementation the later
  sub-tasks port from; GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-D deletes it once nothing needs it.

⚠ 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) that assert on rendered pixels/painted content — not by asserting the
  ScreenLayout field is populated, which is already true today and is exactly why this bug
  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 — every draw_* call goes through an existing
  shared adapter. New adapters land in src/render.rs, not in src/gtk/.
• TUI behaviour unchanged.
• cargo build && cargo test EXIT=0.

Files

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

Out of scope

• Panels and bars (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-B), 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).
• The Ctrl+V / UiEvent::ClipboardPaste gap — that is Ctrl+V paste silently does nothing on GTK — quadraui swallows the key, vimcode has no ClipboardPaste handler #593, same root cause, different fix.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #669: #592-A: GTK live path — paint the five editor overlay popups (completion, hover, editor_hover, diff_peek, signature_help)

Sub-task 1/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 editor overlay popups from the orphaned src/gtk/draw.rs path onto the live GTK ShellApp::render_content path, so GTK paints them again.

screen.* field	dead GTK site	TUI reference
completion	draw.rs:1332	quadraui_tui::draw_completions
hover	draw.rs:1406	—
editor_hover	draw.rs:1552	render_editor_hover_popup
diff_peek	draw.rs:1697	—
signature_help	draw.rs:1792	—

Why this group

All five are popup-shaped surfaces the engine already populates and TUI already paints
through a quadraui primitive (Completions, Tooltip, RichTextPopup). They share a
paint idiom, so porting them together is one pattern applied five times rather than five
investigations. They are also the five most visible: on GTK today, completion, hover,
signature help and diff peek simply do not appear, with no error.

Design

• These fields are already populated on the GTK path — the engine computes them and
  ScreenLayout carries them. Nothing needs computing; this is purely a missing paint call.
• Mirror what TUI does: read the field off ScreenLayout, build the quadraui primitive via
  the existing shared adapter in render.rs, and call the corresponding Backend::draw_*
  inside render_content's frame scope. Do not re-derive geometry per backend.
• If a needed adapter turns out to live only inside draw.rs, lift it to render.rs rather
  than copying it — that is the whole point of the issue.
• Do not delete src/gtk/draw.rs here. It is the reference implementation the later
  sub-tasks port from; GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-D deletes it once nothing needs it.

⚠ 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) that assert on rendered pixels/painted content — not by asserting the
  ScreenLayout field is populated, which is already true today and is exactly why this bug
  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 — every draw_* call goes through an existing
  shared adapter. New adapters land in src/render.rs, not in src/gtk/.
• TUI behaviour unchanged.
• cargo build && cargo test EXIT=0.

Files

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

Out of scope

• Panels and bars (GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592-B), 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).
• The Ctrl+V / UiEvent::ClipboardPaste gap — that is Ctrl+V paste silently does nothing on GTK — quadraui swallows the key, vimcode has no ClipboardPaste handler #593, same root cause, different fix.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 40m 58s
Log: /home/john/.coord/logs/bc82c2815421.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 14m 8s
Log: /home/john/.coord/logs/6a91f53b42a6.log