GTK: the VS Code-style Command Center (nav arrows + search box) was dropped by the #540 Relm4→ShellApp cutover and never re-wired

[JDonaghy]

Summary

The GTK backend has silently lost its VS Code–style Command Center — the ◀ ▶ nav arrows
plus the centered 🔍 <project> search box in the title-bar row (quadraui's CommandCenter
primitive, landed for both backends in #310 / b5fdd7d). Clicking the search box is the
discoverable entry point to the unified picker with prefix routing (> commands, @ symbols,
: line, # …).

It is collateral damage from the Relm4 → ShellApp cutover, commit c35aea4
("feat(#540): flip GTK main loop from Relm4 to ShellApp runner (#448-C)", 2026-06-28).
That commit deleted impl SimpleComponent for App (~3,059 lines). Inside the deleted Relm4
view! scaffolding lived the titlebar DrawingArea draw closure that called
quadraui::gtk::draw_command_center(...) and stashed the result in engine.command_center_layout,
plus the sibling click handler that hit-tested it. The replacement
impl quadraui::ShellApp for App::render_content never ported either half.

This is the same bug family as the other #540 fallout already fixed one at a time — #546
(dialog / context menu never painted), #547 (nerd fonts), #552 (window controls / CSD), #555
(breadcrumb bar), #556 (dock icon), #557 (extension panels), #587 (picker + panel accelerators),
#544 (sidebar panel clicks). The command center is simply the one nobody re-listed.

Expected

On GTK, the title-bar row shows ◀ ▶ nav arrows and a centered 🔍 <project-name> search box
between the menu labels (File / Edit / View …) and the inline window controls (min / max / close).
Clicking ◀/▶ navigates tab history; clicking the search box opens the unified picker
(Engine::open_command_center()).

Actual

Nothing is painted in that region and nothing is clickable there. The band from the end of the
menu labels to the right window edge is claimed end-to-end by the window-controls status bar.

Repro

1. cargo run --features gui (GTK build).
2. Look at the title-bar row: File / Edit / View … on the left, min/max/close on the right,
   empty band in between — no arrows, no search box.
3. Click anywhere in that empty band → nothing happens.
4. Compare with the TUI (cargo run in vscode-mode, or Alt to reveal the menu bar): the arrows
   and search box are present and clickable.

Evidence — current state of the tree

	Paint	Click	Status
TUI	✅ src/tui_main/shell_app.rs:1359-1377 (ported by #635, Stage 6b item A)	✅ src/tui_main/mouse.rs:1978-1995	intact
GTK	❌ nothing in src/gtk/** calls draw_command_center or build_command_center_view	❌ no command_center_layout hit-test anywhere in src/gtk/	gone

Corroborating details:

• The real estate is being painted over. src/gtk/mod.rs:8255-8276 computes
  controls_rect = menu_end → right window edge, and src/gtk/mod.rs:8884 paints
  render::window_controls_status_bar across all of it. quadraui::gtk::draw_status_bar
  background-fills its entire rect (quadraui/src/gtk/status_bar.rs:73-80), so even the gap is
  claimed.
• engine.command_center_layout is permanently None on GTK — never written by the ShellApp
  path, so any hit-test would fail even if one existed.
• menu_bar_da is a dead husk. Declared src/gtk/mod.rs:509, initialised to None at
  :1544, and never assigned Some — four dead reads remain at :2134, :5452, :5460,
  :7532. That is the orphaned handle to the old Relm4 titlebar drawing area.
• src/gtk/draw.rs never had it — the legacy Cairo path (already dead under ShellApp) has no
  command-center code, so there is no second call site to revive. The only one was in mod.rs's
  deleted view! block.
• Docs are stale: PROJECT_STATE.md:92 still claims Command center (nav arrows + search box) | CommandCenter | ✅ | ✅.

What still works on GTK: :CommandCenter (src/core/engine/execute.rs:1999) and Ctrl+Shift+P
(accelerators restored in #587) both open the picker correctly. It is purely the bar — the
visible entry point and its arrows — that is missing.

Nothing was deleted from quadraui

The whole API surface is live and already exported, so this is wiring, not a rebuild:

• quadraui::{CommandCenter, CommandCenterHit, CommandCenterLayout, CommandCenterMeasure}
  (quadraui/src/lib.rs:159, primitive at quadraui/src/primitives/command_center.rs)
• Backend::draw_command_center (quadraui/src/backend.rs:1157) and
  Backend::command_center_layout (:1160) — trait methods, available to GTK today
• quadraui::gtk::draw_command_center (quadraui/src/gtk/command_center.rs:50) — the GTK
  rasteriser, still implemented and still wired into the GTK backend at
  quadraui/src/gtk/backend.rs:2882
• render::build_command_center_view (src/render.rs:4065) — backend-agnostic, already shared

Proposed fix

1. Narrow controls_rect. In render_content (src/gtk/mod.rs:8255-8276), measure the three
   window-control buttons with backend.status_bar_layout(...) and shrink the controls rect to
   just that right-aligned width, instead of handing them the entire menu_end → right edge band.
2. Paint the command center in the freed gap, using render::build_command_center_view( engine.tab_nav_can_go_back(), engine.tab_nav_can_go_forward(), &title) and
   backend.draw_command_center(gap_rect, &cc).
   Ordering is load-bearing: it must be painted after menu_system.borrow().render(...)
   (src/gtk/mod.rs:8788), which repaints draw_menu_bar across the full menu_row_rect band.
   Painting before it reproduces the #448-E: GTK window chrome lost after ShellApp flip — WM titlebar returns, menu bar + inline min/max buttons gone #552 round-2/3 "buttons render blank" regression verbatim.
3. Cache the layout into engine.command_center_layout (and clear it to None when
   menu_bar_visible is false), mirroring src/tui_main/shell_app.rs:1377 / :1381.
4. Hit-test on click in handle_mouse_click_msg (src/gtk/mod.rs:3698):
   Back → tab_nav_back(), Forward → tab_nav_forward(), SearchBox → open_command_center()
   — mirroring src/tui_main/mouse.rs:1983-1993. Must run before the window-controls
   hit-test so it isn't swallowed.
5. Delete the dead menu_bar_da field and its four dead reads.
6. Fix PROJECT_STATE.md:92 to reflect reality once the fix lands.

Design note — deliberate GTK/TUI divergence

GTK forces menu_bar_visible = true at startup (src/gtk/mod.rs:8171), whereas the TUI shows the
menu row only in vscode-mode or on Alt. So on GTK the command center returns permanently
visible — which is both the pre-#540 behaviour and the VS Code behaviour this was modelled on.
Gate the GTK paint on engine.menu_bar_visible anyway (same condition as TUI) so the two
backends stay structurally identical; the flag just happens to always be true on GTK.

Black-box test

Per CLAUDE.md this is behaviour-changing and needs a black-box test. Use the GTK headless
pixel-probe harness in src/gtk/testing.rs and follow the pattern established by #555
("test(#555): assert the breadcrumb dropdown paints via pixels, not painted text", 755d732) —
assert on painted pixels, not on painted text, since these are icon glyphs. Cover:

• the search box and both arrows paint inside the title-bar band, to the left of the window
  controls and to the right of the last menu label (no overlap with either);
• a click on the search box opens the picker (engine.picker_open == true with
  picker_source == PickerSource::CommandCenter);
• clicks on ◀/▶ drive tab-nav history;
• the window controls still paint and still respond (guard against re-breaking #448-E: GTK window chrome lost after ShellApp flip — WM titlebar returns, menu bar + inline min/max buttons gone #552).

Files

• src/gtk/mod.rs
• src/gtk/testing.rs
• PROJECT_STATE.md

[JDonaghy]

Queue context + scope clarification (coordinator)

Queued as drive-queue entry 534. The overlap predictor (#2247) chained this
--after vimcode#659, #669, #670, #671, #672 on a declared-files match
(src/gtk/mod.rs, src/gtk/testing.rs). Three notes for whoever picks this up.

1. This is NOT a sub-task of #592 — and #592 could not have found it

#669–#672 are #592-A/B/C/D. Their combined scope is the surfaces in #592's table:
editor overlays (completion, hover, editor_hover, diff_peek,
signature_help), panels (quickfix, bottom_tabs, debug_toolbar,
panel_hover, ai_panel), and transient chrome (find_replace,
tab_switcher, separated_status_line, tab_tooltip). Every one paints into
the editor viewport, the bottom panel, or the sidebar. None touches
layout.title_bar_bounds, menu_row_rect, or controls_rect — so the
overlap that chained this entry is file-level (same render_content function,
disjoint blocks), not region-level.

The command center was invisible to #592's audit for two independent structural
reasons, both worth knowing before you assume this is already covered:

1. It was never in src/gtk/draw.rs. Confirmed — that file contains no
   command-center code at any revision. It lived in the Relm4 view! block in
   mod.rs, deleted wholesale by c35aea4. GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592's method was "enumerate what
   draw.rs paints that render_content doesn't", against a file that never
   held it.
2. It is not a ScreenLayout field. It is built ad hoc from
   render::build_command_center_view(engine.tab_nav_can_go_back(), ...), not
   carried on ScreenLayout. A field-by-field audit of that struct skips it too.

Checked whether that blind spot hides anything else: c35aea4 deleted exactly
two quadraui::gtk::draw_* calls from the Relm4 block — draw_command_center
and draw_activity_bar. The activity bar is fine (it moved up to
quadraui::AppShell::render, which the runner calls before render_content;
#557/#544 have since worked on it). Verified AppShell::render does not
paint a command center — it only reserves the band via title_bar_bounds and
leaves the app to fill it, so render_content is the sole possible painter.
draw_menu_bar, draw_status_bar and draw_tab_bar all have live call sites
again. The command center is the sole survivor of that class.

2. Step 5 (delete dead menu_bar_da) may already be done — check first

#672 (#592-D) has an acceptance criterion of "no file under src/gtk/ carries a
file-level #![allow(dead_code)]", then letting the compiler name what is left.
That will flag menu_bar_da (src/gtk/mod.rs:509, initialised None at
:1544, never assigned, four dead reads at :2134, :5452, :5460, :7532)
— which is exactly step 5 here. Since this entry is chained after #672, expect
it to be gone already. Treat step 5 as "remove if still present", not as a
required deliverable, and do not re-add the field.

3. The test harness will have moved by the time this runs

#659 removes the local tab_center / tab_close_center helpers from
src/gtk/testing.rs in favour of the quadraui-promoted versions (quadraui #594),
keyed by the tab bar's WidgetId rather than vimcode's GroupId. Write the
black-box test against the post-#659 harness — consume the quadraui-provided
helpers, do not reintroduce local tab-geometry arithmetic.

Unchanged

The root cause, the paint/click evidence, the six-step fix, and the #552 paint-
ordering hazard in the issue body all still stand. In particular: the command
center must be painted after menu_system.borrow().render(...)
(src/gtk/mod.rs:8788), because that call repaints draw_menu_bar across the
full menu_row_rect band and will erase anything drawn earlier — the exact
#552 round-2/3 "buttons render blank" regression.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #676: GTK: the VS Code-style Command Center (nav arrows + search box) was dropped by the #540 Relm4→ShellApp cutover and never re-wired

Summary

The GTK backend has silently lost its VS Code–style Command Center — the ◀ ▶ nav arrows
plus the centered 🔍 <project> search box in the title-bar row (quadraui's CommandCenter
primitive, landed for both backends in #310 / b5fdd7d). Clicking the search box is the
discoverable entry point to the unified picker with prefix routing (> commands, @ symbols,
: line, # …).

It is collateral damage from the Relm4 → ShellApp cutover, commit c35aea4
("feat(#540): flip GTK main loop from Relm4 to ShellApp runner (#448-C)", 2026-06-28).
That commit deleted impl SimpleComponent for App (~3,059 lines). Inside the deleted Relm4
view! scaffolding lived the titlebar DrawingArea draw closure that called
quadraui::gtk::draw_command_center(...) and stashed the result in engine.command_center_layout,
plus the sibling click handler that hit-tested it. The replacement
impl quadraui::ShellApp for App::render_content never ported either half.

This is the same bug family as the other #540 fallout already fixed one at a time — #546
(dialog / context menu never painted), #547 (nerd fonts), #552 (window controls / CSD), #555
(breadcrumb bar), #556 (dock icon), #557 (extension panels), #587 (picker + panel accelerators),
#544 (sidebar panel clicks). The command center is simply the one nobody re-listed.

Expected

On GTK, the title-bar row shows ◀ ▶ nav arrows and a centered 🔍 <project-name> search box
between the menu labels (File / Edit / View …) and the inline window controls (min / max / close).
Clicking ◀/▶ navigates tab history; clicking the search box opens the unified picker
(Engine::open_command_center()).

Actual

Nothing is painted in that region and nothing is clickable there. The band from the end of the
menu labels to the right window edge is claimed end-to-end by the window-controls status bar.

Repro

1. cargo run --features gui (GTK build).
2. Look at the title-bar row: File / Edit / View … on the left, min/max/close on the right,
   empty band in between — no arrows, no search box.
3. Click anywhere in that empty band → nothing happens.
4. Compare with the TUI (cargo run in vscode-mode, or Alt to reveal the menu bar): the arrows
   and search box are present and clickable.

Evidence — current state of the tree

	Paint	Click	Status
TUI	✅ src/tui_main/shell_app.rs:1359-1377 (ported by #635, Stage 6b item A)	✅ src/tui_main/mouse.rs:1978-1995	intact
GTK	❌ nothing in src/gtk/** calls draw_command_center or build_command_center_view	❌ no command_center_layout hit-test anywhere in src/gtk/	gone

Corroborating details:

• The real estate is being painted over. src/gtk/mod.rs:8255-8276 computes
  controls_rect = menu_end → right window edge, and src/gtk/mod.rs:8884 paints
  render::window_controls_status_bar across all of it. quadraui::gtk::draw_status_bar
  background-fills its entire rect (quadraui/src/gtk/status_bar.rs:73-80), so even the gap is
  claimed.
• engine.command_center_layout is permanently None on GTK — never written by the ShellApp
  path, so any hit-test would fail even if one existed.
• menu_bar_da is a dead husk. Declared src/gtk/mod.rs:509, initialised to None at
  :1544, and never assigned Some — four dead reads remain at :2134, :5452, :5460,
  :7532. That is the orphaned handle to the old Relm4 titlebar drawing area.
• src/gtk/draw.rs never had it — the legacy Cairo path (already dead under ShellApp) has no
  command-center code, so there is no second call site to revive. The only one was in mod.rs's
  deleted view! block.
• Docs are stale: PROJECT_STATE.md:92 still claims Command center (nav arrows + search box) | CommandCenter | ✅ | ✅.

What still works on GTK: :CommandCenter (src/core/engine/execute.rs:1999) and Ctrl+Shift+P
(accelerators restored in #587) both open the picker correctly. It is purely the bar — the
visible entry point and its arrows — that is missing.

Nothing was deleted from quadraui

The whole API surface is live and already exported, so this is wiring, not a rebuild:

• quadraui::{CommandCenter, CommandCenterHit, CommandCenterLayout, CommandCenterMeasure}
  (quadraui/src/lib.rs:159, primitive at quadraui/src/primitives/command_center.rs)
• Backend::draw_command_center (quadraui/src/backend.rs:1157) and
  Backend::command_center_layout (:1160) — trait methods, available to GTK today
• quadraui::gtk::draw_command_center (quadraui/src/gtk/command_center.rs:50) — the GTK
  rasteriser, still implemented and still wired into the GTK backend at
  quadraui/src/gtk/backend.rs:2882
• render::build_command_center_view (src/render.rs:4065) — backend-agnostic, already shared

Proposed fix

1. Narrow controls_rect. In render_content (src/gtk/mod.rs:8255-8276), measure the three
   window-control buttons with backend.status_bar_layout(...) and shrink the controls rect to
   just that right-aligned width, instead of handing them the entire menu_end → right edge band.
2. Paint the command center in the freed gap, using render::build_command_center_view( engine.tab_nav_can_go_back(), engine.tab_nav_can_go_forward(), &title) and
   backend.draw_command_center(gap_rect, &cc).
   Ordering is load-bearing: it must be painted after menu_system.borrow().render(...)
   (src/gtk/mod.rs:8788), which repaints draw_menu_bar across the full menu_row_rect band.
   Painting before it reproduces the #448-E: GTK window chrome lost after ShellApp flip — WM titlebar returns, menu bar + inline min/max buttons gone #552 round-2/3 "buttons render blank" regression verbatim.
3. Cache the layout into engine.command_center_layout (and clear it to None when
   menu_bar_visible is false), mirroring src/tui_main/shell_app.rs:1377 / :1381.
4. Hit-test on click in handle_mouse_click_msg (src/gtk/mod.rs:3698):
   Back → tab_nav_back(), Forward → tab_nav_forward(), SearchBox → open_command_center()
   — mirroring src/tui_main/mouse.rs:1983-1993. Must run before the window-controls
   hit-test so it isn't swallowed.
5. Delete the dead menu_bar_da field and its four dead reads.
6. Fix PROJECT_STATE.md:92 to reflect reality once the fix lands.

Design note — deliberate GTK/TUI divergence

GTK forces menu_bar_visible = true at startup (src/gtk/mod.rs:8171), whereas the TUI shows the
menu row only in vscode-mode or on Alt. So on GTK the command center returns permanently
visible — which is both the pre-#540 behaviour and the VS Code behaviour this was modelled on.
Gate the GTK paint on engine.menu_bar_visible anyway (same condition as TUI) so the two
backends stay structurally identical; the flag just happens to always be true on GTK.

Black-box test

Per CLAUDE.md this is behaviour-changing and needs a black-box test. Use the GTK headless
pixel-probe harness in src/gtk/testing.rs and follow the pattern established by #555
("test(#555): assert the breadcrumb dropdown paints via pixels, not painted text", 755d732) —
assert on painted pixels, not on painted text, since these are icon glyphs. Cover:

• the search box and both arrows paint inside the title-bar band, to the left of the window
  controls and to the right of the last menu label (no overlap with either);
• a click on the search box opens the picker (engine.picker_open == true with
  picker_source == PickerSource::CommandCenter);
• clicks on ◀/▶ drive tab-nav history;
• the window controls still paint and still respond (guard against re-breaking #448-E: GTK window chrome lost after ShellApp flip — WM titlebar returns, menu bar + inline min/max buttons gone #552).

Files

• src/gtk/mod.rs
• src/gtk/testing.rs
• PROJECT_STATE.md

[JDonaghy]

Coordinator: Assignment Complete

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

[JDonaghy]

🧊 Pipeline row stalled

Machine: dellserver
Assignment: 6dfe85cda171
Issue: #676
Reason: Work done, no review ever dispatched

Work is done with test_state='passed' but no review assignment was ever dispatched for it.

Detection + surfacing only — nothing was dispatched automatically. This row's auto-loop transition already fired once and won't fire again on its own; a human should look at coord status and decide whether to dispatch a fix/review manually or drop it with coord backlog.

[JDonaghy]

Coordinator: Assignment Complete

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

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

None.

Nits

• src/gtk/mod.rs (new MouseDown handler in handle()): only matches button: MouseButton::Left; correct behavior (nav-arrow/search-box are left-click actions) but a short comment noting other buttons intentionally fall through would help a future reader.

[JDonaghy]

Review Complete — ✅ Approved

Reviewer could not post directly to a PR (no PR number available). Findings are reproduced here.

Note: a completion comment was posted earlier but findings could not be extracted at that time. These are the retroactive findings.

Reviewed branch issue-676-gtk-the-vs-code-style-command-center-nav (diff: git diff origin/develop...origin/issue-676-gtk-the-vs-code-style-command-center-nav), commit 4de0265. Diff touches only src/gtk/mod.rs and src/gtk/testing.rs, in line with the operator's pinned constraint to keep this to src/gtk/** and leave PROJECT_STATE.md/PLAN.md untouched (confirmed: not touched).

Platform-neutrality check (mandatory rule): Verified this is thin event-to-engine wiring, not new backend logic. render::build_command_center_view, engine.command_center_layout, engine.tab_nav_can_go_back/forward, and Backend::draw_command_center all pre-exist and are already used identically by src/tui_main/shell_app.rs / render_impl.rs / mouse.rs (confirmed via grep — TUI has used them since #635). Confirmed in the quadraui checkout (~/src/quadraui/quadraui/src/gtk/{command_center.rs,backend.rs}) that the GTK backend's draw_command_center painting implementation already exists in quadraui itself — vimcode's GTK side only computes a rect (via the already-shared backend.status_bar_layout measurement, not hand-rolled geometry) and calls the trait method. This matches the exact TUI pattern and does not violate the Platform-Neutrality Rule.

Correctness:

• The controls_rect narrowing logic correctly measures the window-control buttons' real painted width via backend.status_bar_layout (the same call draw_status_bar uses) instead of reusing the old full menu_end→right-edge band, which is what was silently eating the Command Center's space — this is the actual bug fix.
• command_center_rect computed only when menu_bar_visible && menu_row_rect.height > 0.0, else command_center_layout is cleared to None — verified by a dedicated test.
• Click routing: the new MouseDown handling block is correctly placed after the menu-system intercept (so menu item/dropdown clicks aren't hijacked) and before the window-control buttons and CSD drag-to-move fallback (so command-center clicks don't start a window drag) — matches the documented TUI precedence in mouse.rs.
• Msg::MruNavBack/MruNavForward/OpenCommandCenter and their handle_menu_msg arms were already present (pre-#448-C: Flip GTK main loop from Relm4 to ShellApp runner; delete Relm4 scaffolding (sub-task 3/3 of #448) #540 leftovers per the commit message) and are correctly routed via the existing dispatch match arm — this PR just adds the first live caller.
• The menu_bar_da field removal is legitimate dead-code cleanup: confirmed via git show origin/develop:src/gtk/mod.rs that it was initialized to None and never once set to Some(...) anywhere in develop — every if let Some(ref da) = ...borrow() guarding it was already unreachable since the #448-C: Flip GTK main loop from Relm4 to ShellApp runner; delete Relm4 scaffolding (sub-task 3/3 of #448) #540 cutover. All 6 references were removed cleanly (verified zero remain in the branch's file).
• title_bar_rect: Cell<Rect> → Rc<Cell<Rect>>: minimal, mechanical change needed only so the test harness can clone a handle to it (mirrors the existing pattern for picker_popup_rect etc.); .get()/.set() call sites are unaffected since Rect is Copy.

Test coverage (black-box bar): Three new driver tests added under mod command_center in testing.rs, all using GtkDriver:

1. command_center_paints_between_menu_labels_and_window_controls — asserts painted-pixel content (not just layout-cache presence) via a coarse pixel-scan against the theme background color, explicitly following the "pixels for icon glyphs" rule from the review checklist (arrows are Unicode ◀/▶, search box is icon+border). Also asserts non-overlap with the real title_bar_rect window-controls rect — the actual regression this issue fixes.
2. command_center_click_routes_nav_and_opens_picker — clicks back/forward arrows and asserts real engine state changes (active_tab().id changes and reverts), then clicks the search box and asserts picker_open + picker_source == PickerSource::CommandCenter. This is genuine end-to-end behavioral proof, not a layout-cache check.
3. command_center_layout_clears_when_menu_bar_is_hidden — guards the clear-on-hide path.

The module doc comment explicitly states each test "was verified to fail red against the pre-fix tree ... before this module was added," satisfying the requirement that a behavior-changing PR state its new tests were observed RED against unfixed develop.

Security: None applicable — pure UI geometry/painting/click-routing, no I/O, no injection surface.

I did not run the build or test suite per the review instructions (forbidden for this task); reviewed via static diff inspection and cross-referencing the quadraui source tree for the shared-infra claims.

Blocking findings

None.

Non-blocking concerns

None.

Nits

• src/gtk/mod.rs (new MouseDown handler in handle()): only matches button: MouseButton::Left; correct behavior since nav-arrow/search-box are left-click actions, but a short comment noting other buttons intentionally fall through (to the drag-to-move / other handlers) would help a future reader who wonders why right/middle-click does nothing there.