Title:
GSettings accent-color not updated after theme generation breaks libadwaita 1.6+ accent sync
Describe the bug
After running matugen, apps using libadwaita 1.6+ display the wrong accent color. The CSS is updated correctly in dank-colors.css but org.gnome.desktop.interface accent-color in GSettings is never touched. Since libadwaita 1.6+ prioritizes GSettings over CSS for accent color, any app that opens after a theme change picks up the stale value.
Additional issue: atomic rename breaks inotify-based watchers
Matugen writes files via atomic rename (write to temp, rename over original), which doesn't trigger close_write. Any tool watching the output CSS with inotify will never detect the change. A mtime polling approach is needed as a workaround.
Expected behavior
After matugen generates a theme, org.gnome.desktop.interface accent-color should be updated to match the generated accent color.
Workaround
I worked around both issues with a systemd user service that polls dank-colors.css for mtime changes, maps the hex value of accent_bg_color to the closest libadwaita accent name, and sets it via gsettings. Had AI help me write it since shell scripting isn't really my thing, happy to share if useful.
Environment
Matugen version: 4.1.0
Distro: Nobara Linux (Fedora 43 base)
Desktop: Hyprland
libadwaita version: libadwaita-1.8.5.1-1.fc43.x86_64
Title:
GSettings accent-color not updated after theme generation breaks libadwaita 1.6+ accent sync
Describe the bug
After running matugen, apps using libadwaita 1.6+ display the wrong accent color. The CSS is updated correctly in dank-colors.css but org.gnome.desktop.interface accent-color in GSettings is never touched. Since libadwaita 1.6+ prioritizes GSettings over CSS for accent color, any app that opens after a theme change picks up the stale value.
Additional issue: atomic rename breaks inotify-based watchers
Matugen writes files via atomic rename (write to temp, rename over original), which doesn't trigger close_write. Any tool watching the output CSS with inotify will never detect the change. A mtime polling approach is needed as a workaround.
Expected behavior
After matugen generates a theme, org.gnome.desktop.interface accent-color should be updated to match the generated accent color.
Workaround
I worked around both issues with a systemd user service that polls dank-colors.css for mtime changes, maps the hex value of accent_bg_color to the closest libadwaita accent name, and sets it via gsettings. Had AI help me write it since shell scripting isn't really my thing, happy to share if useful.
Environment