4341628b2fe09b9b9e64b2da349c33abd847540f
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Gabriel Brown
|
2d69ce7648 |
Make the lock screen follow the colour scheme
hyprlock.conf shipped with Tokyo Night Moon hardcoded in six places, so choosing light mode left the lock screen dark. Every other surface had been taught to follow the scheme this week -- kitty, GTK, the launcher, btop, tmux, neovim -- and this was the one left, which is unfortunate, because it is the screen a user sees most often and the worst possible place to find a theming bug: you discover it while locked out of the machine and cannot fix it from there. It is now generated from a template on every scheme change, the same shape kitty, GTK, tmux and btop already use, and seeded by link-dotfiles so the first lock of a fresh install is themed rather than falling back to hyprlock's bare grey default. hyprlock is launched fresh on each lock (`pidof hyprlock || hyprlock`), so it picks the file up with no restart. The dark output is byte-identical to the file it replaces, ignoring comments -- verified by diff -- so nothing changes for anyone already in dark mode. One detail worth recording: hyprlock takes rgba(r, g, b, a) in DECIMAL, not hex, so the template carries "R, G, B" triples where every other theme file in this repository uses hex. Two values are the exception, sitting inside Pango markup where hyprlock wants ##rrggbb. Getting either wrong is not a parse error -- hyprlock ignores the value and uses its own default, silently. Which is why this has a contract. It generates both schemes into a fixture, never the live config, and checks that no placeholder survives substitution, that every colour is a well-formed decimal triple, that the Pango values are well-formed hex, that a light lock screen is actually light, and that the two schemes differ at all. Verified it catches a hardcoded colour left in the template and a light mode built from the dark palette, which is the original bug exactly. Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L |
||
|
Gabriel Brown
|
27af4fd443 |
Carry the colour scheme into btop and tmux
Two more applications that keep their own palette and so never followed the desktop. btop was on "Default" and had never been themed at all; tmux had Tokyo Night Moon hardcoded across seventeen lines, which meant a dark status bar sitting under a light terminal in light mode. Both themes are authored rather than borrowed. btop ships a "tokyo-night" theme, but it is the Night variant (#1a1b26) where the rest of this desktop is Moon (#222436), and two Tokyo Nights side by side read as a mistake; it ships no Tokyo Night light theme at all. Colours come from kitty's theme files so a terminal and what runs inside it cannot disagree. tmux follows kitty's shape: the colours move to themes/, tmux.conf sources a generated current-theme.conf, and running servers are re-sourced so an open session changes immediately rather than at next launch. btop is different -- it OWNS btop.conf and rewrites it on exit, so only the color_theme line is edited in place and the file is not symlinked into the repository. btop reads its theme once at startup, so a running instance keeps the old colours; forcing a restart would kill a process the user is watching. The tmux light theme took two passes. Mapping the palette role-for-role put the standard Day accents on a mid-grey panel at 2.74:1 and 2.94:1 -- under the 3:1 floor, on a bar you read at a glance. It now uses Day's darker accent variants on a lighter panel: 4.42:1 and 4.17:1, and 5.01:1 / 4.73:1 for the light text inside the inverted blocks. The helper also now reports every target rather than only kitty. Saying "kitty: applied" while silently skipping three other applications is how a half-applied theme goes unnoticed. Not changed: bat is configured with --theme ansi, which follows the terminal's own palette, so it already tracks kitty with nothing to do. Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L |
||
|
Gabriel Brown
|
f0321432b4 |
Fix dark mode: the GTK theme it asked for does not exist
Reported symptom: Electron applications and a Chromium-based browser, all set to follow the system, went light when the desktop went light and never came back. Nothing reported an error, and the portal was serving the correct value the whole time. Cause: ColorScheme set gtk-theme to "Adwaita-dark" for dark and "Adwaita" for light. Neither is installed on Fedora 44 -- only adw-gtk3 and adw-gtk3-dark are. GTK responds to an unknown theme name by falling back to its built-in default, which is LIGHT. So asking for light worked by accident, asking for dark silently produced light, and anything that takes its cue from the GTK theme rather than the portal stayed light no matter what org.freedesktop.appearance said. Verified: the portal emits correctly in both directions, so this was never the portal's fault. Second cause, the mirror of the first: gtk-3.0/settings.ini and gtk-4.0/settings.ini were pinned to adw-gtk3-dark and prefer-dark=1 and never regenerated. Under GNOME that file is ignored because gnome-settings-daemon publishes over XSETTINGS; under Hyprland nothing does, so for GTK3 it is authoritative -- and it contradicted the scheme in light mode. They are now generated from a template on every switch, gitignored as machine state, and seeded by link-dotfiles, the same shape kitty's current-theme.conf already uses. These directories are symlinked into the repository, so writing the live file directly would dirty the working tree on every theme switch. The failure was silent by construction, so it gets a test rather than a comment: gtk-theme-contract asserts every theme name Panama sets is actually installed, and that the generated GTK config agrees with the scheme in both directions. Verified it catches both original bugs. Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L |
||
|
Gabriel Brown
|
19063a3e02 |
Carry the colour scheme into terminals and the editor
The scheme switch already reached everything that reads org.freedesktop.appearance -- GTK4, Qt6, Chromium, Electron -- because ColorScheme.qml writes the gsettings key those all watch. Applications carrying their own palettes did not follow, so choosing light mode left the two windows actually used all day, kitty and neovim, still dark. kitty: the 32 colours move out of kitty.conf into themes/, and kitty.conf ends with `include current-theme.conf`. The generated file is machine state rather than configuration, so it is gitignored and link-dotfiles seeds it on install -- otherwise a fresh checkout starts by complaining about a missing include. Running terminals are re-coloured in place over their control sockets; a restart is not needed. neovim: reads settings.json directly, since it neither watches the portal nor keeps a socket open. Tokyo Night ships Day in the same family as Moon, so light mode keeps the editor's identity instead of turning it into a different-looking application. The existing readability overrides were written against Moon and are now dark-only -- applied to Day they would have put light grey on a light background, the same problem they exist to fix, inverted. Light mode gets one override of its own: tokyonight's shipped comment colour measures 2.54:1 against Day's background, under the 3:1 floor for secondary text, so it is replaced with 3.25:1 -- readable, still dimmer than Normal's 4.52:1. An editor already open when the scheme flips re-applies on FocusGained, which is cheap and fires exactly when the mismatch would be noticed. Verified both directions: kitty re-coloured 4 live terminals, and neovim starts as tokyonight-day with background=light and tokyonight-moon with background=dark. Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L |