* Decode webp in the shell
The background and the lock screen are drawn by Quickshell, so they
decode through Qt, which ships handlers for png, jpeg and gif but not
webp. QImageReader answers "Unsupported image format" and the layer
comes up blank. Any third-party theme shipping a .webp background hits
this today, even though every path that goes looking for a background
already globs the extension.
qt6-imageformats supplies the missing plugin for 71 KB downloaded. Its
one new dependency of substance, libwebp, is already on every machine
by way of libvips.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Store theme backgrounds as webp
WebP codes both of the things these backgrounds are made of better than
the formats they were in: the photographs, where its lossy mode is worth
a third or more over JPEG at matched quality, and the flat art and dot
patterns, where its lossless mode undercuts an oxipng-packed PNG.
28 of them become lossless webp and decode bit-for-bit identically
(AE=0), so the dot patterns and flat-shaded pieces carry no quality
question at all. That includes 0-launch, whose alpha channel comes
through intact. The other 51 are photographs held to the same 38 dB
PSNR floor as the JPEG pass, landing between 38.0 and 54.6 dB. Every
image keeps its exact pixel dimensions, for 29.8 MB.
Each one is encoded from the original as it stands in quattro rather
than from the file the earlier commits produced, so nothing picks up a
second generation of loss on the way here.
13 stay JPEG. WebP is plainly larger for most of them, and three are
grainy enough that its filter smooths the grain instead of coding it:
PSNR plateaus near 34 dB however high the quality goes, well under the
floor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* fix `--help` being skipped for bin routes that only partially resolve to a file
* Add regression tests for --help on partially resolved routes
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Stop help-flag scanning at -- and match --json as an exact token
A `--` marks the rest of the args as belonging to the command itself, so
neither --help nor --json past it should be treated as router flags. The
--json check also matched substrings of flattened args, so a --json inside
one quoted argument switched --help output to JSON.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Repair theme symlinks the state-move migration left dangling
1781043107.sh re-linked legacy theme symlinks whose targets were stored
with a literal "~/.config/omarchy/current/..." string. The replacement
used the same literal tilde, which the filesystem never expands inside a
symlink target, so btop, Helix, and VS Code/Cursor lost their theme and
the migration reported success anyway.
Fix the source migration to relink through the already-defined
$current_state_dir variable, and add a follow-up migration that repairs
the links the applied version left dangling — matching the existing
1785002349.sh pattern, so it is idempotent and leaves custom links alone.
Co-Authored-By: Claude <noreply@anthropic.com>
* Only repair theme symlinks that could never have worked
The repair matched any target containing omarchy/current, so a working link
into a user's own dotfiles was rewritten to the state directory and their
setup was lost. Claim a link only when its target starts with a literal "~/",
which the filesystem never expands, and names this exact theme file: that is
what 1781043107.sh wrote, and no working link can look like it. A dangling
target is not enough on its own, since a dotfiles repo may just be unmounted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Clean up every scratch directory the CLI suite creates
Five of the eight mktemp directories were never registered with the exit
trap, so each run left them behind in /tmp. Route them all through a helper
that records them for cleanup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Drop the theme symlink migration tests
A migration runs once on each machine and is then inert, but a test for it
sits in the suite forever. Now that the repair behaves correctly, keep the
migration and let it go untested rather than grow the suite permanently.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: David Heinemeier Hansson <david@hey.com>
setup is where a user goes to configure something: direct boot, security
keys, hibernation. These three are not that. omarchy-apply-system is the
ISO's entry point in the target chroot, omarchy-apply-hardware is what it
calls for device quirks, and omarchy-apply-lock is called by
install/config/lockscreen-pam.sh.
apply is the verb they already used to describe themselves, and it carries
the contract: declared state under install/ converged onto the machine,
idempotent, safe to repeat.
The group gets no GROUP_DESCRIPTIONS entry on purpose. That table drives the
top-level group list on its own, so an entry would put apply back in front of
users even with every command in it hidden, the way provision already stays
out. A test covers it.
The ISO installs the runtime from the mirror it ships with, so it moves to
the new names in lockstep and no compatibility route is needed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The setup group is described as interactive setup wizards, but these three
are not that. omarchy-setup-system is the ISO's entry point in the target
chroot, omarchy-setup-hardware is what it calls for device quirks, and
omarchy-setup-lock is called by install/config/lockscreen-pam.sh. None of
them is something to browse to and run.
Hiding only affects listings, so the ISO and the install leaves keep routing
through the CLI exactly as before.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix: add bg/fg aliases for theme color resolution
Themes define bg/fg but the template system expects
background/foreground. The fallback chain only checked color0/color7,
leaving background/foreground empty for themes using bg/fg naming.
* Complete legacy theme palette compatibility
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
* Sync Omarchy themes to Claude Code
Claude Code 2.1.118 added custom themes as JSON files in
~/.claude/themes, watched and hot-reloaded, so this follows the same
shape as the Pi integration (da53c0ff, bin/omarchy-theme-set-pi).
A claude.json template renders from each theme's colors.toml — no
per-theme files, so every stock and community theme is covered — and
omarchy-theme-set-claude copies the result into
~/.claude/themes/omarchy.json on theme switch, retinting running
sessions without a restart.
The theme just appears as "Omarchy" in the /theme picker, and picking
it once (or running omarchy-theme-set-claude --activate) makes every
future theme switch carry Claude Code along. No ~/.claude directory,
no-op.
* Respect custom Claude config directory
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
1781158082.sh matched an explicit list of three legacy spellings for
~/.config/nvim/lua/plugins/theme.lua. At least one more exists in the
wild -- "../../../../.config/omarchy/current/theme/neovim.lua" -- so
those installs fell through the case, kept a dangling link, and Neovim
loaded no colorscheme spec at all. The failure looks theme-specific
because it only surfaces when you next switch themes.
Editing that migration would not help anyone, since it is already marked
applied. Add a new one that matches the shared suffix instead of an
enumerated list, so every spelling of the pre-state-dir path is caught.
It exits early when the link already points at the state directory and
ignores targets outside omarchy/current, leaving custom links alone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LjeyQZsNBxqyYy9z8KaKm7
The canonical colors.toml keys are now background/foreground, including
all permutations (dark_background, darker_background, lighter_background,
dark_foreground, light_foreground, bright_foreground). The old short
names are gone entirely, not kept as aliases; legacy alacritty-generated
themes still resolve through the ANSI color0/color7 fallback.
Theme files are also regrouped: accent/selection/muted first, then the
backgrounds, then the foregrounds, then the named colors.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Remove legacy online installer entrypoints, collapse migrations for 4.0, and move setup responsibilities into target-side system, hardware, and user commands.
