mirror of
https://github.com/NanmiCoder/cc-haha
synced 2026-07-31 16:33:34 +08:00
5b891151ae
An Auto-dark-mode user reported being flashed by a white window every evening, then switching to a dark palette by hand. That is two defects, and only one of them is the missing feature. The flash fired even for someone who had already saved a dark palette. `index.html` hardcoded `data-theme="white"` while the code that reads the stored theme, `initializeTheme()`, only runs after the app bundle's dynamic imports resolve. So every launch painted white first. A synchronous inline script now resolves the theme before any stylesheet is parsed, and Electron seeds `backgroundColor` from a cached appearance so the window is not white before the renderer's first frame either. Following the system is a switch in Settings -> General rather than a seventh palette. The OS only reports dark/light while the app ships six palettes, so each ground carries its own preference: the picker splits into "use in light mode" (the four paper grounds) and "use in dark mode" (the two ink ones), and a pick lands in the preference for its own ground. Choosing ink-blue at noon is therefore remembered for that night rather than fighting the OS. Detection goes through `prefers-color-scheme` because the same renderer runs under Electron, the Tauri shell and the browser entry, and the media query is the only signal all three share. New installs follow the system; existing ones keep their fixed palette until they opt in, so an update never silently repaints someone's app. `nativeTheme.themeSource` is deliberately left alone, which is the part most likely to be "fixed" later. Pinning it to the user's palette would make context menus and the macOS frame agree with the app, but it is a process-wide override of `prefers-color-scheme` — the very signal this feature reads. Re-enabling the switch would then resolve against the pinned value instead of the real OS setting, and the override also leaks into the preview WebContentsView, forcing third-party pages to the app's theme. A test fails on any assignment to it. The OS-flip listener reads the preferences from storage rather than from its own store. The pet and trace windows run the same bootstrap with their own store instance over one shared localStorage, so after the main window turns the switch off their in-memory copy still says "on" — acting on it wrote the user's choice straight back out. A `storage` listener catches the other windows up. `settingsStore.theme` is gone. It was a copy that only refreshed on an explicit `setTheme`, so an OS flip left the Settings picker highlighting a palette that was no longer on screen. uiStore owns the theme; the copy had no remaining readers. The 「纸·墨·印」 rename reaches the new keys too: `light` -> `warm-classic` now migrates for the per-ground preferences, not just the applied theme, so the palette daytime returns to is not silently reset. Guards, each verified by breaking what it protects: the inline script is extracted from `index.html` and run verbatim against `resolveAppliedTheme` over every stored combination — including dirty values, which are reachable because it runs before the persistence migrations, and cross-ground values like a dark palette stored as the light preference; the three copies of the palette grounds (CSS `--cc-bg`, `index.html`, main process) are pinned to each other and to `THEME_MODES`, so a seventh palette cannot ship without a pre-paint color; the two grounds are proven to cover every palette at compile time; and the IPC payload is held to a literal 6-digit hex because `setBackgroundColor` also accepts `#AARRGGBB`, where a translucent window means click-through and overlay spoofing.