You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Close the gap between TUI (~95% on quadraui chrome) and GTK (~65%). After this wave, every chrome surface that has a quadraui primitive should consume it on both backends, with bug fixes living in one place. This is the wave Phase B.5 in PLAN.md refers to.
This is an umbrella issue — each checkbox is a self-contained slice that ships as its own PR / Path-A landing.
In scope (chrome only — editor viewport explicitly deferred to B.5b / Phase A.9)
GTK Tooltip migration — `draw_hover_popup`, `draw_editor_hover_popup`, `draw_signature_popup`, `draw_diff_peek_popup` → `quadraui::Tooltip` via `quadraui_gtk::draw_tooltip`. Biggest deduplication win (4 popups → 1 primitive consumer). Also lets us drop the per-popup geometry math in each.
GTK menu-dropdown migration — `draw_menu_dropdown` (top menu bar dropdowns) → `quadraui::ContextMenu`. TUI consumer landed in Session 328 `c6c0718`. Also closes Menu dropdown doesn't highlight items on mouse hover #181 (no hover highlight) since the primitive resolves hover state.
GTK debug toolbar migration — `draw_debug_toolbar` → `quadraui::StatusBar` via `bar.resolve_click` for hit testing. TUI consumer landed in Session 328 `f84c3c2`.
GTK breadcrumb bar migration — `draw_breadcrumb_bar` → `quadraui::StatusBar` (same pattern). TUI consumer landed in Session 328 `553b207`.
LSP signature help popup never shows data #180 — LSP signature help shows no data (that's an engine bug — server response not reaching the popup; unrelated to migrating the popup's renderer).
Unified sidebar rendering via ScreenLayout #133 — "Unified sidebar rendering via ScreenLayout" (proposes a different architectural axis; revisit after this wave to see whether it's still desirable).
Suggested order
Tooltip first (biggest dedup), then Dialog (smallest single-surface change), then ContextMenu / menu-dropdown together (same primitive, different consumers), then Completions, then debug toolbar + breadcrumb together (same StatusBar pattern), ext-panel last (bundled with #200 render fix).
Rough size estimates
Slice
LOC delta
Risk
Tooltip
-200 / +50
Low — primitive proven on TUI
Dialog
-120 / +40
Low
ContextMenu + menu-dropdown
-200 / +60
Med — focus/hover handling
Completions
-150 / +50
Low
Debug toolbar
-80 / +30
Low
Breadcrumb bar
-60 / +25
Low
Ext-panel render+drag
-100 / +120
Med — currently no scrollbar at all
Cumulative: ~-900 LOC GTK draw.rs, +375 LOC primitive consumers.
The quadraui north-star — "developer can write a cross-platform app on quadraui without knowing GTK / crossterm / Cocoa" — is currently true for picker-shaped surfaces but false for dialog/tooltip/completion-shaped surfaces because GTK still draws those bespoke. Closing the gap makes the north-star defensible across both backends in vimcode and unblocks the Postman-class validation app (Postman-class app as quadraui validation consumer #169).
Goal
Close the gap between TUI (~95% on quadraui chrome) and GTK (~65%). After this wave, every chrome surface that has a quadraui primitive should consume it on both backends, with bug fixes living in one place. This is the wave Phase B.5 in PLAN.md refers to.
This is an umbrella issue — each checkbox is a self-contained slice that ships as its own PR / Path-A landing.
In scope (chrome only — editor viewport explicitly deferred to B.5b / Phase A.9)
Pre-existing issues this wave subsumes
Pre-existing issues this wave does not address
Suggested order
Tooltip first (biggest dedup), then Dialog (smallest single-surface change), then ContextMenu / menu-dropdown together (same primitive, different consumers), then Completions, then debug toolbar + breadcrumb together (same StatusBar pattern), ext-panel last (bundled with #200 render fix).
Rough size estimates
Cumulative: ~-900 LOC GTK draw.rs, +375 LOC primitive consumers.
Why now