Give the desktop real themes, video wallpapers, and honest titlebars

Appearance now opens on Themes: light and dark side by side, each
remembering its own choice, over galleries of ten shipped themes —
Tokyo Moon and Day joined by Moon Rose, Catppuccin, Nord, Gruvbox and
Everforest in both modes. A theme is a complete palette: the catalog
lives in themes.json, Theme.qml reads every color token from the
active record, and one render pipeline carries it to kitty, tmux,
btop, GTK, Vicinae, Firefox's chrome, and the lock screen. The Theme
editor builds new ones from four wells — wheel, hex, or eyedropper —
with derived surfaces, a saturation slider, debounced fine-tune, and
effects that save with the theme. Custom edits finally keep GNOME's
accent, kitty's border, and hyprlock in sync.

Wallpapers can be video: mpvpaper per output, hardware-decoded, muted
and looped, supervised and respawned. Panama owns the pausing — games,
battery, and a bar pill for right now — because the compositor
rebuilds full-screen blur for every frame a video wallpaper draws.
The lock screen gets a still frame.

Titlebars stop lying. GNOME apps get close-only on your chosen side,
the maximize and double-click settings are gone, the Settings window
obeys the same rules, and its titlebar can be turned off entirely.
Typography becomes five labeled dropdowns instead of a wall of
samples.

Contracts updated and written throughout (165 now); per the redesign
workflow none were executed — the full sweep runs once at the end.

Claude-Session: https://claude.ai/code/session_01Ms2FbjQy31TVf3CEvQhGM8

tests/quickshell/gtk-theme-contract

@@ -16,6 +16,14 @@
 # The failure is silent by construction, so it needs a test rather than a
 # comment. Checks the compositor-facing setting and the generated GTK config
 # agree, and that both name something real.
+#
+# It also covers the second half of GTK theming: settings.ini names a theme,
+# gtk.css overrides that theme's colours. Those colours used to be baked in --
+# #82aaff written out by hand, and the GTK4 "light" gtk.css a byte-for-byte
+# copy of the dark one, so a light desktop drew dark GTK4 windows. They are now
+# a marked block that panama-theme-apps rewrites from the active theme, with a
+# thousand lines of vendored structural CSS around it that must survive
+# untouched.
 
 set -uo pipefail
 
@@ -85,4 +93,65 @@ for scheme in dark light; do
     done
 done
 
+# ── The generated colour block ───────────────────────────────────────────────
+catalog="$repo_dir/config/dot/quickshell/config/themes.json"
+gtk_css_files=(gtk-3.0/gtk.css gtk-4.0/gtk.css gtk-4.0/gtk-dark.css)
+
+for relative in "${gtk_css_files[@]}"; do
+    tracked="$repo_dir/config/dot/$relative"
+    [[ -r "$tracked" ]] || fail "$relative is missing"
+
+    grep -q 'PANAMA THEME BEGIN' "$tracked" \
+        || fail "$relative has no PANAMA THEME BEGIN marker, so the palette is never written into it and GTK keeps whatever colours the file shipped with"
+    grep -q 'PANAMA THEME END' "$tracked" \
+        || fail "$relative has no PANAMA THEME END marker; the generator would rewrite the rest of the file"
+
+    # The shipped file has to be valid before it has ever been regenerated: a
+    # fresh checkout renders GTK windows before the first theme change.
+    grep -q '@define-color window_bg_color' "$tracked" \
+        || fail "$relative ships without a window_bg_color, so a fresh checkout draws GTK windows in adw-gtk3's stock greys"
+
+    cp "$tracked" "$fixture/$relative"
+done
+
+mkdir -p "$fixture/panama"
+
+# One dark theme and one light one, named through settings.json the way the
+# shell names them.
+for pair in "dark:$(jq -r .defaultDark "$catalog")" "light:$(jq -r .defaultLight "$catalog")"; do
+    scheme="${pair%%:*}"
+    theme_id="${pair#*:}"
+    want_bg="$(jq -r --arg id "$theme_id" '.themes[] | select(.id == $id) | .palette.bg' "$catalog")"
+    want_accent="$(jq -r --arg id "$theme_id" '.themes[] | select(.id == $id) | .accent' "$catalog")"
+
+    jq -n --arg id "$theme_id" --arg scheme "$scheme" \
+        '{colorScheme: $scheme, themeProfileId: $id}' >"$fixture/panama/settings.json"
+    XDG_CONFIG_HOME="$fixture" "$theme_apps" "$scheme" >/dev/null 2>&1
+
+    for relative in "${gtk_css_files[@]}"; do
+        generated="$fixture/$relative"
+        block="$(awk '/PANAMA THEME BEGIN/,/PANAMA THEME END/' "$generated")"
+
+        grep -qF "@define-color view_bg_color $want_bg;" <<<"$block" \
+            || fail "$relative did not take \"$theme_id\"'s background ($want_bg) for $scheme -- the block is not being regenerated from the theme"
+        grep -qF "@define-color accent_bg_color $want_accent;" <<<"$block" \
+            || fail "$relative did not take \"$theme_id\"'s accent ($want_accent) for $scheme"
+
+        # Nothing outside the markers may move. That is the entire reason for
+        # a marked block rather than a generated file.
+        diff <(sed '/PANAMA THEME BEGIN/,/PANAMA THEME END/d' "$repo_dir/config/dot/$relative") \
+             <(sed '/PANAMA THEME BEGIN/,/PANAMA THEME END/d' "$generated") >/dev/null \
+            || fail "$relative changed OUTSIDE the markers -- the vendored theme's structural CSS is being rewritten"
+    done
+done
+
+# The last render above was light, so this reads the light result: gtk-4.0's
+# gtk.css shipped as a byte-for-byte copy of the dark one, which is how a light
+# desktop kept drawing dark GTK4 windows.
+light_bg="$(sed -n 's/^@define-color view_bg_color #\([0-9a-fA-F]\{6\}\);.*/\1/p' \
+    "$fixture/gtk-4.0/gtk.css" | head -1)"
+[[ -n "$light_bg" ]] || fail 'gtk-4.0/gtk.css has no view_bg_color after a light render'
+(( 16#${light_bg:0:2} > 128 )) \
+    || fail "gtk-4.0/gtk.css renders a DARK background (#$light_bg) in light mode -- the original bug"
+
 printf 'gtk theme contract: PASS\n'