* 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>
Omarchy shell
omarchy-shell is a single long-running Quickshell
instance that hosts the Omarchy desktop. Hyprland autostart launches one shell
per graphical session; everything else — the bar, background switcher, panels,
and overlays — runs inside the shell as a plugin.
Hosting everything inside one shell means:
- shared services and singletons live once, not once per process
- summoning a panel is an IPC call into a process that is already running,
not a fresh
quickshell -p ...cold start - third-party plugins can be loaded from disk without changing any source code in Omarchy itself
The runtime layout:
shell/
shell.qml entry point (ShellRoot)
services/
PluginRegistry.qml discovers, validates plugins, looks up enabled state in shell.json
BarWidgetRegistry.qml unified registry for bar widgets (1p + 3p)
plugins/
bar/ first-party plugins (see plugins/README.md)
image-picker/
menu/
notifications/
panels/
audio/
bluetooth/
monitor/
network/
power/
weather/
agents/
services/
battery/
idle/
osd/
polkit/
The plugin discovery path is documented in plugins/README.md.
Plugin manifest
Every plugin ships a manifest.json describing what it is and how the
shell should load it. Minimal example:
{
"schemaVersion": 1,
"id": "my.org.cool-clock",
"name": "Cool clock",
"version": "1.0.0",
"author": "You",
"description": "A clock that does cool things",
"kinds": ["bar-widget"],
"entryPoints": { "barWidget": "Widget.qml" },
"barWidget": {
"displayName": "Cool clock",
"category": "Time",
"allowMultiple": false,
"defaultSection": "left",
"defaults": { "format": "HH:mm" },
"schema": [
{ "key": "format", "type": "string", "label": "Format" }
]
}
}
Supported kinds:
| Kind | What it is |
|---|---|
bar-widget |
A component that the active bar can drop into a section |
panel |
A persistent or summoned floating window (e.g. OSD) |
overlay |
A fullscreen overlay (e.g. background switcher) |
menu |
A summoned menu surface |
service |
A headless singleton, no UI |
bar |
A full bar option that can replace the built-in omarchy.bar |
Only one bar plugin is active at a time. Missing or invalid selections fall
back to the built-in omarchy.bar, so users always have a safe path home.
Panels, overlays, and menus are loaded when summoned. Plugins that need
to outlive a single summon can set keepLoaded: true (e.g. the image
picker keeps its overlay window mounted between summons). The same flag
keeps a service mounted across plugin hot-reload, so tearing down a
changed bar widget cannot destroy omarchy.lock while Hyprland still
holds the session lock. The kept instance is not replaced, so code
changes to a keepLoaded service itself only take effect on a shell
restart. First-party services are loaded at startup.
The full schema lives in services/PluginRegistry.qml.
Installing a third-party plugin
A plugin is a git repo with a manifest.json at its root. Adding one
clones it straight into ~/.config/omarchy/plugins/<id>/ (named by the
manifest id); updating is a fast-forward pull of that checkout.
omarchy plugin add https://github.com/acme/omarchy-weather.git
omarchy plugin update acme.weather # fetches, shows a diff, fast-forwards
omarchy plugin update # updates every git-managed plugin
omarchy plugin remove acme.weather
⚠️ Plugins run as unsandboxed code inside
omarchy-shell. Adding warns you before cloning, plugins land disabled so you can review the code before enabling, and updates show a diff of the changes before touching anything. Only add repos whose code you are willing to run.
Each command is interactive when run bare in a terminal (gum pickers,
confirmation, a diff to review) and fully non-interactive when given
arguments. Pass --yes to skip every prompt — this is the path for scripts and
AI agents:
omarchy plugin add https://github.com/acme/omarchy-weather.git --enable --yes
omarchy plugin update --yes
The installer never runs plugin code, install hooks, or sudo — it only clones files, validates the manifest, and toggles enabled state over shell IPC. Since an installed plugin is a plain git checkout, anything beyond add/update (pinning a ref, switching branches) is ordinary git in the plugin directory.
Installing by hand
You can still drop a plugin in without git:
- Put it in
~/.config/omarchy/plugins/<plugin-id>/with amanifest.jsonplus the QML referenced from itsentryPoints. omarchy-shell shell rescanPlugins.omarchy plugin enable <id>. Bar widgets start inbarWidget.defaultSection, or in the center when it is omitted, and can be moved withomarchy bar move; a full bar replaces the one in use.
The lower-level IPC equivalents remain available via omarchy-shell shell rescanPlugins,
omarchy-shell shell enablePlugin <id> '{}', and omarchy-shell shell listPlugins.
The omarchy plugin commands wrap those calls. omarchy bar move and
omarchy bar set edit the persisted widget layout in shell.json.
To hack on a built-in plugin safely, clone it into user config instead of
editing the built-in source. The complete plugin directory is copied, including
every declared kind and local dependency. A built-in id such as
omarchy.clock becomes <username>.clock (e.g. dhh.clock), with My Clock
as its display name. The username prefix keeps shared clones from colliding
with each other or with other plugin authors.
omarchy plugin clone omarchy.clock
Cloning switches from the built-in to the new personal plugin, preserving an
existing bar widget's position and settings. Setup > Plugins > Clone provides
the interactive picker, then opens the new <username>.* directory in $EDITOR.
Existing shortcuts and shell IPC calls made to the built-in id are routed to
the enabled clone, so cloning does not require changing its callers. Removing
an active clone switches back to its built-in source.
Saving a file anywhere under ~/.config/omarchy/plugins/ reloads plugin code
automatically; omarchy-shell shell rescanPlugins remains available to force a reload.
First-party plugins under shell/plugins/ are discovered the same way and load
by default. Disabling a non-widget records it in disabledPlugins[]; disabling
a widget removes it from the bar layout while leaving its component available
to add again. A full bar has no off state and is replaced by enabling another.
IPC contract
The shell exposes a single shell IPC target plus whatever extra targets
individual plugins register (e.g. the bar's bar target for refresh
hooks, the image picker's image-selector target). omarchy-menu uses the
shell target to summon the first-party omarchy.menu plugin instead of
running a separate Quickshell instance.
| Method | Returns | Effect |
|---|---|---|
ping |
ok |
health check |
summon <id> <payloadJson> |
ok / unknown |
load + open a panel/overlay plugin |
hide <id> |
— | close a previously-summoned plugin |
toggle <id> <payloadJson> |
— | summon if closed, hide if open |
call <id> <method> <arg> |
string | call a method on an already-loaded plugin |
rescanPlugins |
— | re-walk plugin dirs and hot-reload plugin code |
reloadConfig |
ok |
reload ~/.config/omarchy/shell.json |
setPluginEnabled <id> <enabled> |
ok / unknown |
flip the persisted enabled bit (see note) |
listPlugins |
JSON | every discovered plugin, sorted by name |
Direct invocation:
quickshell ipc -p $OMARCHY_PATH/shell call shell ping
Hyprland autostart launches the shell directly with quickshell -p $OMARCHY_PATH/shell. Use omarchy-restart-shell to stop every running
instance of that config and launch one fresh shell process.
A convenience wrapper, omarchy-shell, forwards IPC
calls to the running shell. It does not start the shell.
omarchy-shell shell ping
omarchy-shell shell toggle omarchy.menu '{"menu":"root"}'
omarchy-shell shell listPlugins
omarchy-shell shell rescanPlugins
Note on setPluginEnabled: the enabled argument is a string. Only the
literal "true" enables the plugin; every other value (including "True",
"1", "yes", or omitted) disables it. This keeps the IPC surface
type-stable across QML's string-only IPC arguments.
Persisted state
There is one user config file. Everything that distinguishes your customization from the shipped defaults lives in it.
| Path | Owner | Purpose |
|---|---|---|
~/.config/omarchy/shell.json |
the shell | full layout + per-entry settings + enabled plugin list |
~/.config/omarchy/plugins/<id>/ |
user | drop-in third-party plugin source files |
The config/omarchy/shell.json default config describes the
fresh-install state. When the user has no shell.json, the shell uses
the defaults verbatim. Once the user customizes anything, shell.json
becomes the authoritative file — we do not deep-merge defaults back in.
shell.json shape
{
"version": 1,
"idle": {
"screensaver": 150,
"lock": 300
},
"bar": {
"id": "omarchy.bar",
"position": "top",
"transparent": false,
"centerAnchor": "omarchy.clock",
"layout": {
"left": [ { "id": "omarchy.menu" }, { "id": "omarchy.workspaces" } ],
"center": [ { "id": "omarchy.clock", "format": "HH:mm" } ],
"right": [
{ "id": "omarchy.audio" }
]
}
},
"plugins": []
}
Storage rules
- The active bar option is
bar.id. Omit it or set it toomarchy.barto use the built-in bar. Set it to another plugin id whose manifest declareskind: "bar"to replace the full bar. - Every plugin instance is one entry. Either in
bar.layout.<section>for bar widgets, or inplugins[]for panels, overlays, services, menus, and anything else non-bar. - Settings are inline on the entry. No
config:sub-object, no separate per-plugin settings file, no merge layers. The fields on each entry are the values the plugin sees. - Built-in widget ids are namespaced. Use ids such as
omarchy.clock,omarchy.audio, andomarchy.network. The migration rewrites older ids likeClockandAudioPanelforward. - Third-party enabled ⇔ present. A third-party plugin is enabled iff
its id appears somewhere in shell.json. For full bar options, that means
bar.id; for bar widgets, plugin enable/disable adds/removes layout entries; other plugin kinds are enabled the same way. First-party non-bar plugins are enabled unless listed indisabledPlugins[]. - Multiple instances are allowed when a manifest sets
allowMultiple: true. Each instance is independent — e.g. two clock widgets in different timezones are just two{"id":"omarchy.clock", "timezone": ...}entries with their own values. - Idle timings are top-level.
idle.screensaverandidle.lockare seconds since user idle began, so the default lock fires at 300s even if the 150s screensaver starts first. version: 1is required at the top level. The shell will fall back to defaults rather than load an unknown version.
Implementation history
Built up in phases on this branch:
- Phase 1 —
omarchy-shell phase 1: host the existing bar in a single shell - Phase 2 —
omarchy-shell phase 2: plugin registry and bar widget registry - Phase 3 —
omarchy-shell phase 3: fold bar-settings into the shell as a panel plugin - Phase 4 —
omarchy-shell phase 4: absorb background-switcher as a plugin - Phase 5 —
omarchy-shell phase 5: docs, cleanup, and migration crumbs - Phase 6 —
omarchy-shell phase 6: reviewer cleanup (path traversal, collision, races) - Phase 7 —
omarchy-shell phase 7: replace socket with IpcHandler, rename to image-picker - Phase 8a —
omarchy-shell phase 8a: unified shell.json with inline plugin settings
Shared services and Pipewire/UPower/Hyprland consolidation are explicitly out of scope here and deferred to a follow-up after a review pass.