GTK VS Code parity: menu dropdown paints in the editor font, not the menu-bar UI font; command-centre row is one editor line tall

[JDonaghy]

Sibling of #699 (VS Code visual-parity audit). Two defects visible in one screenshot of
the GTK build (Edit menu open, command centre showing vimcode in the title-bar row):

1. The open menu dropdown does not paint in the menu-bar's font. File Edit View Go Run Terminal renders in the UI font; the dropdown under it (Undo / Redo / Cut / Copy / Paste / Find / Replace + accelerators) renders in a visibly different,
   larger face — the editor font — on editor-line-height row pitch. VS Code paints bar
   and dropdown in the same UI font at the same size.
2. The command centre ("omnibar") is too short. The rounded search box in the
   title-bar row is a few px shy of the row it sits in, and the row itself is one
   editor line tall. VS Code's title bar is 35 px with a ~26 px command-centre pill;
   ours reads squat next to it.

Both are metrics/type-stack problems, not layout-structure problems — the same class as
#699, which predates the command centre existing (it lists "the command-center pill in
the title bar" under Out of scope for exactly that reason).

1. Dropdown font — quadraui#637 (filed, and this issue is queued behind it)

MenuSystem::render paints the bar with Backend::draw_menu_bar and the open dropdown
with Backend::draw_context_menu (quadraui src/compose/menu_system.rs:102-110). At
the pinned rev 097eb5f4:

Primitive	Applies self.ui_font?	Where
draw_menu_bar	yes — sets ui_font on the shared layout before rasterising, restores after	quadraui/src/gtk/backend.rs:2708, :2725
draw_dialog	yes — builds ui_font_desc and passes it in	quadraui/src/gtk/backend.rs:2375
draw_context_menu	no — hands the shared pango_layout straight through, plus self.current_line_height for row pitch	quadraui/src/gtk/backend.rs:2341-2364
draw_command_center	no — same shape	quadraui/src/gtk/backend.rs:3064-3085

So the dropdown inherits whatever font description was last set on the frame's shared
Pango layout — the editor font — and sizes its rows off the editor line height. Two
primitives quadraui#624's chrome sweep never listed; the same gap is why the command
centre's ◀ ▶ arrows and its vimcode search label paint in the editor font rather
than the UI font. One root cause, two surfaces.

The quadraui half is already filed as JDonaghy/quadraui#637 and this issue is queued
--after it — do not re-file it, and do not fix it here. Per the Platform-Neutrality
Rule, do not work around it in src/gtk/ by setting the layout font before
menu_system.render() either.

What item 1 is on this side, once #637 has merged and released:

1. Bump Cargo.toml:62's rev to a quadraui rev containing Extension panel input dies intermittently: scrollwheel never works, and the scrollbar/? stop responding after a help-popup dismiss or an editor focus round-trip #637 — a deliberate,
   reviewable commit, the same move vimcode#705 made for #602: [fix-1] #595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #623/#603: #595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #624/CI-only test flakiness: 6 insta snapshots + ext_sidebar_intercept_claims_focus_on_mouse_down fail on GH Actions but pass locally #625. Bump vt100's
   rev at :124 to match; the two are pinned to the same repo and must not diverge.
2. Verify it actually reached the surface — the failure mode this whole epic keeps
   hitting (VS Code parity (Tier 1 of #699): GTK chrome metrics — explorer row, tab/breadcrumb height, tab ordinals, mnemonics, indent guides #700 item 1, VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #704 item 1) is a change that looks done and moves no pixels.
   Assert it, don't eyeball it.

If the bumped rev turns out not to fix it — the dropdown still paints in the editor
font — stop and report that on #637 rather than patching around it in vimcode.

2. Command-centre height — with_title_bar(1.0) (vimcode-side)

src/gtk/mod.rs:10426 reserves the title-bar/menu band as
ShellConfig::with_title_bar(1.0) — 1.0 x editor line height, so the whole row
scales with the editor font and lands around one line (~24 px at the default
font_size = 14; measure rather than trusting that number). Everything downstream is
derived from it:

• menu_row_rect = layout.title_bar_bounds (src/gtk/mod.rs:8201), and the command
  centre gets cc_rect with exactly menu_row_rect.height (src/gtk/mod.rs:8268-8272);
• the pill is then painted at sb.height - 4.0 (quadraui
  src/gtk/command_center.rs, search-box block) inside that band.

So the box cannot be taller than the band, and the band is an editor-font multiple.
Target: VS Code's 35 px title bar with a ~26 px command-centre pill.

Raising the multiplier is a one-line vimcode change and is the fix asked for here.
Note the residual: ShellConfig::with_title_bar takes height_lh (a line-height
multiple) only, so a fixed-px, font-independent band — what #699 Tier 1 items 2 and 3
argue for on the tab and breadcrumb rows — needs an absolute-height reservation in
quadraui. Pick the multiplier now and note in the PR whether a quadraui px-based
reservation should be filed, rather than silently leaving the row font-coupled.

Acceptance

GtkDriver (src/gtk/testing.rs), asserting on rendered output — see the existing
command_center module there (command_center_paints_between_menu_labels_and_window_controls)
for the harness shape:

• with a menu open, the dropdown's item glyph extents (or row pitch) track the UI
  font, not the editor font: change settings.font_size and the dropdown metrics must
  not move, while changing ui_font_size must;
• the title-bar band height and the command-centre pill height are stable across at
  least two different settings.font_size values, or — if the band stays an lh
  multiple — the pill height matches the intended target at the default size. A
  single-font-size assertion passes with the bug reinstated, so pin it with two.

Both items are inherently visual: attach a before/after screenshot to the PR in
addition to the assertions.

Files

• src/gtk/mod.rs
• Cargo.toml

Depends on

JDonaghy/quadraui#637 (item 1 — the pin bump has nothing to bump to until it lands).
Item 2 is vimcode-side and independent; if #637 stalls, item 2 can be split out and
shipped alone rather than held hostage.

Not this issue

• GTK menu bar: top-level entries poorly spaced (missing space between 'View' and 'Go') #235 (menu-bar top-level entry spacing) and GTK context menu: 1 px Cairo border barely visible — needs higher contrast or rounded chrome #236 (context-menu border contrast) are
  separate defects on adjacent surfaces.
• GTK chrome: close the visual gap with VS Code — type size, vertical rhythm, tab/breadcrumb metrics #699's Tier 1/2/3 metric work stands on its own; this issue only borrows its
  vocabulary.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #710: GTK VS Code parity: menu dropdown paints in the editor font, not the menu-bar UI font; command-centre row is one editor line tall

Sibling of #699 (VS Code visual-parity audit). Two defects visible in one screenshot of
the GTK build (Edit menu open, command centre showing vimcode in the title-bar row):

1. The open menu dropdown does not paint in the menu-bar's font. File Edit View Go Run Terminal renders in the UI font; the dropdown under it (Undo / Redo / Cut / Copy / Paste / Find / Replace + accelerators) renders in a visibly different,
   larger face — the editor font — on editor-line-height row pitch. VS Code paints bar
   and dropdown in the same UI font at the same size.
2. The command centre ("omnibar") is too short. The rounded search box in the
   title-bar row is a few px shy of the row it sits in, and the row itself is one
   editor line tall. VS Code's title bar is 35 px with a ~26 px command-centre pill;
   ours reads squat next to it.

Both are metrics/type-stack problems, not layout-structure problems — the same class as
#699, which predates the command centre existing (it lists "the command-center pill in
the title bar" under Out of scope for exactly that reason).

1. Dropdown font — quadraui#637 (filed, and this issue is queued behind it)

MenuSystem::render paints the bar with Backend::draw_menu_bar and the open dropdown
with Backend::draw_context_menu (quadraui src/compose/menu_system.rs:102-110). At
the pinned rev 097eb5f4:

Primitive	Applies self.ui_font?	Where
draw_menu_bar	yes — sets ui_font on the shared layout before rasterising, restores after	quadraui/src/gtk/backend.rs:2708, :2725
draw_dialog	yes — builds ui_font_desc and passes it in	quadraui/src/gtk/backend.rs:2375
draw_context_menu	no — hands the shared pango_layout straight through, plus self.current_line_height for row pitch	quadraui/src/gtk/backend.rs:2341-2364
draw_command_center	no — same shape	quadraui/src/gtk/backend.rs:3064-3085

So the dropdown inherits whatever font description was last set on the frame's shared
Pango layout — the editor font — and sizes its rows off the editor line height. Two
primitives quadraui#624's chrome sweep never listed; the same gap is why the command
centre's ◀ ▶ arrows and its vimcode search label paint in the editor font rather
than the UI font. One root cause, two surfaces.

The quadraui half is already filed as JDonaghy/quadraui#637 and this issue is queued
--after it — do not re-file it, and do not fix it here. Per the Platform-Neutrality
Rule, do not work around it in src/gtk/ by setting the layout font before
menu_system.render() either.

What item 1 is on this side, once #637 has merged and released:

1. Bump Cargo.toml:62's rev to a quadraui rev containing Extension panel input dies intermittently: scrollwheel never works, and the scrollbar/? stop responding after a help-popup dismiss or an editor focus round-trip #637 — a deliberate,
   reviewable commit, the same move vimcode#705 made for #602: [fix-1] #595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #623/#603: #595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #624/CI-only test flakiness: 6 insta snapshots + ext_sidebar_intercept_claims_focus_on_mouse_down fail on GH Actions but pass locally #625. Bump vt100's
   rev at :124 to match; the two are pinned to the same repo and must not diverge.
2. Verify it actually reached the surface — the failure mode this whole epic keeps
   hitting (VS Code parity (Tier 1 of #699): GTK chrome metrics — explorer row, tab/breadcrumb height, tab ordinals, mnemonics, indent guides #700 item 1, VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #704 item 1) is a change that looks done and moves no pixels.
   Assert it, don't eyeball it.

If the bumped rev turns out not to fix it — the dropdown still paints in the editor
font — stop and report that on #637 rather than patching around it in vimcode.

2. Command-centre height — with_title_bar(1.0) (vimcode-side)

src/gtk/mod.rs:10426 reserves the title-bar/menu band as
ShellConfig::with_title_bar(1.0) — 1.0 x editor line height, so the whole row
scales with the editor font and lands around one line (~24 px at the default
font_size = 14; measure rather than trusting that number). Everything downstream is
derived from it:

• menu_row_rect = layout.title_bar_bounds (src/gtk/mod.rs:8201), and the command
  centre gets cc_rect with exactly menu_row_rect.height (src/gtk/mod.rs:8268-8272);
• the pill is then painted at sb.height - 4.0 (quadraui
  src/gtk/command_center.rs, search-box block) inside that band.

So the box cannot be taller than the band, and the band is an editor-font multiple.
Target: VS Code's 35 px title bar with a ~26 px command-centre pill.

Raising the multiplier is a one-line vimcode change and is the fix asked for here.
Note the residual: ShellConfig::with_title_bar takes height_lh (a line-height
multiple) only, so a fixed-px, font-independent band — what #699 Tier 1 items 2 and 3
argue for on the tab and breadcrumb rows — needs an absolute-height reservation in
quadraui. Pick the multiplier now and note in the PR whether a quadraui px-based
reservation should be filed, rather than silently leaving the row font-coupled.

Acceptance

GtkDriver (src/gtk/testing.rs), asserting on rendered output — see the existing
command_center module there (command_center_paints_between_menu_labels_and_window_controls)
for the harness shape:

• with a menu open, the dropdown's item glyph extents (or row pitch) track the UI
  font, not the editor font: change settings.font_size and the dropdown metrics must
  not move, while changing ui_font_size must;
• the title-bar band height and the command-centre pill height are stable across at
  least two different settings.font_size values, or — if the band stays an lh
  multiple — the pill height matches the intended target at the default size. A
  single-font-size assertion passes with the bug reinstated, so pin it with two.

Both items are inherently visual: attach a before/after screenshot to the PR in
addition to the assertions.

Files

• src/gtk/mod.rs
• Cargo.toml

Depends on

JDonaghy/quadraui#637 (item 1 — the pin bump has nothing to bump to until it lands).
Item 2 is vimcode-side and independent; if #637 stalls, item 2 can be split out and
shipped alone rather than held hostage.

Not this issue

• GTK menu bar: top-level entries poorly spaced (missing space between 'View' and 'Go') #235 (menu-bar top-level entry spacing) and GTK context menu: 1 px Cairo border barely visible — needs higher contrast or rounded chrome #236 (context-menu border contrast) are
  separate defects on adjacent surfaces.
• GTK chrome: close the visual gap with VS Code — type size, vertical rhythm, tab/breadcrumb metrics #699's Tier 1/2/3 metric work stands on its own; this issue only borrows its
  vocabulary.

[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:10426 — the commit message explicitly flags that the with_title_bar(1.7) fix is still an lh-multiple workaround (no fixed-px band reservation API exists in quadraui yet) and that a quadraui issue for that gap was not filed as part of this PR, asking the reviewer to decide. Given GOALS.md's push to lift platform-specific tuning into quadraui, I'd recommend filing that quadraui issue now (even if not fixed immediately) so the residual doesn't get lost — but I don't consider this blocking, since the change itself is a legitimate 1-line parameter tweak to an already-existing shared-API knob, not new backend-specific code, and is honestly documented in both the inline comment and the commit message.
• No PROJECT_STATE.md/PLAN.md update accompanies this fix. Given the small, self-contained scope (quadraui pin bump + one parameter tweak + tests) this is likely fine, but worth a quick confirmation with the user per the Session Start Protocol's doc-maintenance step.

Nits

• None.

Summary

Diff: Cargo.toml/Cargo.lock (quadraui pin bump to 227a8c4, landing quadraui#637 which fixes the dropdown-font bug in quadraui's GtkBackend::draw_context_menu/draw_command_center), src/gtk/mod.rs (with_title_bar(1.0) → with_title_bar(1.7), well-commented), and src/gtk/testing.rs (two new GtkDriver black-box tests).

Platform-neutrality: correctly respected. Item 1 (dropdown font) was fixed in quadraui itself and pulled in via a rev bump — no new GTK-specific code. Item 2 (command-centre row height) is a genuine 1-line parameter change to an already-existing quadraui ShellConfig::with_title_bar knob, which qualifies as "thin wiring" under the Platform-Neutrality Rule; the inline comment is transparent about the residual (still lh-coupled, not fixed-px) rather than silently working around it.

Testing: both new tests are driver-tier (GtkDriver), assert on painted output (find_bounds glyph extents, title_bar_rect/search_bounds geometry actually used to paint the band/pill — same established pattern as the pre-existing command_center_click_routes_nav_and_opens_picker-adjacent test at testing.rs:3118 that already uses title_bar_rect), use positive-control + regression-guard structure consistent with the sibling breadcrumb_text_width_tracks_ui_font_size_not_editor_font_size / tab_label_width_tracks_ui_font_size_not_editor_font_size tests, and the commit message explicitly states both were verified RED against the unfixed state (pre-#637 pin / with_title_bar(1.0)) before being restored to pass — satisfying the "test must be able to fail" bar.

Scope is tight: only files touching the two issue items are changed. No coordinator-owned docs (CLAUDE.md) touched. No security concerns (no user input, no injection surface). Verified field types (settings.font_size: i32, settings.ui_font_size: u8) and helper functions (harness, engine_with_tab_history, GtkDriver::find_bounds/click/render) used in the new tests match the existing codebase exactly, so the tests should compile against real APIs, not invented ones.

I did not run cargo test/cargo build per reviewer instructions (build/test validation is the separate pre-merge smoke gate's job); this assessment is from static reading of the diff and surrounding code only.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 3m 46s
Log: /home/john/.coord/logs/6cbe37d5faaa.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 17m 35s
Log: /home/john/.coord/logs/d96230ecfffb.log

[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.

Blocking findings

None.

Non-blocking concerns

• src/gtk/mod.rs:10426 — the commit message explicitly flags that the with_title_bar(1.7) fix is still an lh-multiple workaround (no fixed-px band reservation API exists in quadraui yet) and that a quadraui issue for that gap was not filed as part of this PR, asking the reviewer to decide. Given GOALS.md's push to lift platform-specific tuning into quadraui, I'd recommend filing that quadraui issue now (even if not fixed immediately) so the residual doesn't get lost — but I don't consider this blocking, since the change itself is a legitimate 1-line parameter tweak to an already-existing shared-API knob, not new backend-specific code, and is honestly documented in both the inline comment and the commit message.
• No PROJECT_STATE.md/PLAN.md update accompanies this fix. Given the small, self-contained scope (quadraui pin bump + one parameter tweak + tests) this is likely fine, but worth a quick confirmation with the user per the Session Start Protocol's doc-maintenance step.

Nits

None.

Summary

Diff: Cargo.toml/Cargo.lock (quadraui pin bump to 227a8c4, landing quadraui#637 which fixes the dropdown-font bug in quadraui's GtkBackend::draw_context_menu/draw_command_center), src/gtk/mod.rs (with_title_bar(1.0) → with_title_bar(1.7), well-commented), and src/gtk/testing.rs (two new GtkDriver black-box tests).

Platform-neutrality: correctly respected. Item 1 (dropdown font) was fixed in quadraui itself and pulled in via a rev bump — no new GTK-specific code. Item 2 (command-centre row height) is a genuine 1-line parameter change to an already-existing quadraui ShellConfig::with_title_bar knob, which qualifies as "thin wiring" under the Platform-Neutrality Rule; the inline comment is transparent about the residual (still lh-coupled, not fixed-px) rather than silently working around it.

Testing: both new tests are driver-tier (GtkDriver), assert on painted output (find_bounds glyph extents, title_bar_rect/search_bounds geometry actually used to paint the band/pill — same established pattern as the pre-existing test at testing.rs:3118 that already uses title_bar_rect), use positive-control + regression-guard structure consistent with sibling *_tracks_ui_font_size_not_editor_font_size tests, and the commit message explicitly states both were verified RED against the unfixed state (pre-#637 pin / with_title_bar(1.0)) before being restored to pass — satisfying the "test must be able to fail" bar.

Scope is tight: only files touching the two issue items are changed. No coordinator-owned docs (CLAUDE.md) touched. No security concerns (no user input, no injection surface). Verified field types (settings.font_size: i32, settings.ui_font_size: u8) and helper functions used in the new tests match the existing codebase exactly.

I did not run cargo test/cargo build per reviewer instructions; this assessment is from static reading of the diff and surrounding code only.