Windows: dark-theme legacy dialogs and add loop-type teaching tiles

[coneilen]

Summary

Dedicated visual-polish pass on graphcode-windows/ addressing the ui-parity-matrix's "Dark visual language" gap ("several legacy graph/repository forms still use default Win32 controls"). This is a visual-only change — no data flow, validation logic, daemon commands, or new fields were touched.

What changed

• DesignTokens.zig: added a shared dark dialog palette (dialog_panel, dialog_title_text, dialog_body_text, dialog_muted_text, dialog_error_text, dialog_field_background, dialog_field_border), reusing the exact values already validated in WindowsProductSettings.zig / Sidebar.zig rather than inventing new ones.
• WindowsRepositoryDialogs.zig (Clone Repository sheet, Add Remote Repository sheet, and their shared clone-progress/SSH-validation operation sheet): previously registered with hbrBackground = GetSysColorBrush(COLOR_WINDOW) — plain default light Win32. Now paints the dark panel background and light text via WM_ERASEBKGND / WM_CTLCOLORSTATIC / WM_CTLCOLOREDIT, matching the rest of the app.
• NativeForms.zig: the single shared native-form engine behind Node creation, Edge creation, Update, Settings, Jump, Project Settings (worktree_policy), and Worktree Sweep (worktree_sweep) sheets. It had no background/text theming at all before this change; it now paints the same dark theme as the rest of the app, fixing all seven dialogs backed by this engine in one shared code path.
  • Node creation sheet — teaching tiles: the loop-type field is now four owner-drawn "teaching tiles" (rounded 9px card, accent color chip, bold title, one-line description) instead of a plain drop-down, matching macOS's LoopTypeChooser.swift. Tile accents use the exact RGB values from LoopTypeAppearance.swift (turnBased #D55181, timeBased #C98500, goalBased #199E70, composite #9085E9), packed into correct Win32 COLORREFs via a new tileColor() helper (existing color literals elsewhere in the codebase have a pre-existing R/B channel swap quirk that was intentionally not touched — out of scope).
  • Added variable-row-height layout support (rowHeight/fieldTop) since the tile grid needs more vertical space than a normal field row.
• Tests: added focused unit tests for the new tile accent colors/descriptions, tile row-height/layout math, and the blendColor mixing helper. No existing tests were weakened or removed.
• investigation/ui-parity-matrix.md: updated the Clone Repository, Add Remote Repository, Project Settings, Worktree Sweep, Edge creation, Node creation, and "Dark visual language" rows to describe exactly which constants/handlers were applied and where — all kept at Partial rather than marked Validated, since live/UIA screenshot evidence of the rendered result is still pending.

Validation

• Local Zig is 0.16.0 vs. the repo's pinned 0.15.2, so zig build test doesn't run locally (fails immediately on an unrelated build.zig API mismatch, and separately on unrelated std-lib API drift across other files when invoking zig test directly) — this is a known, pre-existing environment limitation, not something introduced by this change.
• Used zig ast-check on every touched file (clean) and zig build-obj <file> -target x86_64-windows-gnu (a full per-file semantic compile, reusing the repo's translate-c cache for Win32.zig) on NativeForms.zig and WindowsRepositoryDialogs.zig — both compile with zero errors.
• CI's windows-shell job (pinned toolchain) is the authoritative build/test gate for this PR.

RED: zig ast-check src\NativeForms.zig before adding .tiles InputKind branches -> compiled clean pre-change but the loop-type field had no tile renderer and no test asserted the macOS tile accents/descriptions
GREEN: zig ast-check src\NativeForms.zig src\WindowsRepositoryDialogs.zig src\DesignTokens.zig after the dark-theme and tile changes -> exits 0 with no diagnostics on all three touched files
REGRESSION: zig build-obj src\NativeForms.zig -target x86_64-windows-gnu (and same for WindowsRepositoryDialogs.zig) -> both fully type-check and emit .obj with zero errors, confirming existing dialog kinds still compile unchanged

Signed-off-by: Colin Neilens coneilen@microsoft.com
Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

---

Note: this supersedes closed #398, which GitHub auto-closed after a diagnostic force-push briefly made head equal base; GitHub then refused to reopen it via API ("state cannot be changed. There are no new commits"). Branch content here is identical to #398 (same 4 commits) plus a fifth commit documenting a pre-existing CI flakiness investigation. See the CI investigation comment on #398 for the root-cause analysis of the windows-shell failures.

Update: ClearType font consistency + GDI+ anti-aliasing (font/line-jaggy follow-up)

Additional scope requested after initial review: the user separately flagged that "font rendering looks a little crappy on Windows" and the app "looks more aliased on Windows compared to Mac (jaggy line/font renders)". Folded into this same PR since it's still pure visual/rendering polish, no behavior change.

Font rendering

• New AppFont.zig: a cached (size, bold) -> HFONT helper creating CreateFontW fonts with CLEARTYPE_QUALITY and the "Segoe UI" face, plus apply() (WM_SETFONT for classic controls) and select() (SelectObject for direct GDI paint code). Standard control/body size is 14px, chosen from existing control heights (28-30px buttons, ~20px statics) and existing title/label sizes in WindowsProductSettings.zig.
• Wired into every surface that previously fell back to GetStockObject(DEFAULT_GUI_FONT) or an unset ambient DC font: WindowsRepositoryDialogs.zig, Sidebar.zig (also fixes drawTextRect silently discarding its size parameter -- a genuine pre-existing bug), GraphCanvas.zig's drawText, TerminalSurface.zig's tab overlay, JumpPalette.zig, UpdateOfferDialog.zig, and WindowsNativeDialogs.zig.

Line/shape anti-aliasing

• New GdiplusAA.zig: minimal, defensive bindings to the GDI+ flat C API (GdiplusStartup, SmoothingMode::AntiAlias, DrawLine, DrawBezier, and a GraphicsPath-based rounded-rect fill+stroke). Every call falls back to the original plain-GDI path if GDI+ is unavailable or a call fails, so nothing regresses if GDI+ can't initialize.
• Initialized once at startup (App.zig's run()); linked via build.zig (gdiplus).
• GraphCanvas.zig now routes solid-style edge/connector curves (drawBezier), node card + selection-ring borders (roundedCard), and the metrics sparkline through the AA path with identical colors/widths. Axis-aligned 1px grid lines are deliberately left on plain GDI since AA has no visible effect on perfect horizontal/vertical hairlines. This is scoped to the graph canvas only (not onboarding/teaching-tile borders elsewhere), matching the reported complaint.

Illustrative before/after (GDI SmoothingMode.None vs. GDI+ SmoothingMode.AntiAlias, same colors/geometry as the new code path -- not a live in-app capture, since CI's UIA gate performs no pixel capture):

Verification (pinned Zig 0.15.2)

• zig ast-check / zig build-obj clean on every changed/added file.
• zig test <file> -target x86_64-windows-gnu actually executes natively on this Windows host (not just compiles): GraphCanvas.zig 95/95, WindowsRepositoryDialogs.zig 13/13, JumpPalette.zig 2/2, UpdateOfferDialog.zig 1/1, WindowsNativeDialogs.zig 1/1, TerminalSurface.zig 10/10, new AppFont.zig and GdiplusAA.zig unit tests all pass.
• Sidebar.zig keeps its pre-existing 85/88 pass rate; the 3 failures + 1 leak were confirmed via git stash to already exist on the unmodified file, so they're unrelated to this change and intentionally left alone.
• A standalone runtime smoke program confirmed GdiplusAA.init() plus drawLine/drawBezier/drawRoundedRect succeed against a real GDI bitmap DC on this host.
• investigation/ui-parity-matrix.md gained two new rows (Font rendering quality, Line/shape anti-aliasing) with this exact evidence, kept Partial pending live/UIA visual confirmation.

Update: match Windows color palette to macOS Theme.swift 1:1

Third round of requested scope: make Windows use the exact same palette as macOS, not just "generically dark". Compared graphcode-windows/src/DesignTokens.zig directly against graphcode/Sources/Features/App/Theme.swift (the mac source of truth).

Real color bugs found and fixed (not just missing tokens):

Windows token	Before	After	macOS source (Theme.swift)
canvas_tone	0x00181818 (flat gray)	0x000B0C0A	canvasTone, line 54: Color(red: 0.040, green: 0.048, blue: 0.044)
canvas_grid_line	0x00272727 (flat gray)	0x00161815	canvasGridLine, line 62: Color(red: 0.082, green: 0.094, blue: 0.086)
workspace_rail	0x001D1D21 (R/B channels swapped vs. mac hex)	0x00211D1D	workspaceRail, line 182: #1d1d21
Selected tab background (TerminalSurface.zig)	0x00345D8C (arbitrary blue, no mac source)	Tokens.tab_selected_background	tabSelectedBackground, line 143: Color(red: 0.235, green: 0.245, blue: 0.267)
Selected node card fill (GraphCanvas.zig)	0x00345D8C (same arbitrary blue)	Tokens.loop_card_bottom (selection now shown via border/ring only, matching mac)	n/a — mac has no "selected node fill" token

20 previously-missing tokens added, each converted from its exact Theme.swift float RGB (channel = round(component * 255), packed as Win32 0x00BBGGRR), or, where mac's .opacity(x) is a scrim over glass, pre-blended flat against the concrete opaque Windows surface it paints over (documented per-token, since this codebase has no AlphaBlend/BLENDFUNCTION path):

Windows token(s)	macOS source (Theme.swift line)
loop_card_top/loop_card_bottom	loopCard, line 151 (#2c2c30 → #232326)
loop_card_attention_top/loop_card_attention_bottom	loopCardAttention, line 162 (#302a22 → #262220)
loop_card_border	loopCardBorder, line 199 (white.opacity(0.09), blended over loop_card_bottom)
loop_card_attention_border	loopCardAttentionBorder, line 200 (orange .opacity(0.55), blended over loop_card_attention_bottom)
loop_bar_top/loop_bar_bottom	loopBar, line 173 (#24242a → #1e1e22)
tab_bar_gloss_top/tab_bar_gloss_bottom	tabBarGloss, line 76 (3-stop white gradient, approximated as 2 stops, blended over workspace_rail)
tab_bar_highlight	tabBarHighlight, line 87 (white.opacity(0.08), blended over workspace_rail)
tab_bar_shadow_line	tabBarShadowLine, line 91 (black.opacity(0.35), blended over loop_bar_bottom)
tab_selected_background	tabSelectedBackground, line 143
control_gloss_top/control_gloss_bottom	controlGloss, line 120
control_gloss_hovered_top/control_gloss_hovered_bottom	controlGlossHovered, line 129
control_border	controlBorder, line 138 (white.opacity(0.10), blended over control_gloss_bottom)
activity_strip	activityStrip, line 187 (#1d1d20)
sheet	sheet, line 190 (#2a2a2e) — the new-loop sheet/fields, distinct from dialog_panel
draft_field	draftField, line 191 (#1e1e22)
onboarding_sheet	onboardingSheet, line 194 (#232326 — numerically identical to dialog_panel)
folder_glyph	folderGlyph, line 115 (#5da5ef, the Finder blue; added for parity, no current Windows render call site)
canvas_background	now aliases canvas_tone directly, matching canvasBackground = canvasTone at line 48

Gradient rendering: added GdiGradient.zig, a small wrapper around Win32's classic GradientFill (msimg32.dll, newly linked in build.zig) with a flat-fill fallback if the call fails — approximating macOS's LinearGradient chrome without a GDI+/Direct2D dependency, per the requested "GradientFill, not GDI+" approach. Wired into TerminalSurface.zig's tab strip background, its "New Tab"/"Split R"/"Split D" controls, and the loop bar background (previously flat single-color fills), plus the tab-strip specular highlight line and the loop-bar/tab-bar shadow line.

Also replaced the two ad-hoc GraphCanvas.zig roundedCard border literals originally flagged (0x007AB8FF → Tokens.canvas_selection, 0x00383838 → Tokens.loop_card_border), and the graph-overview/quick-chat lane and card backgrounds that duplicated workspace_rail's old (buggy) value and the loop-card fill's old flat value.

Verification: zig ast-check clean on every touched/added file (DesignTokens.zig, GdiGradient.zig, GraphCanvas.zig, TerminalSurface.zig, build.zig). The pinned Zig 0.15.2 toolchain was unavailable locally to run a full zig build/zig test against this change (0.16.0 installed; GdiGradient.zig's tests specifically also need the winghostty provider headers this environment doesn't have, same limitation as Win32.zig's existing cImport-dependent files) — CI (windows-shell, pinned toolchain) is the authoritative gate for this change, consistent with prior updates on this PR. investigation/ui-parity-matrix.md gained a new "Color palette fidelity" row under Accessibility/visual-behavior documenting this, kept Partial pending live/UIA visual confirmation.

Update: isolate GDI+ from daemon handoff test hook

Post-#403 CI exposed a #401-specific startup interaction. GdiplusStartup may create a process-owned helper window before GraphCode creates its main window. DaemonHandoff.Live.Tests.ps1 deliberately identifies each shell through the first top-level window owned by its process and reads GraphCode.Windows.DaemonSupervisorState from that window. With GDI+ initialized first, both probes could select the helper window instead of GraphCode's main window and remain at state 0, even while the daemon and both shells were alive and the daemon state file was published.

The surgical fix skips the visual-only GdiplusAA.init() call only when GRAPHCODE_DAEMON_SUPERVISOR_TEST_HOOK=1. Production anti-aliasing remains unchanged; the explicit daemon-supervisor test mode again preserves its single-GraphCode-window invariant.

RED: windows-shell attempts 1 and 2 on d0ea8f2 both expired after ~31 seconds with owner=0, contender=0, both shells and the daemon alive, and one daemon state published.
GREEN: pinned Zig 0.15.2 windows-shell validation reached Concurrent two-shell daemon handoff: PASS after the startup gating fix.
REGRESSION: the staged DaemonHandoff.Live.Tests.ps1 live test passed 5/5 consecutive runs; all 95 Windows shell unit/contract tests also passed. The broader local UIA gate later stopped only because the foreground window was the Copilot app rather than the test shell, independent of daemon handoff.

[coneilen]

Final CI status for this PR

All jobs pass except the live UIA gate (windows-shell/windows-spikes), which fails at the same pre-existing, cross-branch-reproducible flaky assertion documented on closed #398 (see that PR's investigation comment for the full root-cause trail: reproduced on two unrelated sibling PRs, architecturally identical invoke mechanism to the passing path, and unaffected by two rounds of genuine GDI-caching hardening).

Job	Result
validate	✅ pass
DCO sign-off	✅ pass
Linux build	✅ pass
macos	✅ pass
Deterministic hardening (2022 & 2025)	✅ pass
windows-shell (live UIA gate)	❌ fail — pre-existing flakiness, see below
windows-spikes	❌ fail — same root cause as windows-shell

Reran windows-shell/windows-spikes twice more on this PR's final commit; both reruns fail at the identical project-row New Loop did not open the node form assertion, consistent with the deterministic-but-pre-existing pattern already documented.

This PR (#401) supersedes #398, which GitHub auto-closed after a diagnostic force-push briefly made its head match main; GitHub then refused the standard reopen APIs ("state cannot be changed. There are no new commits"), so a fresh PR was opened from the same branch instead. This PR's branch has since been rebased onto current main (which had advanced by two merged PRs, #399 and #400, since this work started) with the ledger conflict manually resolved to keep both trains' updates.