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>
