* Add a theme-set sample hook that mirrors themes to herdr machines
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Mirror theme changes to herdr machines by default
Replaces the sample hook with omarchy-theme-sync, which omarchy-theme-set
starts detached after every theme change, and a theme-sync-off toggle that
stops a machine from both sending and receiving.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Rename omarchy-theme-sync to omarchy-theme-set-herdr-machines
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Label the toggle Herdr Theme Sync and extract its menu guard
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Answer the Herdr Theme Sync menu guard from omarchy-theme-set-herdr-machines
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Sync herdr machines one at a time and drop the dry run
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Check the theme sync toggle under the lock and stop special-casing this machine
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Make herdr theme sync opt-in
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Decode the next theme background while the theme stages
The wipe waited 125-290ms after the transition arrived, decoding the new
wallpaper. Most stock wallpapers are WebP, which Qt decodes at full size
and scales afterwards, so a screen-sized sourceSize does not shorten it.
Start the decode earlier instead. omarchy-theme-set chooses the next
background and snapshots it before rendering templates, then sends a new
background prepare call in the background. The shell loads it into the
hidden incoming frame, so the transition finds it decoded. A prepare that
arrives after its transition is ignored, and one no transition claims is
dropped after five seconds.
The wipe now starts ~255ms after omarchy-theme-set begins instead of
~345-490ms.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Decode the wallpaper at screen size instead of shipped size
Wallpapers decoded at the resolution they were shipped at: a 5120x2880
stock wallpaper took 5120x2880 of RGBA on a 1920x1200 panel, and a
transition held up to three such frames. Bind sourceSize on the
displayed wallpaper and both transition frames to the screen's physical
size. PreserveAspectCrop treats it as the area to cover, so the image
still fills the screen.
Qt scales a decode up as well as down to cover sourceSize, so the native
size is read from the file header first with magick identify, and a
wallpaper smaller than the screen decodes at its own size. The images
wait for both sizes, so nothing decodes at native size first.
Ported from #8324 onto BackgroundMedia and the prepared incoming frame.
Measured with a 5120x2880 wallpaper, the shell's GPU memory at rest
drops from 264 MiB to ~148 MiB. The size probe delays the reveal by
~30ms, which the earlier prepare still more than covers.
Co-authored-by: Ryan Yogan <ryanyogan@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Ryan Yogan <ryanyogan@gmail.com>
* Run menu summon actions in-process
A menu action that only summons another shell plugin spawned bash and a
qs ipc client to ask this same shell to do it, about 60ms of the path.
Call shell.summon directly instead, and fall back to bash when the call
is refused or the action is anything more than a bare summon.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Open the theme picker from rows held in the shell
Opening the theme picker ran omarchy-theme-switcher to rebuild its index
and then made a second IPC call, about 170ms before the picker mapped.
The picker now holds the theme rows itself, opens from them at once, and
refreshes them behind the open via omarchy-theme-switcher --print-rows.
It applies the chosen theme with omarchy-theme-set directly, so
omarchy-theme-set no longer preloads the picker.
From the keybinding to the overlay mapped drops from ~245ms to ~83ms.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Keep the image picker surface mapped between opens
Each open mapped a fresh surface, which rendered its first frames before
Hyprland sent its fractional scale: the pixel ratio stepped 2, 1, then
1.6, so the picker flashed blurry for ~130ms and re-uploaded every
thumbnail texture. Keep the surface and park it transparent and
input-less on the bottom layer while closed, since anything on the
overlay layer blocks direct scanout for fullscreen apps. It follows the
focused monitor on each open.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
T3 Code reads themes an environment publishes into its state directory, so
a generated t3code.json carries the palette the same way claude.json and
vscode-theme.json already do, and omarchy-theme-set-t3code republishes it
on every theme change for the app to pick up live.
The template overrides only the roles a theme actually designs -- terminal
and code surfaces, text on canvas, borders, selection -- and leaves muted
text, placeholders, and status foregrounds to T3 Code, which contrast-solves
them against whatever canvas it is given. Overriding those directly cost
readability on light themes: White fell to 1.0:1 on placeholder text.
Installing from the menu now routes through omarchy-install-ai-t3-code so a
fresh install publishes the current palette and opens wearing it.
* Add native video wallpaper support
* Pause video wallpapers while a fullscreen app is focused
* Sample one frame when a video background sets the bar text colour
A video wallpaper made the transparent bar's colour sampling decode the entire file. ImageMagick's video delegate runs ffmpeg with no frame limit, so a twenty-second 1080p background took 11.3s of CPU where one frame takes 0.14s, and it did that on every theme change.
The result was unusable anyway: a multi-frame input emits one value per frame, which the single-value match then rejected, so transparent bars silently fell back to the plain text colour on every video wallpaper. Selecting frame zero fixes the cost and the colour together, and fixes animated GIFs, which had the same bug.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Load wallpaper video lazily, and without an audio output
Three costs the still-image path should never have paid.
BackgroundMedia imported QtMultimedia at file scope and was instantiated on every output, so the module and its audio dependency closure mapped into every shell process whether or not a video was ever shown — measured at +2.72 MiB RSS. Moving the element into its own file behind a Loader that takes a URL defers the whole import: an inactive loader maps none of it, an active one maps all 25 libraries. An inline Component cannot defer that, because the type has to resolve when the file compiles.
Qt's Video convenience type always builds an AudioOutput, and `muted` only aliases that sink's volume, so every monitor decoded an audio stream it would never play and opened an audio client for it. A bare MediaPlayer with no audio output spawns no QFFmpeg::AudioR, QAudioContext or PWDevMon thread, and plays files with no audio track just the same.
The shared image also turned mipmapping on, which the desktop background never had. A full mip chain is about a third more texture memory — 10.6 MiB extra at 4K, per output — for a wallpaper drawn at its own size.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Stop wallpaper playback while the session is locked or screensaved
Playback stopped only for a focused fullscreen window. Locking the session did not stop it, and the lock screen starts a player of its own, so an N-monitor desktop reached 2N decode pipelines the moment it locked — and stayed there, because a display blanked for idle stops being presented but does not stop Qt's FFmpeg engine, which drives its own clock. A laptop locked with the lid shut decoded video until the battery ran out.
The lock and idle services already know both states, so the background service takes the shell reference the loader offers it and reads them. Looking a service up by id needs the registry to be reactive, or a background that loads before the lock service would bind to null and stay there.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Fan out video thumbnails narrower than single-threaded image jobs
The generator fans out one job per core, which was bounded because VIPS_CONCURRENCY=1 made each of them single-threaded. ffmpegthumbnailer leaves FFmpeg's automatic decoder threading on, so a folder of uncached videos put a codec thread pool on every core at once. Queueing video work separately keeps the still-image path at full width and gives the video path a quarter of it.
* Recognize a named video file as a theme preview
The backgrounds fallback beside it already picks videos, so a theme shipping preview.mp4 was the one case that still went unseen.
* Document video backgrounds in the manual
The manual described backgrounds as images only. Worth saying plainly that a video wallpaper costs far more power than a still one and that each monitor decodes its own copy, since neither is visible from the picker.
* Stop the lock screen's own playback once the displays go dark
Pausing the desktop wallpaper on lock only moved the cost. The lock screen builds a player per monitor of its own, so locking an N-monitor session went from N decoders to N rather than to none — and the lock service blanks the displays five seconds later without touching them, which is where a lock spends nearly all of its time. A laptop locked and shut still decoded video into a dark panel.
The service already owns both transitions, so it records whether the displays are dark and the lock view stops playback while they are. The manual said playback stops while the screen is locked, which was the same overstatement; it now says once a locked screen has gone dark.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Keep videos out of the lazy thumbnail path
A lazy row stands in with the media file itself until its thumbnail exists, and the picker draws that with an Image — which shows a picture and shows nothing for a video, with no reload once the real thumbnail lands. So the first open after discovering an uncached video showed a blank tile.
The same branch also spawns one generator per file immediately, before either queue is reached, and the theme switcher always asks for lazy thumbnails. That put the narrower video fan out on the one path that never used it: forty uncached previews meant forty ffmpegthumbnailer processes. Sending videos to the queue instead fixes the blank tile and puts them back under the cap.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Rebuild the theme preview cache after teaching it about video
Preview discovery changed what it recognizes, but its cache keys on theme directory mtimes alone. A theme that already shipped a video preview would keep whatever the old rules cached until something happened to touch the directory. Bumping the version rebuilds it once.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Drop an activeAudioTrack setting that never took effect
Qt's FFmpeg backend ignores setActiveTrack while no source is open, and the literal binding is not reapplied once the media loads and the tracks become known, so the line did nothing. What actually keeps the audio decoder and its client from ever being built is the absent audio output, which a file carrying an audio track confirms on its own: no QFFmpeg::AudioR, QAudioContext or PWDevMon thread appears without it.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Give up the blank state when a display comes back
The lock screen stops its wallpaper while the displays are dark, but it was tracking the blanking it asked for rather than the panels themselves. Opening a docked lid turns the internal panel back on without going through runWake, and so does a resume, which left a visible lock wallpaper frozen on one frame until the next keypress. A frozen wallpaper someone is looking at is worse than the decoding it saves, so a screen change gives the state up.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Time bound the video thumbnail generator
Routing videos through the queue means they are generated before the picker opens rather than behind it, which turned an unreadable or stalled file into a picker that never opens. ffmpegthumbnailer had no bound of its own and the drain waits for every job. A generator that gives up is already handled: the run reports failure, the partial file is removed, and the row drops out of the list.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Pause only the output a fullscreen window covers
The fullscreen test was global, so a game on one monitor stopped the wallpaper on every other one — including the ones still in plain view. That is the failure the lock work was careful to avoid, and it made the manual's claim that playback stops when nothing can see it untrue for the commonest multi-monitor case. A lock or a screensaver does cover every output, so those stay a single decision; fullscreen is now matched against the focused monitor, the way the bar already routes by output.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Kill a video thumbnail generator that ignores the timeout
Plain timeout sends TERM and then waits for a process that may never take it, which leaves the bound it was added for unenforced on exactly the stuck files it was meant to catch.
Co-Authored-By: Codex XHigh <noreply@anthropic.com>
* Pause video wallpapers in battery power-saver
* Fix paused video wallpaper source priming
* Skip snapshots for video background transitions
(cherry picked from commit 6f759538bfa76c2da03634e98ebfc2ebf63ec68e)
* Generate thumbnails for direct-scan videos
(cherry picked from commit 10fcca018a865dca311fb6863e8c8b0057291223)
* Remember a video the thumbnail converter rejected
A permanently unreadable video cost ten seconds of generator time on every
picker open before its row dropped, because nothing recorded the failure.
Both the menu image generator and the direct picker scan now leave a marker
beside the missing thumbnail, keyed like the thumbnail on the file's size
and mtime, so a repaired file starts clean. A timeout is left to retry, as
it may only have been a busy machine.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Follow the panels' real DPMS state under a locked video wallpaper
The lock screen stopped video playback when it asked for the displays to
blank, and resumed on input, but never checked what the panels did. A blank
that failed left a lit panel on one frozen frame, and a resume that turned
the same outputs back on played nothing until the next keypress.
Quickshell exposes no DPMS signal, so while a video is the locked wallpaper
the lock polls hyprctl and decides per surface from the answer. A wake or
blank request drops the last answer so its optimistic state applies until
the next poll confirms it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Pause a video wallpaper for the fullscreen window that covers it
The fullscreen check read the globally active window and the focused
monitor, so it only knew about the window that had focus. A fullscreen
window left on one monitor while focus moved to another resumed the
wallpaper decoding behind it, and with fullscreen windows on two outputs
only the focused one paused.
Each output's visible workspace reports whether a fullscreen window covers
it, and Quickshell flips that on the compositor's fullscreen event, so each
panel now decides from its own monitor's active workspace instead.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Reopen a video wallpaper a theme switch replaced behind its path
Two themes that both ship backgrounds/wallpaper.mp4 leave the current
background at the same path after a switch, so the displayed path never
changed and the running player kept decoding the old file from its open
descriptor. Stills go through the snapshot transition and survive this;
a video switch is instant and did not.
A forced switch onto the path already on show now bumps a reload counter,
and BackgroundMedia rebuilds the video player for it. A cache-busting query
is not an option there, since FFmpeg reads it as part of the filename.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Keep picker rows uncached while a rejected video is left out
Skipping a video with a failure marker let the picker cache its rows
without it, and cached rows are trusted on the directory's mtime alone.
A file repaired in place never touches that, so the marker's fresh key
was never consulted and the video stayed missing.
The generator now hands the marker back to the row loop, which drops the
row and leaves the rows uncached, so each open re-stats the file and a
repaired one is converted again.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Hand each background loader only its own kind of file
BackgroundMedia fed one URL to both the still loader and the video player.
On a switch from image to video the Image was handed the video's URL in
the moment before its loader unloaded, so Qt tried to decode the mp4 as a
picture and logged an unsupported format on every such switch; the reverse
handed the player a still to demux.
The still URL is now empty whenever the path is a video and the video URL
empty whenever it is a still, so a switch changes only the loader that
stays.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Stop a video wallpaper before tearing its player down
Switching from a video to a still destroys the BackgroundVideo item while
its player is mid-read, which FFmpeg reports as a failed open in the shell
journal on every such switch. Stopping the player on destruction lets the
demuxer wind down first, and the switch is quiet.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Play a video wallpaper's sound track from the first monitor
Video wallpapers were always silent: the player was built without an
audio output, since a muted output still decodes the track and opens an
audio client on every monitor. A video with music should be able to play
it.
The player now builds its AudioOutput only once the media reports a sound
track, so a silent file still opens no audio client, and only the first
screen's panel opts in, so a multi-monitor desktop does not layer copies of
the track. The output is muted while a paused player primes its first
frame, and the lock screen stays silent.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Keep a departing video player off the still's file
The switch away from a video still logged a cancelled open, and stopping
the player on destruction only hid it: stopping reports the media as
loaded, which the loaded handler answered by playing again. The real cause
was one evaluation pass. Both URLs derived from the `video` flag, which is
itself bound to the path, and QML updates the two in no fixed order, so
the video URL could evaluate against the stale flag and hand the player
the still for a moment. Its destructor then cancelled that open.
Each URL now tests the path directly, the source binding only applies
while the path is a video and restores nothing when it stops, and the
destruction stop goes away with the hazard it introduced.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Pin the audio wiring in the test and name the output in the manual
The audio assertion passed with the BackgroundMedia forwarding binding
removed, which would have left every wallpaper silent, and did not pin the
silent default or the first-screen selection. It covers all three now.
The manual said the sound track plays "from your first monitor", which
reads as routing to that monitor's audio device. It is the first monitor's
wallpaper that plays, through the default output.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Omabot <omabot@omarchy.org>
Co-authored-by: Codex XHigh <noreply@anthropic.com>
Co-authored-by: z8 <yam@kernelius.com>
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Hermes Desktop installed under Install > AI kept its own palette while every other agent app retinted with the theme. Hermes' skin is its one theme unit for the desktop app, the TUI and the CLI, and its gateway watches the active skin file and broadcasts changes to every surface, so Omarchy publishes a skin named omarchy from a template on every theme switch and nothing Omarchy-specific goes upstream.
Activation goes through hermes config set, which writes the active profile's config and touches the skin so a running gateway repaints at once, and it only replaces Hermes' default skin so a choice made in Hermes stays. A theme switch runs that activation too when the desktop package is present and Hermes is still on its default, so a hand-over the installer missed is finished by the next switch; once the config names the skin a switch never starts Hermes. The desktop adopts a skin from a change broadcast rather than from the config it finds at connect time, and its first launch builds the runtime over minutes, so the installer starts --wait as a transient user unit that outlives the install terminal, activates once the runtime marker appears, republishes after the gateway is up, and reports to the journal. A migration hands the skin to existing Hermes Desktop installs through --activate, which also renders the skin for a theme applied before the template existed.
The generated file is validated before it is published, because Hermes parses it as YAML: only the name, a plain description and #rrggbb colours pass, so an unresolved palette key or a cloned theme's own hermes.yaml leaves the previous skin in place.
🤖 Generated by Fable 5.1 in Claude Code. Reviewed by Fable 5.1 code-review at high.
* Stop an installed theme from shipping code
`omarchy theme install <url>` clones a stranger's git repository into ~/.config/omarchy/themes, and omarchy-theme-set then copied that whole directory into the staged theme. Most of the files in a staged theme are code rather than colour: Hyprland requires hyprland.lua and gum_env.lua from it at login, Neovim loads neovim.lua at startup, and alacritty.toml, kitty.conf, foot.ini and ghostty.conf each name the program the terminal launches. Installing a theme was the same act as running its author's code, and nothing on disk distinguishes an installed theme from one the user wrote.
Stage only what a theme needs in order to be a theme: colors.toml, light.mode, the preview and unlock images, and image files under backgrounds/. Everything else is ignored, named on stderr, and generated from default/themed/*.tpl instead. Symlinks are never followed, because in an untrusted theme they point wherever the author chose. A theme older than colors.toml keeps its palette: its alacritty.toml is read for colours in a scratch directory and only the resulting colors.toml is staged, so the terminal config never lands.
The filter belongs in omarchy-theme-set rather than in omarchy-theme-install because staging is the choke point. It also covers themes installed before this change, themes copied in by hand, and files a theme gains later through `omarchy theme update`.
First-party themes under $OMARCHY_PATH/themes are unaffected. Per-theme overrides of a generated file are no longer available to user themes; the template at ~/.config/omarchy/themed/<file>.tpl replaces that, and icons.theme is the one setting with no replacement.
🤖 Generated by Opus 5 in Claude Code.
* Stop a theme URL or name being read as an option or a path
Three paths in the theme commands took an attacker-shaped string straight into git, into basename, or into rm.
`git clone "$REPO_URL"` passes the URL as the first positional argument, so a URL beginning with a dash is parsed as an option instead and the destination path becomes what git tries to clone. Pass `--` before the URL so a URL is always a URL. git also treats `<helper>::<address>` as a remote helper to run; git's own protocol.allow default already refuses `ext::`, so rejecting that shape here is a second line rather than the fix, and it keeps holding if that default ever moves. The helper name is a bare word at the very start of the URL, which is what the guard matches: an scp-style IPv6 host such as git@[2001:db8::1]:org/repo.git carries `::` of its own and still clones.
`basename "$REPO_PATH" .git` has the same problem one step later, after the scp-style prefix has been stripped: `host:-s/foo.git` leaves basename reading `-s` as an option and returning `.git` as the theme name. Take the name with `--`.
That name is then joined into a path that is about to be `rm -rf`'d, so a repo whose basename came out as `..` would take ~/.config/omarchy with it. omarchy-theme-remove had the same shape from its own argument, and omarchy-theme-set's sed/tr normalization does not stop a name containing a slash. Reject empty, anything starting with a dot, and anything containing `/` in all three, before the name reaches a path.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.
Co-Authored-By: Codex XHigh <codex@openai.com>
* Re-stage the current theme for installs that already applied one
Dropping a theme's code at staging time only takes effect the next time a theme is staged. An install that already applied an extra theme keeps that theme's hyprland.lua, gum_env.lua, neovim.lua and terminal configs in ~/.local/state/omarchy/current/theme, which Hyprland requires at login and the terminals include at launch, and nothing forces a theme change — so for those installs the fix would arrive whenever the user next happened to switch themes, which may be never.
Re-stage once through omarchy-theme-refresh. First-party themes stage identically, so the cost for everyone else is a single retint during an update they are already running.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.
Co-Authored-By: Codex XHigh <codex@openai.com>
* Stop a theme's unlock image republishing a file it points at
omarchy-plymouth-set-by-theme reads unlock.png straight out of ~/.config/omarchy/themes, which is an installed theme's own directory and outside the staging filter, and hands the path to omarchy-plymouth-set. That path was copied twice into world-readable /usr/share — once by the user into the Plymouth theme, and once by `sudo cp` into the SDDM theme. A symlink there was followed both times, so a theme could name a file it cannot read and have root publish it.
Refuse a symlinked logo, and copy the staged logo to SDDM instead of rereading the caller's path as root. The staged copy is made by the user, so nothing privileged opens a path the caller chose.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.
Co-Authored-By: Codex XHigh <codex@openai.com>
* Limit only what an installed theme could run
Two corrections to the rule this branch introduced, both narrowing it to what it was actually for.
It applied to every theme under ~/.config/omarchy/themes, which swept up themes the user wrote themselves. Their machine, their file: a theme they wrote is theirs to fill however they like, and Omarchy's own themes were never in scope. Only a theme that came from someone else needs limiting, and the repo already knows which those are — omarchy-theme-extras calls a theme with a `.git` directory an extra and a symlink someone's working copy, because that is what `omarchy theme install` leaves behind when it clones. Use the same test.
It was also an allowlist, which dropped files that carry nothing but colour and left theme authors worse off for no gain. Drop only what can run: any `*.lua`, since Hyprland requires a theme's hyprland.lua and gum_env.lua at login and Neovim loads neovim.lua at startup; the four terminal configs, since each names the program the terminal launches; and vscode.json, whose extension field reaches `code --install-extension` and a VS Code extension is arbitrary JavaScript. Everything else an installed theme ships is kept, so btop.theme, chromium.theme, helix.toml, icons.theme, keyboard.rgb and shell.toml go back to being the theme's to set.
Symlinks are still dropped, now at any depth rather than only where an allowlist happened to look.
A denylist is wrong the moment someone adds a template and does not think about it, so the decision is forced rather than remembered: the test fails on any default/themed/*.tpl whose output is recorded as neither code nor colour, and a new terminal or a new Lua-loading editor cannot be added without classifying it.
What this does not cover, and is written down in docs/theming.md rather than implied: a theme shipped as an archive and unpacked by hand looks exactly like one the user wrote. `omarchy theme install` only takes git URLs, so the supported path is always filtered, but this marks where a theme came from and is not a sandbox.
🤖 Generated by Opus 5 in Claude Code.
* Fix what the review found
Four things, all confirmed against the source before changing anything.
The migration failed permanently when the active theme had been removed. `omarchy theme remove` deletes the directory without repointing theme.name, so the name survives, the staged copy survives, and omarchy-theme-refresh exits 1 because neither source directory exists — leaving the migration pending forever and the stale staged Lua exactly where it was, which is the one thing it existed to remove. Seed the default theme in that case: there is nothing to re-stage from, and the removal should have left a working theme behind anyway.
The staging test skipped the strict-mode header that docs/testing.md makes the contract for every shell test. Adding it means the patterns that fail on purpose have to stop being bare `cmd && fail` compounds, which errexit reads as the script itself failing; the mutations were re-run afterwards to confirm the assertions still fire rather than the run dying early and looking like something else.
The guards in omarchy-theme-install and omarchy-theme-remove had no coverage — they were checked by hand and left that way. theme-install-guards-test.sh stubs git and the themes directory and proves an option-shaped URL, a transport helper, and a name that would climb out all stop before git or rm runs, that a dash inside the path no longer becomes a basename option, and that an ordinary URL still clones and applies.
The new docs/theming.md prose was hard-wrapped, which AGENTS.md forbids for docs/. Unwrapped. The rest of that file is wrapped from before and is left alone rather than churned through this change.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh and Copilot.
---------
Co-authored-by: Codex XHigh <codex@openai.com>
* Make WhatsApp Web follow your Omarchy light/dark theme
WhatsApp Web's "System default" theme follows prefers-color-scheme and
repaints live, so a small theme bridge is enough to make it track the active
Omarchy theme with no reload and no WhatsApp-specific CSS.
- omarchy-chromium-theme-host: push-only native messaging host that reads the
active theme and emits it on connect and on every theme-set. Unlike copy-url/
yt-dlp (one-shot), it stays connected and pushes, since theme-following needs
the page to learn about changes while it is running.
- omarchy-chromium-theme-refresh: SIGUSR1s the running host(s); called from
omarchy-theme-set's post_theme_commands.
- whatsapp-theme extension: decides dark vs. light from the theme background's
WCAG luminance and drives a prefers-color-scheme shim, so WhatsApp's own
theme does the repaint.
Wired like copy-url/yt-dlp and whatsapp-slim: bundled under
default/chromium/extensions, added to --load-extension, host manifest
registered from the fresh-install/refresh/browser-install paths, existing users
covered by a migration.
The host is named com.omarchy.theme (a generic theme bridge) rather than
WhatsApp-specific, so other bundled web-app extensions can follow the theme by
connecting to it and adding their id to the host manifest's allowed_origins.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Address review on the WhatsApp theme bridge
Light/dark was decided by weighting raw sRGB bytes, which the comment above
it already described as WCAG relative luminance. sRGB is gamma-encoded, so
the weights only mean anything once each channel is linearized — the two
steps the shell already does in Panel.qml. Every shipped theme classifies the
same either way; a mid-tone custom background does not (#808080 reads 0.502
unlinearized and 0.216 linearized).
Drop the `tabs` permission. The WhatsApp host permission is what lets
tabs.query filter by url and what populates tab urls in onUpdated, so `tabs`
only widened this to every tab's url and title. Tabs without permission
arrive with url unset and fall out on the existing guard.
Give the two new bin commands their metadata directives. Without a summary
they failed test/cli's command metadata check.
Cover all three: the classifier over unambiguous and mid-tone backgrounds,
and the manifest for the permission it should no longer ask for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Scope color-scheme listeners to their query and test the real host
Registrations all shared one Set keyed only by callback, so an app that gave
the same callback to both the dark and the light query and later detached one
detached the other too, leaving the query it still held deaf to theme
changes. Record the owning MediaQueryList and match on it. Adds native
dedupe behaviour while there: registering the same callback twice fired it
twice. addListener is a legacy alias of addEventListener("change"), so the
two share one registration space and either remover cancels either add —
which is also why useEvent had nothing left to select and is gone.
The refresh test signalled a synthetic sleeper carrying its own USR1 trap, so
it proved the refresh command sends a signal but would have stayed green
through any regression in the host's own trap, watchdog wait, or second
write. Drive the real host over a FIFO instead, count framed messages, and
assert the second one is a usable theme. Verified by neutering the host's
USR1 trap: the old test passed, this one fails.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Harden Chromium theme bridge
* Address Chromium theme bridge review
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
Remove legacy online installer entrypoints, collapse migrations for 4.0, and move setup responsibilities into target-side system, hardware, and user commands.
Based entirely on the work of @robzolkos in #5711. That attempt was
adapted to better fit the standard templating system while also adding
color mixing for use in other themes.
omarchy-shell's bar plugin replaces waybar on every default path, so the
waybar package, configs, indicator scripts, and toggle/restart/refresh
binaries all go away in this commit.
The four small helper scripts that Bar.qml shells out to (weather.sh and
indicators/*.sh) move with the shell rather than disappear \u2014 they live
at default/quickshell/omarchy-shell/scripts/ now, alongside the rest of
the shell code.
Companion script changes:
- omarchy-shell-ipc gains --if-running so fire-and-forget refresh
callers (toggle-idle, toggle-notification-silencing,
update-available-reset, capture-screenrecording) don't accidentally
spawn the shell when it isn't already up.
- omarchy-theme-set, omarchy-tz-select, omarchy-voxtype-{install,model},
omarchy-toggle-nightlight, omarchy-voxtype-config drop their waybar
branches and comments.
- omarchy-voxtype-status's summary stops claiming it's a Waybar helper.
- omarchy-base.packages drops waybar; install/packaging/fonts.sh's
comment points at the new bar consumer.
- SKILL.md / AGENTS.md / omarchy-menu.jsonc lose their waybar entries.
- test/omarchy-cli-test.sh substitutes a remaining toggle command.
Adds first-party omarchy.notifications service plugin that hosts a
freedesktop notification server and renders popups + a history popup
inside the shell. Uninstalls mako and retargets every helper, keybind,
indicator, and migration entry to the new daemon.
Plugin (default/quickshell/omarchy-shell/plugins/notifications/):
- Service.qml: NotificationServer, popupModel + pendingModel + pastModel
(two-tier history, see below), DND via PersistentProperties +
cache-file backstop, image cache for /tmp screenshots, IpcHandler with
toggleDnd/setDnd/isDnd/showHistory/clear/clearPending/markAllSeen/
dismissAll/dismissOne/invokeLast/dismiss, per-theme override file
~/.config/omarchy/current/theme/notifications.json honoring
borderColor/backgroundColor/textColor/countdownColor.
- components/NotificationCard.qml: theme-driven card (Color.foreground/
background/border tokens from Commons/Color.qml), 32x32 icon slot,
Nerd Font glyph fallback via omarchy-glyph hint, hero image strip
for screenshot/image-path notifications, hover-pause progress bar,
uses bar.fontFamily so all surfaces share one font.
Filtering and DND:
- transient hint and CLI-style senders (app_name in notify-send /
omarchy-action) bypass history but still pop.
- DND only allows omarchy-action toasts and notify-send -u critical
through; real-app urgency=critical (Discord, Slack, Vesktop) is
silenced and lands in pending instead.
- Pending vs past split surfaced via tabs in the bar widget popup;
past tab is auto-pruned at the 15-minute mark.
- Click-to-jump: notifications without a libnotify default action focus
the matching Hyprland window via class lookup.
Shell host:
- shell.qml: generic first-party service loader (mirrors the existing
noctalia-compat path) and an alias for the bar so plugins can read
barSize / barHidden / position for anchoring.
- Commons/Color.qml: parses the theme's hyprland.conf for
$activeBorderColor so notifications match Hyprland window borders;
picks the explicit accent= key over the color4= alias.
Bar widget rebase (plugins/bar/widgets/notificationCenter.qml):
- Drops the chunk-1 stub server, binds count/dnd state to the service,
hosts the history popup via PopupCard so it drops down from the
notification glyph the same way Quick Settings does.
- Pending/Past tabs, dismiss-individual close X, mark-all-as-seen and
clear-recent action buttons, theme-driven palette.
Quick Settings rework (plugins/bar/widgets/controlCenter.qml):
- DND tile binds directly to service.doNotDisturb for instant feedback.
- Drops the volume slider (already in audioPanel) and the no-op Theme
tile; adds a Bluetooth toggle bound to Quickshell.Bluetooth.
- Bigger 44x44 wallet was scaled back to 32x32 for tighter rows.
Notification scripts (bin/omarchy-*):
- omarchy-notification-send: passes glyph as a custom hint instead of
prepending to the summary; adds -a omarchy-action and -u urgency
automatically; supports -e/--transient passthrough.
- User-action toasts in the capture / toggle / hyprland / default-*
scripts and bindings/utilities.lua now tag themselves
-a omarchy-action so DND treats them as intent-based bypass.
- omarchy-toggle-notification-silencing, omarchy-notification-dismiss,
default/waybar/indicators/notification-silencing.sh, and the Hyprland
comma-keybinds all route through omarchy-shell-ipc notifications.
- omarchy-capture-screenshot / -screenrecording set the image-path
hint properly so the hero-image rendering kicks in.
Mako removal (migrations/1778743515.sh):
- pkill -x mako, systemctl --user stop mako.service, pacman -Rns mako
(uninstalling deletes /usr/lib/systemd/user/mako.service so D-Bus
activation can't respawn it). Removes ~/.config/mako/ and the legacy
toggle file. Restarts quickshell so it claims the bus name.
- Drops mako from install/omarchy-base.packages, autostart.lua,
install/config/theme.sh + toggles.sh, default/themed/mako.ini.tpl,
default/mako/, the omarchy-menu Mako restart row, bin/omarchy
GROUP_DESCRIPTIONS, the settings panel catalogue, and the
default/omarchy-skill paths table.
- Removed scripts: bin/omarchy-restart-mako,
bin/omarchy-style-corners-mako.
- bin/omarchy-style-corners summary updated; corner radius for the
notification card reads ~/.local/state/omarchy/toggles/quickshell-menu.json
alongside the rest of the shell.
Helix had no theme integration. Installing it from the menu just ran
omarchy-pkg-add and left the editor on whatever default theme it shipped
with, regardless of the active Omarchy palette.
This adds `default/themed/helix.toml.tpl` so the template
renderer produces a helix.toml on every theme switch, and
`omarchy-install-helix` that wires Helix up:
- install the package
- symlink `~/.config/helix/themes/omarchy.toml` at the rendered theme
- seed a config.toml selecting that theme when the user has none
The install menu routes Helix through this script. omarchy-restart-helix
joins omarchy-theme-set and signals Helix with SIGUSR1 so theme changes
are live [[1]], the same way as other packages. Arch-based distros
package the binary as 'helix' rather than upstream 'hx', so the new
scripts target 'helix' and the installer ends with a hint about aliasing
'hx'.
[1]: https://docs.helix-editor.com/configuration.html
Ref: https://github.com/basecamp/omarchy/discussions/4986
* add generation of colors.toml via alacritty.toml
* Shorter command name
* Fix perms
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
* UPDATE: select background method
* ADD: migration file for background selector
* Add symlink for background selector in walker-elephant.sh
Forgot about this file. Should be added to make sure the background selector feature available in the fresh install
* clean up the code a bit
Updated omarchy background selector to hide from provider list and removed subtext from entries.
* Make the background selector the default
* Fix migration
* FIX: typo on background symlink target
* UPDATE: add ~/.config/omarchy/backgrounds/theme.name
* UPDATE: Cache = false
* Fix escaping for all extensions
* Extract omarchy-theme-bg-set
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Instead of choosing exclusively between the official or user theme
directory, copy the official theme first, then overlay any user
customizations on top. This allows users to override specific files
(e.g. colors, backgrounds, keyboard backlight) without having to
duplicate the entire theme.
