fix(desktop): sync Electron's nativeTheme with the in-app theme preference by GabrielDrapor · Pull Request #493 · apache/maka

GabrielDrapor · 2026-07-04T02:46:40Z

Summary

Reported bug: switching the in-app theme from dark back to light left the left session-list sidebar stuck dark, while the rest of the UI repainted correctly to light.

Theme switching (apps/desktop/src/renderer/theme.ts) only ever toggles a .dark class on <html> -- a pure renderer/DOM operation with zero IPC to the main process.
On macOS the sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native vibrancy: 'sidebar' material (set once at window creation in main-window.ts). That material's light/dark tint is controlled by Electron's own nativeTheme.themeSource, which stays on its default ('system') forever -- nothing ever updated it.
So when the OS appearance disagrees with the chosen in-app theme (OS is Dark, user picks Light in-app), the opaque main content repaints correctly (it uses CSS vars that flip with .dark), but the vibrancy-backed sidebar keeps showing the system theme's tint, since that's a native/OS-level material, not something CSS variables can reach.

Fix

Added a window:setThemeSource IPC round-trip:

main-window.ts: new setThemeSource method on MainWindowController, sets nativeTheme.themeSource.
main.ts: registers the window:setThemeSource IPC handler.
preload.ts / global.d.ts: exposes window.maka.appWindow.setThemeSource(...).
theme.ts: applyTheme() now calls this alongside the existing .dark class toggle, mapping the app's 'auto'|'light'|'dark' preference to Electron's 'system'|'light'|'dark' themeSource.

This keeps the vibrancy material (and any other Electron-native chrome) in sync with the in-app theme choice, instead of silently following the OS setting forever.

Test plan

npm --workspace @maka/desktop run typecheck
Full desktop test suite: 1821/1821 passing
Manually verified: launched with OS in Dark mode, switched in-app theme to Light -- sidebar now repaints to light along with the rest of the UI

Note

A related fix for duplicate app instances (adding app.requestSingleInstanceLock()) was developed alongside this one but is intentionally not included here -- it'll land in a separate follow-up PR.

Co-Authored-By: Claude noreply@anthropic.com

…rence Switching the in-app theme (Settings → Appearance) only ever flipped the `.dark` class on <html> in the renderer -- a pure DOM/CSS operation with no IPC to the main process. On macOS the session-list sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native `vibrancy: 'sidebar'` material, and that material's light/dark tint is controlled by Electron's own `nativeTheme.themeSource`, which stays on its default ('system') forever since nothing ever touched it. Result: if the OS appearance disagrees with the chosen in-app theme (e.g. OS is Dark, user picks Light), the opaque main content repaints correctly but the vibrancy-backed sidebar keeps showing the *system* theme's tint. Added a `window:setThemeSource` IPC round-trip (main-window.ts, main.ts, preload.ts, global.d.ts) so `theme.ts`'s `applyTheme()` also calls `nativeTheme.themeSource = ...` in the main process whenever the preference changes, keeping the vibrancy material -- and any other Electron-native chrome -- in sync with the app's own theme choice. Verified: typecheck clean, full desktop suite (1821/1821) passing.

likun666661 · 2026-07-04T03:58:16Z

LGTM

Astro-Han · 2026-07-04T05:22:37Z

Hi! No blocking issues from me.

Non-blocking suggestions only:

P2 non-blocking: the startup first frame still has a small gap. createWindow() reads themePref before new BrowserWindow, and the sidebar uses macOS vibrancy. Right now nativeTheme.themeSource is only synced later, after the renderer reaches applyTheme() and sends the IPC call. On macOS, with the OS in dark mode and the app preference set to light, the sidebar can still flash dark on cold start.
I would set nativeTheme.themeSource = themePref === 'auto' ? 'system' : themePref right after reading themePref and before creating the BrowserWindow. The runtime IPC path can still handle later theme changes.
P2 non-blocking: this bridge could use a small regression test. The useful contract seems to be: auto/light/dark map to system/light/dark; the main handler accepts valid values, rejects invalid values, and rejects senders that are not the main window.
P3 non-blocking: the public window.maka.appWindow.setThemeSource bridge spreads theme ownership across renderer, preload, main-window, and settings/localStorage. A tiny helper like toNativeThemeSource(pref) would make the main-process side easier to keep correct, especially for startup and command-palette paths.
P3 non-blocking: the long explanation about DOM .dark vs Electron nativeTheme appears on both sides of the bridge. I would trim it to one short comment, or let the helper name carry most of it.

Suggested checks: the focused tests plus typecheck. I do not think this needs a slow E2E.

Addresses non-blocking review feedback on apache#493 (Astro-Han): - P2: createWindow() now syncs nativeTheme.themeSource from the resolved themePref before constructing the BrowserWindow, not only via the renderer's later setThemeSource() IPC call. Previously, on a cold start where the OS appearance disagreed with the persisted in-app preference, the vibrancy-backed sidebar could flash the *system* theme's tint for the first frame or two before the renderer reached applyTheme() and sent the IPC call. - P3: extracted the pref->themeSource mapping and validation into a new apps/desktop/src/main/theme-source.ts (toNativeThemeSource, isThemePreference) -- a single conversion point shared by both the createWindow() startup sync and the setThemeSource() IPC handler, so the two call sites can't drift. The IPC contract itself changed to carry the raw ThemePreference ('auto'|'light'|'dark') instead of a pre-mapped Electron value; the renderer no longer does its own 'auto' -> 'system' mapping (preload.ts / global.d.ts updated to match). - P3: trimmed the duplicated DOM-`.dark`-vs-native-chrome explanation down to one full copy (on toNativeThemeSource's docstring) with a one-line pointer from theme.ts, instead of a paragraph repeated on both sides of the bridge. - P2: added theme-source.test.ts -- direct unit tests for the pure mapping/validation functions (toNativeThemeSource, isThemePreference, including rejecting the old pre-mapped 'system' value now that the contract carries ThemePreference), plus source-contract checks that setThemeSource validates the sender + preference and that the createWindow sync runs before `new BrowserWindow(`. Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Live IPC round-trip check confirms setThemeSource resolves cleanly for all three valid preferences and silently rejects an invalid one (no main-process error). Screenshot capture confirms the app still builds and renders correctly end to end.

GabrielDrapor · 2026-07-04T10:53:37Z

Thanks @Astro-Han — addressed all four.

P2 (cold-start flash): createWindow() now syncs nativeTheme.themeSource from the resolved themePref right after it's computed, before new BrowserWindow(...) — not only via the later setThemeSource() IPC call. Added a source-contract test asserting the sync happens before the BrowserWindow construction.

P3 (helper): extracted toNativeThemeSource(pref) + isThemePreference(value) into a new theme-source.ts — the one conversion point shared by the startup sync and the IPC handler. As part of this the IPC contract itself changed to carry the raw ThemePreference instead of a pre-mapped value, so the renderer no longer does its own 'auto' → 'system' mapping (preload.ts/global.d.ts updated to match).

P3 (duplicated comment): now lives once, on toNativeThemeSource's docstring; theme.ts just points at it.

P2 (test): added theme-source.test.ts — direct unit tests for the pure mapping/validation (including rejecting the old pre-mapped 'system' value, since the contract changed), plus the source-contract checks mentioned above for setThemeSource's sender/value validation.

Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Also did a live IPC round-trip check confirming setThemeSource resolves cleanly for auto/light/dark and silently rejects garbage input with no main-process error.

Astro-Han · 2026-07-04T11:38:17Z

LGTM, thanks for addressing the review feedback.

GabrielDrapor · 2026-07-04T02:46:40Z

Summary

Reported bug: switching the in-app theme from dark back to light left the left session-list sidebar stuck dark, while the rest of the UI repainted correctly to light.

Theme switching (apps/desktop/src/renderer/theme.ts) only ever toggles a .dark class on <html> -- a pure renderer/DOM operation with zero IPC to the main process.
On macOS the sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native vibrancy: 'sidebar' material (set once at window creation in main-window.ts). That material's light/dark tint is controlled by Electron's own nativeTheme.themeSource, which stays on its default ('system') forever -- nothing ever updated it.
So when the OS appearance disagrees with the chosen in-app theme (OS is Dark, user picks Light in-app), the opaque main content repaints correctly (it uses CSS vars that flip with .dark), but the vibrancy-backed sidebar keeps showing the system theme's tint, since that's a native/OS-level material, not something CSS variables can reach.

Fix

Added a window:setThemeSource IPC round-trip:

main-window.ts: new setThemeSource method on MainWindowController, sets nativeTheme.themeSource.
main.ts: registers the window:setThemeSource IPC handler.
preload.ts / global.d.ts: exposes window.maka.appWindow.setThemeSource(...).
theme.ts: applyTheme() now calls this alongside the existing .dark class toggle, mapping the app's 'auto'|'light'|'dark' preference to Electron's 'system'|'light'|'dark' themeSource.

This keeps the vibrancy material (and any other Electron-native chrome) in sync with the in-app theme choice, instead of silently following the OS setting forever.

Test plan

npm --workspace @maka/desktop run typecheck
Full desktop test suite: 1821/1821 passing
Manually verified: launched with OS in Dark mode, switched in-app theme to Light -- sidebar now repaints to light along with the rest of the UI

Note

A related fix for duplicate app instances (adding app.requestSingleInstanceLock()) was developed alongside this one but is intentionally not included here -- it'll land in a separate follow-up PR.

Co-Authored-By: Claude noreply@anthropic.com

…rence Switching the in-app theme (Settings → Appearance) only ever flipped the `.dark` class on <html> in the renderer -- a pure DOM/CSS operation with no IPC to the main process. On macOS the session-list sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native `vibrancy: 'sidebar'` material, and that material's light/dark tint is controlled by Electron's own `nativeTheme.themeSource`, which stays on its default ('system') forever since nothing ever touched it. Result: if the OS appearance disagrees with the chosen in-app theme (e.g. OS is Dark, user picks Light), the opaque main content repaints correctly but the vibrancy-backed sidebar keeps showing the *system* theme's tint. Added a `window:setThemeSource` IPC round-trip (main-window.ts, main.ts, preload.ts, global.d.ts) so `theme.ts`'s `applyTheme()` also calls `nativeTheme.themeSource = ...` in the main process whenever the preference changes, keeping the vibrancy material -- and any other Electron-native chrome -- in sync with the app's own theme choice. Verified: typecheck clean, full desktop suite (1821/1821) passing.

likun666661 · 2026-07-04T03:58:16Z

LGTM

Astro-Han · 2026-07-04T05:22:37Z

Hi! No blocking issues from me.

Non-blocking suggestions only:

P2 non-blocking: the startup first frame still has a small gap. createWindow() reads themePref before new BrowserWindow, and the sidebar uses macOS vibrancy. Right now nativeTheme.themeSource is only synced later, after the renderer reaches applyTheme() and sends the IPC call. On macOS, with the OS in dark mode and the app preference set to light, the sidebar can still flash dark on cold start.
I would set nativeTheme.themeSource = themePref === 'auto' ? 'system' : themePref right after reading themePref and before creating the BrowserWindow. The runtime IPC path can still handle later theme changes.
P2 non-blocking: this bridge could use a small regression test. The useful contract seems to be: auto/light/dark map to system/light/dark; the main handler accepts valid values, rejects invalid values, and rejects senders that are not the main window.
P3 non-blocking: the public window.maka.appWindow.setThemeSource bridge spreads theme ownership across renderer, preload, main-window, and settings/localStorage. A tiny helper like toNativeThemeSource(pref) would make the main-process side easier to keep correct, especially for startup and command-palette paths.
P3 non-blocking: the long explanation about DOM .dark vs Electron nativeTheme appears on both sides of the bridge. I would trim it to one short comment, or let the helper name carry most of it.

Suggested checks: the focused tests plus typecheck. I do not think this needs a slow E2E.

Addresses non-blocking review feedback on apache#493 (Astro-Han): - P2: createWindow() now syncs nativeTheme.themeSource from the resolved themePref before constructing the BrowserWindow, not only via the renderer's later setThemeSource() IPC call. Previously, on a cold start where the OS appearance disagreed with the persisted in-app preference, the vibrancy-backed sidebar could flash the *system* theme's tint for the first frame or two before the renderer reached applyTheme() and sent the IPC call. - P3: extracted the pref->themeSource mapping and validation into a new apps/desktop/src/main/theme-source.ts (toNativeThemeSource, isThemePreference) -- a single conversion point shared by both the createWindow() startup sync and the setThemeSource() IPC handler, so the two call sites can't drift. The IPC contract itself changed to carry the raw ThemePreference ('auto'|'light'|'dark') instead of a pre-mapped Electron value; the renderer no longer does its own 'auto' -> 'system' mapping (preload.ts / global.d.ts updated to match). - P3: trimmed the duplicated DOM-`.dark`-vs-native-chrome explanation down to one full copy (on toNativeThemeSource's docstring) with a one-line pointer from theme.ts, instead of a paragraph repeated on both sides of the bridge. - P2: added theme-source.test.ts -- direct unit tests for the pure mapping/validation functions (toNativeThemeSource, isThemePreference, including rejecting the old pre-mapped 'system' value now that the contract carries ThemePreference), plus source-contract checks that setThemeSource validates the sender + preference and that the createWindow sync runs before `new BrowserWindow(`. Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Live IPC round-trip check confirms setThemeSource resolves cleanly for all three valid preferences and silently rejects an invalid one (no main-process error). Screenshot capture confirms the app still builds and renders correctly end to end.

GabrielDrapor · 2026-07-04T10:53:37Z

Thanks @Astro-Han — addressed all four.

P2 (cold-start flash): createWindow() now syncs nativeTheme.themeSource from the resolved themePref right after it's computed, before new BrowserWindow(...) — not only via the later setThemeSource() IPC call. Added a source-contract test asserting the sync happens before the BrowserWindow construction.

P3 (helper): extracted toNativeThemeSource(pref) + isThemePreference(value) into a new theme-source.ts — the one conversion point shared by the startup sync and the IPC handler. As part of this the IPC contract itself changed to carry the raw ThemePreference instead of a pre-mapped value, so the renderer no longer does its own 'auto' → 'system' mapping (preload.ts/global.d.ts updated to match).

P3 (duplicated comment): now lives once, on toNativeThemeSource's docstring; theme.ts just points at it.

P2 (test): added theme-source.test.ts — direct unit tests for the pure mapping/validation (including rejecting the old pre-mapped 'system' value, since the contract changed), plus the source-contract checks mentioned above for setThemeSource's sender/value validation.

Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Also did a live IPC round-trip check confirming setThemeSource resolves cleanly for auto/light/dark and silently rejects garbage input with no main-process error.

Astro-Han · 2026-07-04T11:38:17Z

LGTM, thanks for addressing the review feedback.

GabrielDrapor · 2026-07-04T02:46:40Z

Summary

Reported bug: switching the in-app theme from dark back to light left the left session-list sidebar stuck dark, while the rest of the UI repainted correctly to light.

Theme switching (apps/desktop/src/renderer/theme.ts) only ever toggles a .dark class on <html> -- a pure renderer/DOM operation with zero IPC to the main process.
On macOS the sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native vibrancy: 'sidebar' material (set once at window creation in main-window.ts). That material's light/dark tint is controlled by Electron's own nativeTheme.themeSource, which stays on its default ('system') forever -- nothing ever updated it.
So when the OS appearance disagrees with the chosen in-app theme (OS is Dark, user picks Light in-app), the opaque main content repaints correctly (it uses CSS vars that flip with .dark), but the vibrancy-backed sidebar keeps showing the system theme's tint, since that's a native/OS-level material, not something CSS variables can reach.

Fix

Added a window:setThemeSource IPC round-trip:

main-window.ts: new setThemeSource method on MainWindowController, sets nativeTheme.themeSource.
main.ts: registers the window:setThemeSource IPC handler.
preload.ts / global.d.ts: exposes window.maka.appWindow.setThemeSource(...).
theme.ts: applyTheme() now calls this alongside the existing .dark class toggle, mapping the app's 'auto'|'light'|'dark' preference to Electron's 'system'|'light'|'dark' themeSource.

This keeps the vibrancy material (and any other Electron-native chrome) in sync with the in-app theme choice, instead of silently following the OS setting forever.

Test plan

npm --workspace @maka/desktop run typecheck
Full desktop test suite: 1821/1821 passing
Manually verified: launched with OS in Dark mode, switched in-app theme to Light -- sidebar now repaints to light along with the rest of the UI

Note

A related fix for duplicate app instances (adding app.requestSingleInstanceLock()) was developed alongside this one but is intentionally not included here -- it'll land in a separate follow-up PR.

Co-Authored-By: Claude noreply@anthropic.com

…rence Switching the in-app theme (Settings → Appearance) only ever flipped the `.dark` class on <html> in the renderer -- a pure DOM/CSS operation with no IPC to the main process. On macOS the session-list sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native `vibrancy: 'sidebar'` material, and that material's light/dark tint is controlled by Electron's own `nativeTheme.themeSource`, which stays on its default ('system') forever since nothing ever touched it. Result: if the OS appearance disagrees with the chosen in-app theme (e.g. OS is Dark, user picks Light), the opaque main content repaints correctly but the vibrancy-backed sidebar keeps showing the *system* theme's tint. Added a `window:setThemeSource` IPC round-trip (main-window.ts, main.ts, preload.ts, global.d.ts) so `theme.ts`'s `applyTheme()` also calls `nativeTheme.themeSource = ...` in the main process whenever the preference changes, keeping the vibrancy material -- and any other Electron-native chrome -- in sync with the app's own theme choice. Verified: typecheck clean, full desktop suite (1821/1821) passing.

likun666661 · 2026-07-04T03:58:16Z

LGTM

Astro-Han · 2026-07-04T05:22:37Z

Hi! No blocking issues from me.

Non-blocking suggestions only:

P2 non-blocking: the startup first frame still has a small gap. createWindow() reads themePref before new BrowserWindow, and the sidebar uses macOS vibrancy. Right now nativeTheme.themeSource is only synced later, after the renderer reaches applyTheme() and sends the IPC call. On macOS, with the OS in dark mode and the app preference set to light, the sidebar can still flash dark on cold start.
I would set nativeTheme.themeSource = themePref === 'auto' ? 'system' : themePref right after reading themePref and before creating the BrowserWindow. The runtime IPC path can still handle later theme changes.
P2 non-blocking: this bridge could use a small regression test. The useful contract seems to be: auto/light/dark map to system/light/dark; the main handler accepts valid values, rejects invalid values, and rejects senders that are not the main window.
P3 non-blocking: the public window.maka.appWindow.setThemeSource bridge spreads theme ownership across renderer, preload, main-window, and settings/localStorage. A tiny helper like toNativeThemeSource(pref) would make the main-process side easier to keep correct, especially for startup and command-palette paths.
P3 non-blocking: the long explanation about DOM .dark vs Electron nativeTheme appears on both sides of the bridge. I would trim it to one short comment, or let the helper name carry most of it.

Suggested checks: the focused tests plus typecheck. I do not think this needs a slow E2E.

Addresses non-blocking review feedback on apache#493 (Astro-Han): - P2: createWindow() now syncs nativeTheme.themeSource from the resolved themePref before constructing the BrowserWindow, not only via the renderer's later setThemeSource() IPC call. Previously, on a cold start where the OS appearance disagreed with the persisted in-app preference, the vibrancy-backed sidebar could flash the *system* theme's tint for the first frame or two before the renderer reached applyTheme() and sent the IPC call. - P3: extracted the pref->themeSource mapping and validation into a new apps/desktop/src/main/theme-source.ts (toNativeThemeSource, isThemePreference) -- a single conversion point shared by both the createWindow() startup sync and the setThemeSource() IPC handler, so the two call sites can't drift. The IPC contract itself changed to carry the raw ThemePreference ('auto'|'light'|'dark') instead of a pre-mapped Electron value; the renderer no longer does its own 'auto' -> 'system' mapping (preload.ts / global.d.ts updated to match). - P3: trimmed the duplicated DOM-`.dark`-vs-native-chrome explanation down to one full copy (on toNativeThemeSource's docstring) with a one-line pointer from theme.ts, instead of a paragraph repeated on both sides of the bridge. - P2: added theme-source.test.ts -- direct unit tests for the pure mapping/validation functions (toNativeThemeSource, isThemePreference, including rejecting the old pre-mapped 'system' value now that the contract carries ThemePreference), plus source-contract checks that setThemeSource validates the sender + preference and that the createWindow sync runs before `new BrowserWindow(`. Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Live IPC round-trip check confirms setThemeSource resolves cleanly for all three valid preferences and silently rejects an invalid one (no main-process error). Screenshot capture confirms the app still builds and renders correctly end to end.

GabrielDrapor · 2026-07-04T10:53:37Z

Thanks @Astro-Han — addressed all four.

P2 (cold-start flash): createWindow() now syncs nativeTheme.themeSource from the resolved themePref right after it's computed, before new BrowserWindow(...) — not only via the later setThemeSource() IPC call. Added a source-contract test asserting the sync happens before the BrowserWindow construction.

P3 (helper): extracted toNativeThemeSource(pref) + isThemePreference(value) into a new theme-source.ts — the one conversion point shared by the startup sync and the IPC handler. As part of this the IPC contract itself changed to carry the raw ThemePreference instead of a pre-mapped value, so the renderer no longer does its own 'auto' → 'system' mapping (preload.ts/global.d.ts updated to match).

P3 (duplicated comment): now lives once, on toNativeThemeSource's docstring; theme.ts just points at it.

P2 (test): added theme-source.test.ts — direct unit tests for the pure mapping/validation (including rejecting the old pre-mapped 'system' value, since the contract changed), plus the source-contract checks mentioned above for setThemeSource's sender/value validation.

Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Also did a live IPC round-trip check confirming setThemeSource resolves cleanly for auto/light/dark and silently rejects garbage input with no main-process error.

Astro-Han · 2026-07-04T11:38:17Z

LGTM, thanks for addressing the review feedback.

GabrielDrapor · 2026-07-04T02:46:40Z

Summary

Reported bug: switching the in-app theme from dark back to light left the left session-list sidebar stuck dark, while the rest of the UI repainted correctly to light.

Theme switching (apps/desktop/src/renderer/theme.ts) only ever toggles a .dark class on <html> -- a pure renderer/DOM operation with zero IPC to the main process.
On macOS the sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native vibrancy: 'sidebar' material (set once at window creation in main-window.ts). That material's light/dark tint is controlled by Electron's own nativeTheme.themeSource, which stays on its default ('system') forever -- nothing ever updated it.
So when the OS appearance disagrees with the chosen in-app theme (OS is Dark, user picks Light in-app), the opaque main content repaints correctly (it uses CSS vars that flip with .dark), but the vibrancy-backed sidebar keeps showing the system theme's tint, since that's a native/OS-level material, not something CSS variables can reach.

Fix

Added a window:setThemeSource IPC round-trip:

main-window.ts: new setThemeSource method on MainWindowController, sets nativeTheme.themeSource.
main.ts: registers the window:setThemeSource IPC handler.
preload.ts / global.d.ts: exposes window.maka.appWindow.setThemeSource(...).
theme.ts: applyTheme() now calls this alongside the existing .dark class toggle, mapping the app's 'auto'|'light'|'dark' preference to Electron's 'system'|'light'|'dark' themeSource.

This keeps the vibrancy material (and any other Electron-native chrome) in sync with the in-app theme choice, instead of silently following the OS setting forever.

Test plan

npm --workspace @maka/desktop run typecheck
Full desktop test suite: 1821/1821 passing
Manually verified: launched with OS in Dark mode, switched in-app theme to Light -- sidebar now repaints to light along with the rest of the UI

Note

A related fix for duplicate app instances (adding app.requestSingleInstanceLock()) was developed alongside this one but is intentionally not included here -- it'll land in a separate follow-up PR.

Co-Authored-By: Claude noreply@anthropic.com

…rence Switching the in-app theme (Settings → Appearance) only ever flipped the `.dark` class on <html> in the renderer -- a pure DOM/CSS operation with no IPC to the main process. On macOS the session-list sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native `vibrancy: 'sidebar'` material, and that material's light/dark tint is controlled by Electron's own `nativeTheme.themeSource`, which stays on its default ('system') forever since nothing ever touched it. Result: if the OS appearance disagrees with the chosen in-app theme (e.g. OS is Dark, user picks Light), the opaque main content repaints correctly but the vibrancy-backed sidebar keeps showing the *system* theme's tint. Added a `window:setThemeSource` IPC round-trip (main-window.ts, main.ts, preload.ts, global.d.ts) so `theme.ts`'s `applyTheme()` also calls `nativeTheme.themeSource = ...` in the main process whenever the preference changes, keeping the vibrancy material -- and any other Electron-native chrome -- in sync with the app's own theme choice. Verified: typecheck clean, full desktop suite (1821/1821) passing.

likun666661 · 2026-07-04T03:58:16Z

LGTM

Astro-Han · 2026-07-04T05:22:37Z

Hi! No blocking issues from me.

Non-blocking suggestions only:

P2 non-blocking: the startup first frame still has a small gap. createWindow() reads themePref before new BrowserWindow, and the sidebar uses macOS vibrancy. Right now nativeTheme.themeSource is only synced later, after the renderer reaches applyTheme() and sends the IPC call. On macOS, with the OS in dark mode and the app preference set to light, the sidebar can still flash dark on cold start.
I would set nativeTheme.themeSource = themePref === 'auto' ? 'system' : themePref right after reading themePref and before creating the BrowserWindow. The runtime IPC path can still handle later theme changes.
P2 non-blocking: this bridge could use a small regression test. The useful contract seems to be: auto/light/dark map to system/light/dark; the main handler accepts valid values, rejects invalid values, and rejects senders that are not the main window.
P3 non-blocking: the public window.maka.appWindow.setThemeSource bridge spreads theme ownership across renderer, preload, main-window, and settings/localStorage. A tiny helper like toNativeThemeSource(pref) would make the main-process side easier to keep correct, especially for startup and command-palette paths.
P3 non-blocking: the long explanation about DOM .dark vs Electron nativeTheme appears on both sides of the bridge. I would trim it to one short comment, or let the helper name carry most of it.

Suggested checks: the focused tests plus typecheck. I do not think this needs a slow E2E.

Addresses non-blocking review feedback on apache#493 (Astro-Han): - P2: createWindow() now syncs nativeTheme.themeSource from the resolved themePref before constructing the BrowserWindow, not only via the renderer's later setThemeSource() IPC call. Previously, on a cold start where the OS appearance disagreed with the persisted in-app preference, the vibrancy-backed sidebar could flash the *system* theme's tint for the first frame or two before the renderer reached applyTheme() and sent the IPC call. - P3: extracted the pref->themeSource mapping and validation into a new apps/desktop/src/main/theme-source.ts (toNativeThemeSource, isThemePreference) -- a single conversion point shared by both the createWindow() startup sync and the setThemeSource() IPC handler, so the two call sites can't drift. The IPC contract itself changed to carry the raw ThemePreference ('auto'|'light'|'dark') instead of a pre-mapped Electron value; the renderer no longer does its own 'auto' -> 'system' mapping (preload.ts / global.d.ts updated to match). - P3: trimmed the duplicated DOM-`.dark`-vs-native-chrome explanation down to one full copy (on toNativeThemeSource's docstring) with a one-line pointer from theme.ts, instead of a paragraph repeated on both sides of the bridge. - P2: added theme-source.test.ts -- direct unit tests for the pure mapping/validation functions (toNativeThemeSource, isThemePreference, including rejecting the old pre-mapped 'system' value now that the contract carries ThemePreference), plus source-contract checks that setThemeSource validates the sender + preference and that the createWindow sync runs before `new BrowserWindow(`. Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Live IPC round-trip check confirms setThemeSource resolves cleanly for all three valid preferences and silently rejects an invalid one (no main-process error). Screenshot capture confirms the app still builds and renders correctly end to end.

GabrielDrapor · 2026-07-04T10:53:37Z

Thanks @Astro-Han — addressed all four.

P2 (cold-start flash): createWindow() now syncs nativeTheme.themeSource from the resolved themePref right after it's computed, before new BrowserWindow(...) — not only via the later setThemeSource() IPC call. Added a source-contract test asserting the sync happens before the BrowserWindow construction.

P3 (helper): extracted toNativeThemeSource(pref) + isThemePreference(value) into a new theme-source.ts — the one conversion point shared by the startup sync and the IPC handler. As part of this the IPC contract itself changed to carry the raw ThemePreference instead of a pre-mapped value, so the renderer no longer does its own 'auto' → 'system' mapping (preload.ts/global.d.ts updated to match).

P3 (duplicated comment): now lives once, on toNativeThemeSource's docstring; theme.ts just points at it.

P2 (test): added theme-source.test.ts — direct unit tests for the pure mapping/validation (including rejecting the old pre-mapped 'system' value, since the contract changed), plus the source-contract checks mentioned above for setThemeSource's sender/value validation.

Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Also did a live IPC round-trip check confirming setThemeSource resolves cleanly for auto/light/dark and silently rejects garbage input with no main-process error.

Astro-Han · 2026-07-04T11:38:17Z

LGTM, thanks for addressing the review feedback.

GabrielDrapor · 2026-07-04T02:46:40Z

Summary

Reported bug: switching the in-app theme from dark back to light left the left session-list sidebar stuck dark, while the rest of the UI repainted correctly to light.

Theme switching (apps/desktop/src/renderer/theme.ts) only ever toggles a .dark class on <html> -- a pure renderer/DOM operation with zero IPC to the main process.
On macOS the sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native vibrancy: 'sidebar' material (set once at window creation in main-window.ts). That material's light/dark tint is controlled by Electron's own nativeTheme.themeSource, which stays on its default ('system') forever -- nothing ever updated it.
So when the OS appearance disagrees with the chosen in-app theme (OS is Dark, user picks Light in-app), the opaque main content repaints correctly (it uses CSS vars that flip with .dark), but the vibrancy-backed sidebar keeps showing the system theme's tint, since that's a native/OS-level material, not something CSS variables can reach.

Fix

Added a window:setThemeSource IPC round-trip:

main-window.ts: new setThemeSource method on MainWindowController, sets nativeTheme.themeSource.
main.ts: registers the window:setThemeSource IPC handler.
preload.ts / global.d.ts: exposes window.maka.appWindow.setThemeSource(...).
theme.ts: applyTheme() now calls this alongside the existing .dark class toggle, mapping the app's 'auto'|'light'|'dark' preference to Electron's 'system'|'light'|'dark' themeSource.

This keeps the vibrancy material (and any other Electron-native chrome) in sync with the in-app theme choice, instead of silently following the OS setting forever.

Test plan

npm --workspace @maka/desktop run typecheck
Full desktop test suite: 1821/1821 passing
Manually verified: launched with OS in Dark mode, switched in-app theme to Light -- sidebar now repaints to light along with the rest of the UI

Note

A related fix for duplicate app instances (adding app.requestSingleInstanceLock()) was developed alongside this one but is intentionally not included here -- it'll land in a separate follow-up PR.

Co-Authored-By: Claude noreply@anthropic.com

…rence Switching the in-app theme (Settings → Appearance) only ever flipped the `.dark` class on <html> in the renderer -- a pure DOM/CSS operation with no IPC to the main process. On macOS the session-list sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native `vibrancy: 'sidebar'` material, and that material's light/dark tint is controlled by Electron's own `nativeTheme.themeSource`, which stays on its default ('system') forever since nothing ever touched it. Result: if the OS appearance disagrees with the chosen in-app theme (e.g. OS is Dark, user picks Light), the opaque main content repaints correctly but the vibrancy-backed sidebar keeps showing the *system* theme's tint. Added a `window:setThemeSource` IPC round-trip (main-window.ts, main.ts, preload.ts, global.d.ts) so `theme.ts`'s `applyTheme()` also calls `nativeTheme.themeSource = ...` in the main process whenever the preference changes, keeping the vibrancy material -- and any other Electron-native chrome -- in sync with the app's own theme choice. Verified: typecheck clean, full desktop suite (1821/1821) passing.

likun666661 · 2026-07-04T03:58:16Z

LGTM

Astro-Han · 2026-07-04T05:22:37Z

Hi! No blocking issues from me.

Non-blocking suggestions only:

P2 non-blocking: the startup first frame still has a small gap. createWindow() reads themePref before new BrowserWindow, and the sidebar uses macOS vibrancy. Right now nativeTheme.themeSource is only synced later, after the renderer reaches applyTheme() and sends the IPC call. On macOS, with the OS in dark mode and the app preference set to light, the sidebar can still flash dark on cold start.
I would set nativeTheme.themeSource = themePref === 'auto' ? 'system' : themePref right after reading themePref and before creating the BrowserWindow. The runtime IPC path can still handle later theme changes.
P2 non-blocking: this bridge could use a small regression test. The useful contract seems to be: auto/light/dark map to system/light/dark; the main handler accepts valid values, rejects invalid values, and rejects senders that are not the main window.
P3 non-blocking: the public window.maka.appWindow.setThemeSource bridge spreads theme ownership across renderer, preload, main-window, and settings/localStorage. A tiny helper like toNativeThemeSource(pref) would make the main-process side easier to keep correct, especially for startup and command-palette paths.
P3 non-blocking: the long explanation about DOM .dark vs Electron nativeTheme appears on both sides of the bridge. I would trim it to one short comment, or let the helper name carry most of it.

Suggested checks: the focused tests plus typecheck. I do not think this needs a slow E2E.

Addresses non-blocking review feedback on apache#493 (Astro-Han): - P2: createWindow() now syncs nativeTheme.themeSource from the resolved themePref before constructing the BrowserWindow, not only via the renderer's later setThemeSource() IPC call. Previously, on a cold start where the OS appearance disagreed with the persisted in-app preference, the vibrancy-backed sidebar could flash the *system* theme's tint for the first frame or two before the renderer reached applyTheme() and sent the IPC call. - P3: extracted the pref->themeSource mapping and validation into a new apps/desktop/src/main/theme-source.ts (toNativeThemeSource, isThemePreference) -- a single conversion point shared by both the createWindow() startup sync and the setThemeSource() IPC handler, so the two call sites can't drift. The IPC contract itself changed to carry the raw ThemePreference ('auto'|'light'|'dark') instead of a pre-mapped Electron value; the renderer no longer does its own 'auto' -> 'system' mapping (preload.ts / global.d.ts updated to match). - P3: trimmed the duplicated DOM-`.dark`-vs-native-chrome explanation down to one full copy (on toNativeThemeSource's docstring) with a one-line pointer from theme.ts, instead of a paragraph repeated on both sides of the bridge. - P2: added theme-source.test.ts -- direct unit tests for the pure mapping/validation functions (toNativeThemeSource, isThemePreference, including rejecting the old pre-mapped 'system' value now that the contract carries ThemePreference), plus source-contract checks that setThemeSource validates the sender + preference and that the createWindow sync runs before `new BrowserWindow(`. Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Live IPC round-trip check confirms setThemeSource resolves cleanly for all three valid preferences and silently rejects an invalid one (no main-process error). Screenshot capture confirms the app still builds and renders correctly end to end.

GabrielDrapor · 2026-07-04T10:53:37Z

Thanks @Astro-Han — addressed all four.

P2 (cold-start flash): createWindow() now syncs nativeTheme.themeSource from the resolved themePref right after it's computed, before new BrowserWindow(...) — not only via the later setThemeSource() IPC call. Added a source-contract test asserting the sync happens before the BrowserWindow construction.

P3 (helper): extracted toNativeThemeSource(pref) + isThemePreference(value) into a new theme-source.ts — the one conversion point shared by the startup sync and the IPC handler. As part of this the IPC contract itself changed to carry the raw ThemePreference instead of a pre-mapped value, so the renderer no longer does its own 'auto' → 'system' mapping (preload.ts/global.d.ts updated to match).

P3 (duplicated comment): now lives once, on toNativeThemeSource's docstring; theme.ts just points at it.

P2 (test): added theme-source.test.ts — direct unit tests for the pure mapping/validation (including rejecting the old pre-mapped 'system' value, since the contract changed), plus the source-contract checks mentioned above for setThemeSource's sender/value validation.

Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Also did a live IPC round-trip check confirming setThemeSource resolves cleanly for auto/light/dark and silently rejects garbage input with no main-process error.

Astro-Han · 2026-07-04T11:38:17Z

LGTM, thanks for addressing the review feedback.

GabrielDrapor · 2026-07-04T02:46:40Z

Summary

Reported bug: switching the in-app theme from dark back to light left the left session-list sidebar stuck dark, while the rest of the UI repainted correctly to light.

Theme switching (apps/desktop/src/renderer/theme.ts) only ever toggles a .dark class on <html> -- a pure renderer/DOM operation with zero IPC to the main process.
On macOS the sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native vibrancy: 'sidebar' material (set once at window creation in main-window.ts). That material's light/dark tint is controlled by Electron's own nativeTheme.themeSource, which stays on its default ('system') forever -- nothing ever updated it.
So when the OS appearance disagrees with the chosen in-app theme (OS is Dark, user picks Light in-app), the opaque main content repaints correctly (it uses CSS vars that flip with .dark), but the vibrancy-backed sidebar keeps showing the system theme's tint, since that's a native/OS-level material, not something CSS variables can reach.

Fix

Added a window:setThemeSource IPC round-trip:

main-window.ts: new setThemeSource method on MainWindowController, sets nativeTheme.themeSource.
main.ts: registers the window:setThemeSource IPC handler.
preload.ts / global.d.ts: exposes window.maka.appWindow.setThemeSource(...).
theme.ts: applyTheme() now calls this alongside the existing .dark class toggle, mapping the app's 'auto'|'light'|'dark' preference to Electron's 'system'|'light'|'dark' themeSource.

This keeps the vibrancy material (and any other Electron-native chrome) in sync with the in-app theme choice, instead of silently following the OS setting forever.

Test plan

npm --workspace @maka/desktop run typecheck
Full desktop test suite: 1821/1821 passing
Manually verified: launched with OS in Dark mode, switched in-app theme to Light -- sidebar now repaints to light along with the rest of the UI

Note

A related fix for duplicate app instances (adding app.requestSingleInstanceLock()) was developed alongside this one but is intentionally not included here -- it'll land in a separate follow-up PR.

Co-Authored-By: Claude noreply@anthropic.com

…rence Switching the in-app theme (Settings → Appearance) only ever flipped the `.dark` class on <html> in the renderer -- a pure DOM/CSS operation with no IPC to the main process. On macOS the session-list sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native `vibrancy: 'sidebar'` material, and that material's light/dark tint is controlled by Electron's own `nativeTheme.themeSource`, which stays on its default ('system') forever since nothing ever touched it. Result: if the OS appearance disagrees with the chosen in-app theme (e.g. OS is Dark, user picks Light), the opaque main content repaints correctly but the vibrancy-backed sidebar keeps showing the *system* theme's tint. Added a `window:setThemeSource` IPC round-trip (main-window.ts, main.ts, preload.ts, global.d.ts) so `theme.ts`'s `applyTheme()` also calls `nativeTheme.themeSource = ...` in the main process whenever the preference changes, keeping the vibrancy material -- and any other Electron-native chrome -- in sync with the app's own theme choice. Verified: typecheck clean, full desktop suite (1821/1821) passing.

likun666661 · 2026-07-04T03:58:16Z

LGTM

Astro-Han · 2026-07-04T05:22:37Z

Hi! No blocking issues from me.

Non-blocking suggestions only:

P2 non-blocking: the startup first frame still has a small gap. createWindow() reads themePref before new BrowserWindow, and the sidebar uses macOS vibrancy. Right now nativeTheme.themeSource is only synced later, after the renderer reaches applyTheme() and sends the IPC call. On macOS, with the OS in dark mode and the app preference set to light, the sidebar can still flash dark on cold start.
I would set nativeTheme.themeSource = themePref === 'auto' ? 'system' : themePref right after reading themePref and before creating the BrowserWindow. The runtime IPC path can still handle later theme changes.
P2 non-blocking: this bridge could use a small regression test. The useful contract seems to be: auto/light/dark map to system/light/dark; the main handler accepts valid values, rejects invalid values, and rejects senders that are not the main window.
P3 non-blocking: the public window.maka.appWindow.setThemeSource bridge spreads theme ownership across renderer, preload, main-window, and settings/localStorage. A tiny helper like toNativeThemeSource(pref) would make the main-process side easier to keep correct, especially for startup and command-palette paths.
P3 non-blocking: the long explanation about DOM .dark vs Electron nativeTheme appears on both sides of the bridge. I would trim it to one short comment, or let the helper name carry most of it.

Suggested checks: the focused tests plus typecheck. I do not think this needs a slow E2E.

Addresses non-blocking review feedback on apache#493 (Astro-Han): - P2: createWindow() now syncs nativeTheme.themeSource from the resolved themePref before constructing the BrowserWindow, not only via the renderer's later setThemeSource() IPC call. Previously, on a cold start where the OS appearance disagreed with the persisted in-app preference, the vibrancy-backed sidebar could flash the *system* theme's tint for the first frame or two before the renderer reached applyTheme() and sent the IPC call. - P3: extracted the pref->themeSource mapping and validation into a new apps/desktop/src/main/theme-source.ts (toNativeThemeSource, isThemePreference) -- a single conversion point shared by both the createWindow() startup sync and the setThemeSource() IPC handler, so the two call sites can't drift. The IPC contract itself changed to carry the raw ThemePreference ('auto'|'light'|'dark') instead of a pre-mapped Electron value; the renderer no longer does its own 'auto' -> 'system' mapping (preload.ts / global.d.ts updated to match). - P3: trimmed the duplicated DOM-`.dark`-vs-native-chrome explanation down to one full copy (on toNativeThemeSource's docstring) with a one-line pointer from theme.ts, instead of a paragraph repeated on both sides of the bridge. - P2: added theme-source.test.ts -- direct unit tests for the pure mapping/validation functions (toNativeThemeSource, isThemePreference, including rejecting the old pre-mapped 'system' value now that the contract carries ThemePreference), plus source-contract checks that setThemeSource validates the sender + preference and that the createWindow sync runs before `new BrowserWindow(`. Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Live IPC round-trip check confirms setThemeSource resolves cleanly for all three valid preferences and silently rejects an invalid one (no main-process error). Screenshot capture confirms the app still builds and renders correctly end to end.

GabrielDrapor · 2026-07-04T10:53:37Z

Thanks @Astro-Han — addressed all four.

P2 (cold-start flash): createWindow() now syncs nativeTheme.themeSource from the resolved themePref right after it's computed, before new BrowserWindow(...) — not only via the later setThemeSource() IPC call. Added a source-contract test asserting the sync happens before the BrowserWindow construction.

P3 (helper): extracted toNativeThemeSource(pref) + isThemePreference(value) into a new theme-source.ts — the one conversion point shared by the startup sync and the IPC handler. As part of this the IPC contract itself changed to carry the raw ThemePreference instead of a pre-mapped value, so the renderer no longer does its own 'auto' → 'system' mapping (preload.ts/global.d.ts updated to match).

P3 (duplicated comment): now lives once, on toNativeThemeSource's docstring; theme.ts just points at it.

P2 (test): added theme-source.test.ts — direct unit tests for the pure mapping/validation (including rejecting the old pre-mapped 'system' value, since the contract changed), plus the source-contract checks mentioned above for setThemeSource's sender/value validation.

Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Also did a live IPC round-trip check confirming setThemeSource resolves cleanly for auto/light/dark and silently rejects garbage input with no main-process error.

Astro-Han · 2026-07-04T11:38:17Z

LGTM, thanks for addressing the review feedback.

GabrielDrapor · 2026-07-04T02:46:40Z

Summary

Reported bug: switching the in-app theme from dark back to light left the left session-list sidebar stuck dark, while the rest of the UI repainted correctly to light.

Theme switching (apps/desktop/src/renderer/theme.ts) only ever toggles a .dark class on <html> -- a pure renderer/DOM operation with zero IPC to the main process.
On macOS the sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native vibrancy: 'sidebar' material (set once at window creation in main-window.ts). That material's light/dark tint is controlled by Electron's own nativeTheme.themeSource, which stays on its default ('system') forever -- nothing ever updated it.
So when the OS appearance disagrees with the chosen in-app theme (OS is Dark, user picks Light in-app), the opaque main content repaints correctly (it uses CSS vars that flip with .dark), but the vibrancy-backed sidebar keeps showing the system theme's tint, since that's a native/OS-level material, not something CSS variables can reach.

Fix

Added a window:setThemeSource IPC round-trip:

main-window.ts: new setThemeSource method on MainWindowController, sets nativeTheme.themeSource.
main.ts: registers the window:setThemeSource IPC handler.
preload.ts / global.d.ts: exposes window.maka.appWindow.setThemeSource(...).
theme.ts: applyTheme() now calls this alongside the existing .dark class toggle, mapping the app's 'auto'|'light'|'dark' preference to Electron's 'system'|'light'|'dark' themeSource.

This keeps the vibrancy material (and any other Electron-native chrome) in sync with the in-app theme choice, instead of silently following the OS setting forever.

Test plan

npm --workspace @maka/desktop run typecheck
Full desktop test suite: 1821/1821 passing
Manually verified: launched with OS in Dark mode, switched in-app theme to Light -- sidebar now repaints to light along with the rest of the UI

Note

A related fix for duplicate app instances (adding app.requestSingleInstanceLock()) was developed alongside this one but is intentionally not included here -- it'll land in a separate follow-up PR.

Co-Authored-By: Claude noreply@anthropic.com

…rence Switching the in-app theme (Settings → Appearance) only ever flipped the `.dark` class on <html> in the renderer -- a pure DOM/CSS operation with no IPC to the main process. On macOS the session-list sidebar is deliberately transparent (theme-glass.css) so it can show through the window's native `vibrancy: 'sidebar'` material, and that material's light/dark tint is controlled by Electron's own `nativeTheme.themeSource`, which stays on its default ('system') forever since nothing ever touched it. Result: if the OS appearance disagrees with the chosen in-app theme (e.g. OS is Dark, user picks Light), the opaque main content repaints correctly but the vibrancy-backed sidebar keeps showing the *system* theme's tint. Added a `window:setThemeSource` IPC round-trip (main-window.ts, main.ts, preload.ts, global.d.ts) so `theme.ts`'s `applyTheme()` also calls `nativeTheme.themeSource = ...` in the main process whenever the preference changes, keeping the vibrancy material -- and any other Electron-native chrome -- in sync with the app's own theme choice. Verified: typecheck clean, full desktop suite (1821/1821) passing.

likun666661 · 2026-07-04T03:58:16Z

LGTM

Astro-Han · 2026-07-04T05:22:37Z

Hi! No blocking issues from me.

Non-blocking suggestions only:

P2 non-blocking: the startup first frame still has a small gap. createWindow() reads themePref before new BrowserWindow, and the sidebar uses macOS vibrancy. Right now nativeTheme.themeSource is only synced later, after the renderer reaches applyTheme() and sends the IPC call. On macOS, with the OS in dark mode and the app preference set to light, the sidebar can still flash dark on cold start.
I would set nativeTheme.themeSource = themePref === 'auto' ? 'system' : themePref right after reading themePref and before creating the BrowserWindow. The runtime IPC path can still handle later theme changes.
P2 non-blocking: this bridge could use a small regression test. The useful contract seems to be: auto/light/dark map to system/light/dark; the main handler accepts valid values, rejects invalid values, and rejects senders that are not the main window.
P3 non-blocking: the public window.maka.appWindow.setThemeSource bridge spreads theme ownership across renderer, preload, main-window, and settings/localStorage. A tiny helper like toNativeThemeSource(pref) would make the main-process side easier to keep correct, especially for startup and command-palette paths.
P3 non-blocking: the long explanation about DOM .dark vs Electron nativeTheme appears on both sides of the bridge. I would trim it to one short comment, or let the helper name carry most of it.

Suggested checks: the focused tests plus typecheck. I do not think this needs a slow E2E.

Addresses non-blocking review feedback on apache#493 (Astro-Han): - P2: createWindow() now syncs nativeTheme.themeSource from the resolved themePref before constructing the BrowserWindow, not only via the renderer's later setThemeSource() IPC call. Previously, on a cold start where the OS appearance disagreed with the persisted in-app preference, the vibrancy-backed sidebar could flash the *system* theme's tint for the first frame or two before the renderer reached applyTheme() and sent the IPC call. - P3: extracted the pref->themeSource mapping and validation into a new apps/desktop/src/main/theme-source.ts (toNativeThemeSource, isThemePreference) -- a single conversion point shared by both the createWindow() startup sync and the setThemeSource() IPC handler, so the two call sites can't drift. The IPC contract itself changed to carry the raw ThemePreference ('auto'|'light'|'dark') instead of a pre-mapped Electron value; the renderer no longer does its own 'auto' -> 'system' mapping (preload.ts / global.d.ts updated to match). - P3: trimmed the duplicated DOM-`.dark`-vs-native-chrome explanation down to one full copy (on toNativeThemeSource's docstring) with a one-line pointer from theme.ts, instead of a paragraph repeated on both sides of the bridge. - P2: added theme-source.test.ts -- direct unit tests for the pure mapping/validation functions (toNativeThemeSource, isThemePreference, including rejecting the old pre-mapped 'system' value now that the contract carries ThemePreference), plus source-contract checks that setThemeSource validates the sender + preference and that the createWindow sync runs before `new BrowserWindow(`. Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Live IPC round-trip check confirms setThemeSource resolves cleanly for all three valid preferences and silently rejects an invalid one (no main-process error). Screenshot capture confirms the app still builds and renders correctly end to end.

GabrielDrapor · 2026-07-04T10:53:37Z

Thanks @Astro-Han — addressed all four.

P2 (cold-start flash): createWindow() now syncs nativeTheme.themeSource from the resolved themePref right after it's computed, before new BrowserWindow(...) — not only via the later setThemeSource() IPC call. Added a source-contract test asserting the sync happens before the BrowserWindow construction.

P3 (helper): extracted toNativeThemeSource(pref) + isThemePreference(value) into a new theme-source.ts — the one conversion point shared by the startup sync and the IPC handler. As part of this the IPC contract itself changed to carry the raw ThemePreference instead of a pre-mapped value, so the renderer no longer does its own 'auto' → 'system' mapping (preload.ts/global.d.ts updated to match).

P3 (duplicated comment): now lives once, on toNativeThemeSource's docstring; theme.ts just points at it.

P2 (test): added theme-source.test.ts — direct unit tests for the pure mapping/validation (including rejecting the old pre-mapped 'system' value, since the contract changed), plus the source-contract checks mentioned above for setThemeSource's sender/value validation.

Verified: typecheck clean, full desktop suite (1828/1828, +7 new). Also did a live IPC round-trip check confirming setThemeSource resolves cleanly for auto/light/dark and silently rejects garbage input with no main-process error.

Astro-Han · 2026-07-04T11:38:17Z

LGTM, thanks for addressing the review feedback.

likun666661 approved these changes Jul 4, 2026
View reviewed changes

Astro-Han merged commit a153d31 into apache:mainJul 4, 2026

GabrielDrapor deleted the fix/nativetheme-sync-sidebar-vibrancy branch July 6, 2026 09:54

Astro-Han mentioned this pull request Jul 7, 2026
fix(desktop): reveal main window only after first React commit #599
Merged