Light theme: one palette owns every colour, and the title bar chooses which one (#200)

The light theme itself is the small part. The work was taking colour away from
the 1100 places that decided it by hand and giving it to one file.

**`UiThemePalette` is the only place a colour is built.** 139 roles named for the
job they do — `ControlSurface`, `TextSecondary`, `CurveExcessPhase`,
`MarkerFirstArrival`, `PlotZoomBoxStroke` — each answered by BOTH themes. The
properties are `required`, so a role cannot be added to one theme and forgotten
in the other, and `UiPalette` is the static face of whichever palette is in
force. Call sites, `.Designer.cs` included, read `UiPalette.<Role>`; plot code
converts with the new `.ToOxy()`.

What that swept up: 604 `Color.FromArgb` literals and 346 `Color.White` in 22
designer files, 148 `SystemColors.ControlLight` label foregrounds, ~290 OxyPlot
colours across 19 files, the band-strip tints, the fader cap gradients, the
meter, the trash cursor. `UiPaletteCoverageTests` now fails the build on a colour
built out of numbers or framework names anywhere under `source/`; its allow list
names the six files that keep theirs and why (the user's own curve colours, PDF
sheets on paper, OxyPlot's defaults compared against). It has already earned its
keep: it caught the three literals the Auto Crossover dialog brought in when
main was merged, which no eye was going to find in a 140-file branch.

**Near-duplicates collapsed into roles rather than being carried over twice.**
Twelve greys of text became a ladder of six; two button fills (50,55,80 and
46,51,67) and the dialog button grey became one `ButtonBackground`; nine greens
became `Success`; four ambers became `Warning`. The plot surfaces went from the
four TODO.md complained about to two: `GraphSurface` (main, wizard, Virtual DSP)
and `GraphSurfaceMuted` (the previews). The satellite plots — Time Alignment,
`AngleCalibrationDialog`, `ImpulseWindowPreview`, `OverlayTargetSettingsDialog`,
`MeasurementHistoryWindow` — no longer carry their own chrome: they go through
`PlotModelStyle.CreatePreviewModel` and `AddAxis`/`StyleAxis`, which is now the
single home of what a plot looks like.

**The twelve overlay slots got designed colours.** They came from `new Random(3)`,
and that colour becomes a curve colour the moment the slot is captured into.
Seeded, so deterministic, but nobody chose it: five of the twelve sit under 3:1
against the DARK plot as shipped — slot 12 reads 1.23:1, slot 6 1.56:1 — and on
white the bright green slot 4 falls to 1.47:1. They are `OverlaySlotDefaults` in
the palette now, twelve per theme, the weakest 4.26:1. The dark slot colours
therefore change; a slot that already holds a capture keeps the colour in its
file.

**The theme is chosen at startup.** A designer reads the palette inside
`InitializeComponent`, so `Program.Main` calls `UiPalette.Use` before the first
control exists; the gear button in the title bar opens Settings, and switching
the theme offers a restart. `Application.Restart` cannot do that here — the shell
cancels its first close to await the audio aborts, so the replacement would meet
a `SingleInstanceGuard` the old process still owns — so the request is recorded
and carried out after `Application.Run` returns and the guard is released. The
choice lives in its own `appearance.json`, written through `AtomicFile` so a
failed write leaves the previous theme rather than an empty file, and a failed
write does not offer a restart into a theme that was not saved.

The gear is drawn rather than typed: at 13 px the U+2699 glyph falls back to the
colour emoji font and reads as a flower. Candidates were rendered side by side —
the glyph with and without the text-presentation selector, in Segoe UI Symbol and
in Segoe MDL2 Assets, against a drawn one — and only the drawn one is legible at
that size. It takes the button's own ink, so it follows the theme.

`DarkComboBox`, `DarkNumericUpDown` and `DarkScrollBars` became `Themed*` — the
scrollbars now ask the OS for the light or dark native theme to match, with the
app-mode value chosen per Windows build (ordinal 135 is `AllowDarkModeForApp` on
1809 and `SetPreferredAppMode` from 1903, where ForceLight is 3, not 1).

Held to the same floors as the dark theme where it is honest to say so:
`UiPaletteContrastTests` runs its whole table against both palettes, plus every
`Curve*`/`Marker*` role, all twelve Virtual DSP channel colours and all twelve
overlay slot defaults against the plot surface. The dark analysis curves predate
that floor — the weakest, violet HD3 on deep blue, reads 1.58:1 — so dark is held
where it stands, REFERENCE.md says so instead of claiming parity, and the gap is
written down in TODO.md rather than quietly retuned.

Deliberately untouched: colours the user chose (captured overlay slots, Virtual
DSP channels in a saved session, the EQ Wizard target) stay exactly as they are
in their files. What follows the theme is the colour a slot or target STARTS in.
Tuning sheet PDFs are printed on paper and have no theme.

Verified beyond the test suite with a scratchpad render harness: every
constructible panel, dialog and control drawn to a bitmap and hashed before and
after the sweep, so the dark theme is provably unchanged except where a merge was
intended — the diffs are the merged values and nothing else. The same harness
drew both themes of the shell, the panels, the settings dialog and the title bar
for the visual passes.

One test-harness fix rides along. `FirConstructorTests` failed once on CI and
never locally, and the state it reported — design and kernel replaced,
`RebuildPending` already false, the button still disabled — has exactly one
cause: the panel publishes that flag one statement before `ApplyRendering`
re-enables the button, which is invisible while both run on the UI thread. It
stops being invisible when the continuation resumes on the thread pool, and
WinForms only installs a `WindowsFormsSynchronizationContext` while the
process-wide `AutoInstall` is on — which a test running beside it can turn off.
`StaTest.Run` installs the context itself now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: DIMOSUS

AGENTS.md

@@ -218,6 +218,16 @@ Enforced by `.editorconfig`; notable deviations from common C# defaults:
 - CRLF line endings, 4-space indent, Allman braces, braces always.
 - New non-UI code uses file-scoped namespaces (see `Program.cs`, `ModeController.cs`).
 - Keep static WinForms controls in `.Designer.cs`. For genuinely dynamic controls, use a designer-defined `TableLayoutPanel` or `FlowLayoutPanel`; avoid absolute 96-DPI coordinates because controls created after `InitializeComponent` miss designer autoscaling.
+- **Colour comes from the palette, by role.** `UiThemePalette` holds every colour the app paints, named for the
+  job it does (`ControlSurface`, `TextSecondary`, `CurveExcessPhase`), and answers it in BOTH themes — the
+  properties are `required`, so a new role cannot be added to one theme and forgotten in the other. Call sites,
+  including `.Designer.cs` files, read `UiPalette.<Role>`; plot code converts with `.ToOxy()`. Nothing anywhere
+  else builds a colour out of numbers or framework names, and `UiPaletteCoverageTests` fails the build if it
+  does (its allow list names the few exceptions and why: the user's own curve colours, PDF sheets on paper,
+  OxyPlot's defaults compared against). The theme is chosen once in `Program.Main` before the first control is
+  built, because a designer reads the palette inside `InitializeComponent`; changing it asks for a restart.
+  Plot chrome has one home, `PlotModelStyle` — `ApplyChrome`/`CreatePreviewModel` and `AddAxis`/`StyleAxis`;
+  do not set an axis colour by hand.
 - Buttons, checkboxes and radio buttons are `ReleaseClickButton` / `ReleaseClickCheckBox` / `ReleaseClickRadioButton`, never the WinForms types they derive from — in the designer as well as in code. WinForms puts a `WindowFromPoint` ownership check in its mouse-release click path — one of several conditions, alongside cancelled validation and `ButtonBase`'s own press/capture state — so any window overlapping that one pixel (a tooltip, above all — measured: 20 of 20 clicks lost) takes the click silently while the control still paints its press. `ReleaseClick*` works around that hit-test failure and only it, and does not decide anything itself: when the release point belongs to another window, the release is handed to the framework at another free point on the same control, so the framework still answers whether a click is due and every other condition it withholds one under keeps applying. A release outside the control, or a control covered edge to edge, is left exactly as it arrived. A menu is then opened through `DropDownMenu`, which posts the show clear of the mouse message and guards it against the focus change opening it causes.
 - Comments stay under roughly 10% of code lines; every line of them is read, and paid for, by each agent that opens the file. See **Comments** below.
 - Every WinForms container scales with `AutoScaleMode.Dpi` and `AutoScaleDimensions = (96, 96)` — do not go back to `AutoScaleMode.Font`. Font autoscaling is anisotropic: at 120 DPI it widens boxes by the average character width (7→8, ×1.14) while the glyphs themselves grow ×1.25, so labels, radios and buttons were clipped across the app at 125%. DPI scaling uses one uniform `DeviceDpi / 96` on both axes, which is the ratio the text grows by. Designer slack therefore scales with the text: leave a few pixels beside a label rather than sizing a box to its exact 96-DPI extent.

README.md

@@ -278,6 +278,8 @@ is set to show no animations (Settings → Accessibility → Visual effects).
 - **Signal Generator**, **Measurement History** with per-entry working state, a
   compact Mic/Loop level meter, and four audio backends (MME Compatibility, ASIO,
   WASAPI Shared and Exclusive) with backend-specific channel routing
+- **Dark and light themes** — the gear button in the title bar opens Settings;
+  the theme colours every panel, dialog, graph and curve
 
 ## Gallery
 

REFERENCE.md

@@ -11,6 +11,7 @@ read-out refuses rather than guesses, what a number was measured against.
 
 ## Contents
 
+- [Application Settings](#application-settings)
 - [Graph Zoom and Limits](#graph-zoom-and-limits)
 - [Mode Settings](#mode-settings)
 - [Phase and Group Delay](#phase-and-group-delay)
@@ -60,6 +61,36 @@ read-out refuses rather than guesses, what a number was measured against.
 
 ---
 
+## Application Settings
+
+The gear button in the title bar, beside minimize/maximize/close, opens the
+settings that belong to the whole application rather than to one mode (a mode
+keeps its own settings behind **Mode Settings...**).
+
+**Theme** — **Dark** (the default) or **Light**. The theme decides every colour
+the program paints: panels, dialogs, the plot surface, the axes and grid, the
+curves, the level meter and the faders. Text and panels are held to the same
+contrast floors in both themes. The light theme also holds every curve at the
+3:1 floor for a graphical object; a few of the dark analysis curves (the third
+and fourth harmonic above all) have sat under it since long before the light
+theme existed, and they are left as they are rather than retuned here.
+
+The theme is read once, when Resonalyze starts, because every control takes its
+colours as it is built. Changing it therefore offers a restart; decline it and
+the new theme simply appears the next time you open the program. The choice is
+stored in `appearance.json` next to the rest of your settings.
+
+Three things the theme deliberately does **not** touch:
+
+- **Colours you chose yourself** — a captured overlay slot's colour, a Virtual DSP
+  channel's colour in a saved session, the EQ Wizard target colour. They live in
+  your files and stay exactly as you set them. What does follow the theme is the
+  colour a slot or a target STARTS in: each of the twelve overlay slots has its
+  own, picked per theme and held apart from its neighbours, so a curve captured
+  in the light theme is born readable on white.
+- **Tuning sheets** — a PDF is printed on paper, which has no theme.
+- **The figures in this documentation**, which were taken in the dark theme.
+
 ## Graph Zoom and Limits
 
 The analysis plot, the Time Alignment previews, the EQ Wizard and the Virtual DSP

TODO.md

@@ -433,27 +433,6 @@ next field session rather than in a register nobody else can tick.
   would change appearance everywhere, not just while loading. Owner looked at a
   rendered comparison on 2026-08-24 and chose to leave it; take it as its own
   change with its own visual pass, not as a rider on something else.
-- [ ] **A light theme is wanted eventually, and 650 colour assignments do not go
-  through `UiPalette`** — 504 `Color.FromArgb` literals across the `.Designer.cs`
-  files plus 146 `SystemColors.ControlLight` label foregrounds.
-  The contrast work (#116) named the roles the app paints with — `AccentFill`,
-  `TextDisabled`, the `Graph*` chrome — and put the graph surface and the accent
-  buttons' fill under the palette, so the SEAMS now exist:
-  `PlotModelStyle.ApplyChrome` is the one place a plot's colours are decided,
-  and `UiPaletteContrastTests` re-measures whatever values a second theme
-  brings. What is left for the theme itself is the designer sweep, and it is
-  smaller than the count suggests: only **35 distinct values** appear in those
-  files and four of them cover 329 of the 504, so a dark→light map plus a
-  runtime pass over the control tree covers most of it. The judgment part is
-  not the chrome but the CURVES: `OxyColors.White` sums, white THD traces,
-  light-grey source curves and the user's own overlay slot colours (persisted
-  as `ColorArgb` in overlay files, so they cannot be rewritten) all need a
-  second palette or a luminance-adaptive fallback before a light plot is
-  readable. Do not start this as a colour swap; start it as a curve-palette
-  design. Half the palette also still carries PHYSICAL names (`AccentBlueSoft`,
-  `TextSecondaryAlt`, `SuccessGreenSoft`): rename them to their roles as they
-  are touched rather than in one sweep — `AccentBlueSoft` is the accent MARK
-  (links, focus borders, selection markers), which is the one that matters.
 - [ ] **Do not let the shell re-assign a docked panel's `Padding`.** Both tool
   panels declare `Padding = new Padding(6)` in their OWN designer, where it scales
   with the rest of the arrangement; `Form1.Designer.cs` used to set the same
@@ -466,31 +445,19 @@ next field session rather than in a register nobody else can tick.
   this defect returning. `ItsPadding_ScalesWithTheArrangement` in both layout
   suites pins the panel's own half of it; nothing can pin the shell's.
 
-- [ ] **The app paints plots on FOUR different surfaces, three of them designer
-  literals.** `UiPalette.GraphSurface` (50,55,100) covers the main plot and the
-  EQ wizard; Virtual DSP's two views sit on (40,44,80)
-  (`VirtualCrossoverPanel.Designer.cs`), the option/Time Alignment/history
-  previews on (32,36,46), and the target preview on (55,58,65). Whether that is
-  intentional or drift, nobody decided it recently — and it is not cosmetic:
-  a FIXED chrome colour reads at a different strength on each (the first grid
-  measured 1.33:1 on the main plots and 1.59:1 on Virtual DSP, which is how it
-  looked). The grid and the plot border are white-with-alpha now, so they no
-  longer care; anything else added to a plot has to make the same choice, and a
-  light theme has to reach all four surfaces. Decide the count first: one
-  surface token, or a named few.
-- [ ] **The satellite plots still carry their own chrome literals.** The Time
-  Alignment previews, `AngleCalibrationDialog`, `ImpulseWindowPreview`,
-  `OverlayTargetSettingsDialog` and `MeasurementHistoryWindow` set their own
-  white text and grid colours rather than going through
-  `PlotModelStyle.ApplyChrome`. They are readable as they are, so this is
-  tidiness, not a defect — but they are the reason a plot colour still has more
-  than one home.
-- [ ] **`WarningRed` on a dark surface measures 4.3:1 as text.** It is a FILL
-  today (meter bars, the fader groove), where no text threshold applies, so
-  nothing is wrong now — but it reads as the palette's "red" and the next
-  status line that reaches for it would land under the floor. `ErrorSoft`
-  (already lifted to 4.6:1) is the text-carrying red; keep them apart, or give
-  `WarningRed` a text-safe sibling if it is ever needed for one.
+- [ ] **Five dark curves sit under the 3:1 floor on the plot surface.** The
+  light theme is measured at 3:1 by `UiPaletteContrastTests`; the dark curve set
+  predates that floor and is held where the owner tuned it, so the same test
+  uses 1.55:1 there — only a regression guard. The weakest are `CurveHarmonic3`
+  (1.58), `CurveHarmonic4` (1.70), `CurveArrayMicrophone` (2.52), `CurveMuted`
+  (2.85) and `CurveLiveTransfer` (2.98) against `GraphSurface`. Lifting them is a
+  visual pass on the dark theme with the owner, not a rider on other work.
+- [ ] **`Danger` on a dark surface measures 4.3:1 as text.** It is a FILL today
+  (meter bars, the fader groove), where no text threshold applies, so nothing is
+  wrong now — but it reads as the palette's "red" and the next status line that
+  reaches for it would land under the floor. `Error` (4.6:1) is the
+  text-carrying red; keep them apart, or give `Danger` a text-safe sibling if it
+  is ever needed for one.
 - [ ] **`ChromeTitleBar` caches the DPI scale once at `Initialize`.** No
   `DpiChanged` handling: moving the window to a monitor with different DPI
   (PerMonitorV2) leaves the bar height, button widths and tab layout at the old

source/LiveSpectrum/LiveSpectrumController.cs

@@ -720,7 +720,7 @@ private void UpdateOverloadAnnotation(PlotModel model)
             TextFlowDirection = TextFlowDirection.TopDown,
             FontSize = 12,
             FontWeight = 700,
-            TextColor = OxyColor.FromRgb(255, 170, 0),
+            TextColor = UiPalette.Warning.ToOxy(),
             TextHorizontalAlignment = OxyPlot.HorizontalAlignment.Center
         });
     }
@@ -799,7 +799,7 @@ private void UpdateCaptureProgressAnnotation(PlotModel? model)
                 TextPosition = new DataPoint(0.01, 0),
                 TextFlowDirection = TextFlowDirection.TopDown,
                 FontSize = 12,
-                TextColor = OxyColor.FromRgb(150, 165, 190),
+                TextColor = UiPalette.TextSecondary.ToOxy(),
                 TextHorizontalAlignment = OxyPlot.HorizontalAlignment.Left
             };
             captureProgressOwner = model;
@@ -815,8 +815,8 @@ private void UpdateCaptureProgressAnnotation(PlotModel? model)
                 ? $"{state} — {seconds:0} s, {frames} frames, {clipped} clipped"
                 : $"{state} — {seconds:0} s, {frames} frames";
             captureProgressAnnotation.TextColor = clipped > 0
-                ? OxyColor.FromRgb(255, 190, 80)
-                : OxyColor.FromRgb(150, 165, 190);
+                ? UiPalette.Warning.ToOxy()
+                : UiPalette.TextSecondary.ToOxy();
         }
 
         model.Annotations.Add(captureProgressAnnotation);