Skip to content

Windows: a light appearance for the notch, and a Theme row in Settings - #320

Merged
vinzdg merged 1 commit into
vinzdg:mainfrom
RawJat:feat/windows-appearance-theme
Sep 23, 2026
Merged

vinzdg merged 1 commit into
vinzdg:mainfrom
RawJat:feat/windows-appearance-theme

Conversation

@RawJat

@RawJat RawJat commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

The notch page was written in a single appearance: about forty colours spelled out where they are used, all dark. This collects them into one palette, unchanged, writes a light set beside it, and adds a Theme row to Settings — System, Light, Dark, defaulting to System.

How the pages know which appearance they are in

Rust resolves it, Windows' own setting included, and answers get_theme_resolved; the pages put that on the document as data-theme and the palettes key off it. Not prefers-color-scheme: correcting a live window with set_theme does not reliably reach WebView2's own scheme, which left Settings with Mica gone light and the page still dark — near-white ink on a light panel, unreadable. Telling the page outright also means a theme changed while a window is open repaints it.

Settings and the drop zones are given it before their first frame through an initialization script, so neither can paint the other appearance first; the notch is created hidden and asks on load. While System is chosen, the watch that already follows the taskbar follows the appearance too. Settings' Mica is asked for MicaLight or MicaDark so it stays on the same side as the page above it, and its accent — Accent Light 2 against Accent Dark 1 — follows the same attribute.

The light values are the Mac's where the Mac has them: #6b6b6b for secondary ink, the usage bands' own light values #00A356 and #B08800 (critical stays #FF3F00, which Palette notes is already 3.5:1 on white), and the ring and bar tracks as alphas over what is behind them rather than fixed greys. The rest — a white card, an #f5f5f7 pill — takes the inks settings.html already used. The drop zones follow EdgeDropZones: the wash stays black in both appearances and only the dashed outline flips.

Arcs and dots are drawn into SVG, where var() does not reach, so the page reads those colours back out of the palette and redraws on a change rather than writing them down twice.

Strings: the row's seven strings are English only. They are new, so no catalog has them, and I would rather a native speaker wrote them than I guessed — ru, zh, zh-Hant, ja, ko, uk and pt are all missing them.

Tests

  • cargo test (132, including a new one pinning both palettes to the same set of names — a name missing from light silently keeps its dark value, and nothing in the build reads the page)
  • cargo clippy --all-targets (6 warnings, all pre-existing), node scripts/check-ui-scripts.mjs, the auth, Korean and Codex node tests
  • Live: each of System, Light and Dark, with Windows set both ways, on all four edges, plus a carry by the handle

The notch page was written in one appearance: about forty colours spelled
out where they were used, all dark. They become a palette, unchanged, with
a light set beside it, and Settings gets a Theme row — System, Light,
Dark, defaulting to System.

Which appearance is on is Rust's answer to get_theme_resolved, put on the
document as data-theme, and not prefers-color-scheme. Correcting a live
window with set_theme does not reliably reach WebView2's own scheme: it
left Settings with Mica gone light and the page still dark, near-white ink
on a light panel. Telling the page plainly also means a theme changed
while a window is open repaints it. The two windows we build — Settings
and the drop zones — are given it before their first frame through an
initialization script, so neither paints the other appearance first, and
the notch, which is created hidden, asks on load. While System is chosen,
the watch that follows the taskbar follows Windows' appearance too.

The light values are the Mac's where the Mac has them: #6b6b6b for
secondary ink (Palette.textSecondary), the usage bands' own light values
(#00A356 and #B08800, with critical unchanged at #FF3F00, which its
comment calls already 3.5:1 on white), and the ring and bar tracks as
alphas over what is behind them rather than fixed greys. The rest — a
white card, an #f5f5f7 pill — takes the inks settings.html already used.

Arcs and dots are drawn into SVG and inline styles, where var() does not
reach, so the page reads those colours back out of the palette and redraws
when the appearance changes rather than writing them down twice.

The drop zones follow EdgeDropZones: the wash stays black in both
appearances, .3 and .62 for the one being aimed at, and only the dashed
outline flips with the ink.

Settings' accent follows the same attribute. It read the system scheme to
choose between Accent Light 2 and Accent Dark 1, so a forced Light on a
dark Windows took the accent belonging to the other one.

A test pins both palettes to the same set of names: one declared in dark
and missing from light silently keeps its dark value, and nothing in the
build reads the page.

The row's strings are English only.
@RawJat
RawJat requested a review from vinzdg as a code owner September 22, 2026 17:56
@vinzdg
vinzdg merged commit 9bf678b into vinzdg:main Sep 23, 2026
4 checks passed
vinzdg added a commit that referenced this pull request Sep 23, 2026
…heme row

Two gaps the merges left:

- Adding Amp rewrote the English of SettingsView.setupCopy, and that string *is*
  the catalog key, so its ten translations were orphaned — the fourth time this
  has happened as providers were added, and there are now four dead variants of
  that paragraph in the catalog. The only change was inserting ", Amp" after
  Kiro, so the six translations of the immediately preceding variant are carried
  onto the new key with Amp inserted at the same point, using each language's
  own list separator.
- #320 shipped Theme / System / Light / Dark and their three captions in English
  only. Now in all seven Windows locale tables.
@RawJat
RawJat deleted the feat/windows-appearance-theme branch September 23, 2026 06:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants