[BUG] run_matugen() regenerates the whole palette in light mode when gtk-application-prefer-dark-theme is 'true' instead of '1'

Aperta Adatta ai principianti
#1,765 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
bash, linux
Ambito
backend

Direzione di ricerca

Leggi .config/ml4w/scripts/ml4w-wallpaper, in particolare run_matugen() attorno al controllo della preferenza GTK alle righe 109–113, e confronta la sua gestione con quella dei due script citati nell’issue. Aggiorna il controllo in modo che 1 e true selezionino entrambi la modalità scura, mentre 0 e false selezionino la modalità chiara. Il lavoro è completato quando tutti e quattro i valori producono la modalità prevista senza stderr, come descritto nell’issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Describe the bug

run_matugen() in .config/ml4w/scripts/ml4w-wallpaper decides between light and dark mode with a numeric comparison against gtk-application-prefer-dark-theme:

https://github.com/mylinuxforwork/dotfiles/blob/3de368eb047c663d4ac06da1ce2558c96bc1ad2a/dotfiles/.config/ml4w/scripts/ml4w-wallpaper#L109-L113

theme_pref=$(grep -E '^gtk-application-prefer-dark-theme=' "$HOME/.config/gtk-3.0/settings.ini" | awk -F'=' '{print $2}')
local mode="light"
[ "$theme_pref" -eq 1 ] && mode="dark"

gtk-application-prefer-dark-theme is a GTK boolean, so true/false is an equally valid spelling of 1/0. When the key holds true, [ -eq ] fails:

$ theme_pref="true"; [ "$theme_pref" -eq 1 ] && mode="dark"
bash: line 1: [: true: integer expected

The && chain short-circuits, mode keeps its default light, and matugen regenerates the entire palette in light mode — waybar, window borders, GTK, rofi, swaync, btop, kitty, nwg-dock and the quickshell components all go light on a dark setup. With wallpaper automation enabled it happens unattended, so it looks like an update silently changed the theme.

This is an internal inconsistency, not a missing feature. Two other consumers of the same key in this repo already accept both spellings:

  • .config/ml4w/listeners/gtk-theme-switcher.sh — line 49 handles 1/true and 0/false explicitly, and even warns on unexpected values:
    if [[ "$THEME_PREF" == "1" || "$THEME_PREF" == "true" ]]; then
    
  • .config/hypr/scripts/gtk.sh — line 28 treats only 0/false as light:
    if [[ $prefer_dark_theme == "0" || $prefer_dark_theme == "false" ]]; then
    

So of the three places that read this key, only run_matugen() was left with the numeric test.

The dotfiles ship gtk-application-prefer-dark-theme=1, which is why this doesn't show on a clean install. It surfaces once any third-party GTK settings tool normalizes settings.ini to the boolean spelling.

Steps to reproduce

On my machine the key was flipped to true by kde-gtk-config, which is part of the default CachyOS package set even in a Hyprland session. It rewrote ~/.config/gtk-3.0/settings.ini and ~/.config/gtk-4.0/settings.ini into KDE's format — both files and ~/.config/xsettingsd/xsettingsd.conf share the same mtime to the second, and the values it left behind are KDE's (breeze, breeze_cursors, ocean). I did not determine what invoked it, so I can't give exact steps for that part.

The bug itself is independent of that trigger and can be reproduced directly:

  1. Confirm the current palette is dark: grep '"background"' ~/.config/ml4w/colors/colors.json
  2. Set the key to its boolean spelling:
    sed -i 's/^gtk-application-prefer-dark-theme=1/gtk-application-prefer-dark-theme=true/' ~/.config/gtk-3.0/settings.ini
  3. Re-run the wallpaper script:
    ~/.config/ml4w/scripts/ml4w-wallpaper "$(cat ~/.cache/ml4w/hyprland-dotfiles/current_wallpaper)"
  4. It logs Running matugen in light mode, and colors.json comes back light ("background": "#faf8ff" on my source wallpaper, vs #121318 before).
Expected behavior

run_matugen() should treat true the same as 1, consistently with gtk-theme-switcher.sh and gtk.sh, and keep generating a dark palette.

A one-line change is enough:

case "$theme_pref" in 1 | true) mode="dark" ;; esac

I verified this against all four values: 1 → dark, true → dark, 0 → light, false → light, with no stderr output. After applying it, the script logs Running matugen in dark mode and the palette returns to its previous values.

Screenshots

No response

Distribution

Other (please specify below)

If Other, specify

CachyOS (Arch-based), ML4W OS 2.12.3, Hyprland 0.56.1

Additional context

There is a second-order effect worth flagging: while the key holds true, .config/ml4w/scripts/ml4w-toggle-theme cannot switch modes either. It tests grep -q "gtk-application-prefer-dark-theme=1", does not match true, falls through to the else branch, and runs sed 's/gtk-application-prefer-dark-theme=0/...=1/', which does not match either. It prints Switched to dark theme while leaving the GTK3 file unchanged — so the user cannot correct the state from the UI, which is what makes the palette change feel permanent.

I searched open and closed issues before reporting (prefer-dark-theme, matugen, light theme, run_matugen, settings.ini, kde-gtk-config) and did not find this. #1596 looked close but is the opposite direction and was fixed in 2.13.0.

I have no strong preference on the fix; the case above is just the smallest change that matches what the other two scripts already do. Happy to open a PR if that helps.

Code of Conduct
  • I agree to follow this project's Code of Conduct
Lingua principale
QML
Stelle
5.1k
Fork
386
Merge medio
16h 45m
PR unite (30g)
14

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mylinuxforwork/dotfiles

Tutte le issue di mylinuxforwork/dotfiles

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.