diff options
| -rwxr-xr-x | install.sh | 26 | ||||
| -rw-r--r-- | templates/waybar/README.md | 19 |
2 files changed, 34 insertions, 11 deletions
@@ -48,18 +48,30 @@ ln -sfn "$repo/bin/udt-palette" "$HOME/bin/udt-palette" # with settings that are none of this repo's business. scheme="$(sed -n 's/^scheme *= *//p' "$selector")" -# waybar. The bar is waybar-theme-udt, which keeps its own config directory and -# imports styles/theme.css under a fixed name, so this is a copy to one path -# with no import to repoint: switching scheme rewrites the file the running bar -# already reads. +# waybar. The bar is waybar-theme-udt, a sibling checkout with its own +# install.sh, and that script is called here rather than having this one copy +# the stylesheet into place. +# +# The reason is that the palette reaches the bar as THREE generated files, not +# one: styles/theme.css, dots.colors for the two dot scripts, which are bash +# and cannot read @define-color, and two tints of the Slackware mark, which +# has to contrast with the accent pill at rest and the dark pill on hover. +# Copying only the stylesheet left the dots and the mark on the previous +# scheme's colours after a switch, and a second writer for those files here +# would drift from the one over there. +# +# Called with the palette already generated, and never fatal: a failure in the +# bar's install must not stop kitty, Kvantum or Sublime from being themed. The +# same reasoning as udt-appthemes below. # # The stock ~/.config/waybar/ is deliberately left alone. Nothing launches it # any more, and its stylesheets still reference the per-module role names this # generator no longer emits, so writing a new theme in there would leave it # referencing colours that do not exist rather than simply sitting unused. -if [ -d "$HOME/.config/waybar-udt" ]; then - install -Dm644 "$repo/templates/waybar/theme.css" \ - "$HOME/.config/waybar-udt/styles/theme.css" +waybar_repo="$repo/../waybar-theme-udt" +if [ -x "$waybar_repo/install.sh" ]; then + UDT_PALETTE_DONE=1 "$waybar_repo/install.sh" >/dev/null || \ + echo "waybar: its install.sh failed, bar left on the old colours" >&2 fi install -Dm644 "$repo/templates/terminal/kitty-theme.conf" \ diff --git a/templates/waybar/README.md b/templates/waybar/README.md index 19c220c..a69f228 100644 --- a/templates/waybar/README.md +++ b/templates/waybar/README.md @@ -4,10 +4,21 @@ The bar is [waybar-theme-udt](../../../waybar-theme-udt), which lives in its own repository and its own config directory, `~/.config/waybar-udt/`. This project supplies only its colours. -`theme.css` is generated here and copied there by `install.sh`, under a fixed -name that the bar's stylesheet imports, so switching scheme rewrites the file -the running bar already reads. There is no import to repoint and no per-scheme -filename. +`theme.css` is generated here, but `install.sh` does not copy it there itself: +it calls the bar's own `install.sh`, with `UDT_PALETTE_DONE=1` so that script +skips regenerating the palette it has just been handed. + +That is because the palette reaches the bar as **three** generated files, not +one: `styles/theme.css`, `dots.colors` for the two dot scripts, which are bash +and cannot read `@define-color`, and two tints of the Slackware mark, which +has to contrast with the accent pill at rest and the dark pill on hover. +Copying only the stylesheet recoloured every pill and left the dots and the +mark on the previous scheme's colours. Generating them here instead would mean +two writers for the same files, drifting apart the moment either is edited. + +The call is never fatal: a failure in the bar's install warns and leaves the +bar on its old colours rather than stopping kitty, Kvantum and Sublime from +being themed. Same reasoning as `udt-appthemes`. ## What the bar asks for |