The watcher not landing left Zen with no theme at all. Keep the startup copy
so the floor is the old behaviour, and let the watcher fight for the live
update on top.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gecko has no userChrome.css reload, so wrap zen with a mozilla.cfg script
that registers chrome/zen-theme.css through nsIStyleSheetService and
re-registers it under a cache-busting URI when its mtime moves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
theme-apply sent reload-config to com.mitchellh.ghostty only, and its
comment claimed the scratchpad 'is the same process'. It is not — that
is the whole point of the --class in settings/hyprland.nix. Ghostty's
--class IS the GTK application id, which is how it forces a separate
instance, and a separate instance owns its own bus name and object path.
So the scratchpad never got the reload and kept the old palette until it
was killed.
Now both are told, scratchpad first and best-effort, since it only
exists once SUPER+Return has been pressed this session.
base03/base04/base05 were three independent slots off the wallpaper, not
one ink at three strengths. On wallhaven-k8dqr6 the raw ladder is red,
blue and cream; on 5y39p9 base03 is a saturated gold against pale cream.
That is why muted labels read as a second accent and why the shell frame
never quite matched the window border beside it.
base04 and base03 are now base05 mixed toward base00. The two factors and
the mix live in settings/ui.nix and are used by all three consumers:
Theme.qml, theming.nix's hypr.lua (applied at runtime) and hyprland.nix's
build-time fallback. Same trick base01/base02 already used for surfaces.
Verified on 5y39p9: hypr.lua now emits aca888 / 727761 from base05 f1e2b6
against base00 0a1f1c, matching what inkStep computes in the shell.
base16-fish and stylix's btop theme were only disabled on desktops, so a
login shell on Mediaserver printf'd OSC 4/10/11 back down the SSH pipe and
overwrote the client's wallpaper palette. Off everywhere, server TUIs draw
in the client's 16 ANSI colours instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neither gets per-wallpaper files. Both draw with the 16 ANSI colours, so
they follow ghostty's palette the moment theme-apply reloads it — no
restart and none of the reflow a GTK theme switch causes.
mc uses a -defbg skin (paints on the terminal's own background); yazi gets
an ANSI-named theme and stylix's hex-writing yazi target is disabled.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GTK3 parses ~/.config/gtk-3.0/gtk.css once per process behind a static
guard and never re-reads it, and it outranks the theme at PRIORITY_USER —
so colours there pin an app to whatever was live when it started. Install
a Fred-<wallpaper> theme instead and switch gtk-theme over gsettings,
which xdg-desktop-portal-gtk forwards to running apps.
One name per wallpaper because gtk_css_provider_get_named memoises
providers in a static hash table keyed by name.
GTK4/libadwaita ignores gtk-theme-name, so it keeps the user CSS and
still needs a restart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
vencord watches quickCss.css with fs.watch on the file and delivers one
event per vesktop run in practice, so only the first switch applied. Its
themes watcher is on the DIRECTORY, whose inode is never replaced, so it
keeps firing — write the same CSS there too. Enable "fredos" once under
Vencord -> Themes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
stylix ships fish as both a NixOS and a home-manager target. Only the HM
one was off, so /etc/fish/config.fish still sourced base16-fish and kept
printf'ing OSC 4/10/11 with build-time colours at every shell start.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fish's stylix target sources base16-fish, which printf's OSC 4 and OSC
10/11 with build-time colours at every shell start — it painted the old
scheme back over ghostty on every reload, and again in each new window.
hyprctl keyword is legacy-parser only and refuses under the lua config
("Use eval."); emit hl.config lua and hyprctl eval it instead.
theme-apply now logs to ~/.local/state/theme-apply.log: quickshell starts
it with execDetached, which drops stdio, so stderr went nowhere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drops the copy step for both: a switch is now just the ln -sfn, so there
is no second write to fail and no stale copy to survive. Verified with
ghostty +show-config that retargeting the link alone changes the
effective background/foreground. Also log the applied theme per run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
hyprctl --batch reported one combined result, so a rejected key took the
rest with it and errors were swallowed; each keyword now reports to the
journal. Ghostty's reload_config keybind never arrived via sendshortcut —
use its org.gtk.Actions reload-config action instead, which needs no
window. Add a gsettings theme toggle to nudge running GTK apps.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
settings/theming.nix renders a full config set per wallpaper (GTK, ghostty,
btop, hyprland, vesktop, zen, folder icons) from its own base16 palette;
theme-apply swaps them in and reloads what can reload.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
