Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Noro18/linux-ricing-dotfiles/llms.txt

Use this file to discover all available pages before exploring further.

Every color in this desktop — from Waybar’s surface tints to Kitty’s terminal palette — is derived automatically from your wallpaper. When you change the wallpaper, two color-generation tools run back to back and overwrite their respective output files, keeping every visible component in sync without any manual intervention.

​
The two tools

The pipeline splits color generation between two tools because they serve different purposes and target different components. Matugen implements the Material You design system. It reads the wallpaper image, extracts a dominant hue, and constructs a full palette of named semantic tokens — primary, secondary, surface, on_primary, tertiary, and more — in both light and dark variants. Those tokens are written into templates, and the rendered output files are consumed by:
  • Waybar — ~/.config/waybar/colors.css
  • Rofi — ~/.config/rofi/colors/colors-matugen.rasi
  • SwayNC — ~/.config/swaync/colors-swaync.css
  • Hyprland — ~/.config/hypr/colors/colors.conf
Wallust generates a classic 16-color terminal palette (the same format used by pywal). It produces color0 through color15 plus foreground, background, and cursor. Its output targets:
  • Waybar — ~/.config/waybar/colors-waybar.css (the raw palette variables)
  • Kitty — ~/.cache/wallust/colors-kitty.conf
  • VS Code / Cursor — ~/.cache/wallust/colors.json and ~/.cache/wallust/colors
Both tools run on every wallpaper change. Matugen handles the high-level semantic theme; Wallust handles the terminal and editor palette.

​
When colors update

Color files are regenerated every time a wallpaper is set — either through the wallset picker or automatically at login via wallset-backend-startup. The update is not triggered by anything else. Editing a generated color file by hand will have no lasting effect; the next wallpaper change will overwrite it.

​
Architecture diagram

The diagram below shows how all the pieces connect, from wallpaper selection through to each component: 
Wallpaper Selection
      │
      ▼
 wallset (menu)
      │
      ▼
wallset-backend
      ├──▶ swww               → changes the wallpaper
      ├──▶ matugen            → generates Material You color tokens
      ├──▶ wallust            → generates terminal/app color scheme
      └──▶ apply scripts      → patches each component with new colors
                │
                ├──▶ Waybar      (colors-waybar.css)
                ├──▶ Rofi        (colors-matugen.rasi)
                ├──▶ Kitty       (~/.cache/wallust/colors-kitty.conf)
                ├──▶ Hyprland    (colors/)
                └──▶ Swaync      (colors-swaync.css)
Never edit auto-generated color files directly — they are overwritten on the next wallpaper change. Always modify the generator templates in ~/.config/matugen/templates/ or ~/.config/wallust/templates/ instead.

Theming pipeline

Detailed step-by-step breakdown of how swww, Matugen, and Wallust transform a wallpaper into a synchronized color scheme.

Customization

How to modify Matugen and Wallust templates to control exactly how wallpaper colors map to each component.

Build docs developers (and LLMs) love

Get started for freeTalk to us