mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-26 17:38:36 +00:00
afd0270a64
Live theme authoring's core loop — Hermes recolors the skin file it just activated — repainted the TUI but not the GUI. The event path was fine (post-#69533 the WS broadcast lands and ingestBackendSkin refreshes the $backendThemes registry); the same-name apply guard also no-ops correctly (it's what protects a manual desktop theme pick). The repaint was supposed to come from the registry: the active theme IS that skin, its palette just changed. But ThemeProvider memoized deriveTheme on [themeName, resolvedMode] only, while deriveTheme reads the registry non-reactively via resolveTheme — so the store update re-rendered the provider and handed back the stale palette. Name switches repainted (themeName moves); recolors never did. Add the theme stores (user/backend/registry) to the memo's deps — they are deriveTheme's actual reactivity, same as the availableThemes memo directly above. applyTheme is idempotent, and $backendThemes only publishes on a real palette change, so no spurious repaints. Tests: render ThemeProvider for real — activation applies; a same-name recolor repaints (fails without the fix); an inactive-skin seed doesn't touch the painted theme. |
||
|---|---|---|
| .. | ||
| backend-sync.test.ts | ||
| backend-sync.ts | ||
| color.ts | ||
| context.test.tsx | ||
| context.tsx | ||
| index.ts | ||
| install.test.ts | ||
| install.ts | ||
| presets.test.ts | ||
| presets.ts | ||
| profile-theme.test.ts | ||
| skin.test.ts | ||
| skin.ts | ||
| types.ts | ||
| use-skin-command.ts | ||
| user-themes.test.ts | ||
| user-themes.ts | ||
| vscode.test.ts | ||
| vscode.ts | ||