# Theming

The configuration app follows the Omarchy theme. Switch spaces, the theme
changes, and the app changes with it without being restarted.

## Where the colours come from

Omarchy writes the active theme to
`~/.local/state/omarchy/current/theme/colors.toml`, the same file the bar,
terminals, and editors read. The app reads it and overrides libadwaita's named
colours, so it matches the desktop rather than sitting in stock Adwaita while
everything around it is Ristretto or Osaka Jade.

| colors.toml | libadwaita |
|---|---|
| `background` | `window_bg_color` |
| `dark_background` | `view_bg_color`, `popover_bg_color` |
| `darker_background` | `headerbar_bg_color`, `sidebar_bg_color` |
| `lighter_background` | `card_bg_color` |
| `foreground` | every matching `_fg_color` |
| `accent` | `accent_bg_color`, `accent_color` |
| `red` | `destructive_*`, `error_*` |
| `green` | `success_*` |
| `yellow` | `warning_*` |
| `muted` | `.dim-label` |
| `mode` | forces the light or dark colour scheme |

Text on a filled button is picked by relative luminance rather than assumed
white, so a bright accent gets black text and stays readable.

## Following a change

The theme directory is watched, not the file. A theme change replaces the file
wholesale, and a rename swaps the inode out from under a file monitor, so
watching the file alone would miss it. This is the same trap the shell plugin
hit with its state file.

Reapplying is skipped when the palette has not actually changed, so touching
the directory does not rebuild the stylesheet for nothing.

## Turning it off

Delete or rename `colors.toml` and the app falls back to stock libadwaita. There
is no setting for this: an app that ignored the desktop theme by choice would be
a strange thing to offer.

## The shell plugin

The bar widget needs none of this. Quickshell plugins draw with Omarchy's own
`Color` and `Style` singletons, so the indicator and the workspace numbers
already follow the theme by construction. Only the GTK app had to be taught.