aether: wallpaper driven theming for Omarchy and any Linux desktop

One wallpaper, every application

Aether is a visual theming application for Omarchy, and its stated job is to extract colours from wallpapers and apply cohesive themes across your entire desktop.

The idea is straightforward and it is the sort of thing that sounds trivial until you try it. A Linux desktop is a dozen applications with a dozen configuration files, each with its own colour syntax, and a user who wants them to match has to open each one. Aether takes the wallpaper instead, derives a palette from it, and writes that palette into all of them.

The first thing to know is that the Omarchy part is optional. The README says that if you are not using Omarchy, Aether works standalone on any Linux desktop, with a separate guide for that case. Omarchy is the opinionated desktop distribution the tool is designed for, and the deep integration, the shell plugins, the update command, is what the Omarchy path adds, but the core is a general Linux theming application.

The project is written in Go with a Wails desktop shell, and the licence is MIT, with the README crediting the author by name. The repository licence field is recorded as unknown, which is a small thing to confirm in the file. The last push was on 2026-10-04, the releases are v4.32.0 from that day, v4.31.1 from 2026-09-29, and v4.31.0 from the same morning, and the homepage is the Omarchy site.

The repository layout shows the structure of the application. There is the main entry point, a set of files at the root for the application object, the dialogs, the templates, the external import handling, and the default wallpapers, plus a cli directory, an internal directory, an ipc directory for the remote control, a frontend directory, a templates directory, and a contrib directory for the Omarchy shell plugins.

Median cut, eight modes, twelve sliders

The colour extraction is the part that has to be good, because everything downstream depends on it, and the implementation is deliberately simple.

It is a pure Go median cut algorithm that generates a full sixteen colour ANSI palette from any wallpaper. Sixteen, because that is the size of the ANSI palette, which is what terminal applications actually consume, so a palette designed for a terminal is one that also works for the bars and the editors.

There are eight extraction modes, and the names describe the kind of palette each produces. Normal, Monochromatic, Analogous, Pastel, Material, Colorful, Muted, and Bright. Monochromatic and Analogous are variations on hue relationship, Pastel and Muted are saturation and lightness choices, and Material and Colorful are the two poles of a set that looks like a design system rather than a screenshot of a photograph.

On top of that there are twelve fine tuning sliders, with vibrance, contrast, temperature, shadows, and highlights named among them, and a light and dark mode toggle with automatic colour anchor swapping. The anchor swapping is the part worth understanding, because a palette that works on a dark background usually has a different set of usable accent colours than the same palette on a light one, and an automatic swap that reassigns the accents accordingly is a better answer than asking the user to do it by hand.

There is also a WCAG contrast ratio checker with AAA and AA accessibility grading, which is the check that matters most for a generated palette, because a wallpaper derived palette will happily produce a text colour that fails contrast against its own background, and the checker is how you find that before the text is unreadable on a panel.

Wallpapers: search, edit, and export

The wallpaper tools are more than a file picker, and they are what makes the application usable as a daily tool rather than a one off.

You can search and download wallpapers from wallhaven.cc directly in the app, and you can browse public GitHub repositories for wallpapers, which covers the case where the wallpaper you want lives in somebody's dotfiles repository. You can export your favourite wallpapers as a ZIP archive with the source metadata included, so the archive tells you where each image came from.

There is a blurred wallpaper variant that you can apply while the extraction still uses the original image, which is a nice piece of thinking, because the blurred version is usually better as a desktop background and the sharp original is better as the source of a palette.

The editor itself covers blur, exposure, sharpen, vignette, grain, and colour toning, and there are twelve one click image presets, with Cinematic, Vintage, Film, and Dramatic named. The presets are for the image, not for the palette, which is a useful distinction, because the image treatment and the colour derivation are separate steps and you often want one without the other.

On the colour side, the extras list also includes a gradient generator and a single colour palette builder, which is the way to make a theme that matches one specific colour in a wallpaper rather than the whole image.

There is a fifty step undo and redo history, which tells you something about the intended workflow. Applying a theme is a sequence of small decisions, the palette extraction, then the adjustments, then the per application tweaks, and the history is what lets you back out of the last one without starting again.

The theme library, Base16, and blueprints

A theme in this project is a bundle, and the library section is about where those bundles come from.

There are twenty four built in colour presets, with Dracula, Nord, Gruvbox, Catppuccin, and Sakura named. You can import more than two hundred and fifty community Base16 colour schemes, which is the largest single source of themes in the desktop world, and the import is a first class feature rather than a conversion script.

You can save and restore complete themes as blueprint files, which is how a theme becomes something you can move between machines, and you can export themes as shareable packages with selective app inclusion, so a package can contain the applications you actually use rather than all twenty of them.

The icon handling has its own small design story, and it is a good example of a tool being careful about a destructive operation. You can keep the palette matched Yaru icon default, or choose an installed desktop icon theme per blueprint. The automatic option preserves Aether's colour matched Yaru output, while an explicit choice writes the installed theme's directory ID. If that theme is later uninstalled, Aether keeps the saved ID and marks it as missing, rather than silently replacing it. And disabling the icons target omits the icons theme setting without erasing the choice.

The picker searches the standard user and system XDG icon roots and the legacy icons root in the home directory, and there is a refresh action that rescans after you install a theme. Aether does not download or install icon themes itself, which is a deliberate boundary: the application reads what is on the system rather than becoming a package manager for it.

Twenty applications and a template system

The application support is the substance of the tool, because a theme that only reaches the terminal is not a desktop theme.

There are twenty or more pre-configured applications, with Hyprland, Waybar, Kitty, Alacritty, Ghostty, Neovim, VS Code, Zed, and btop named. That list is a good description of what a modern Wayland desktop is made of, and it covers the compositor, the panel, the terminals, the editors, and a system monitor.

The templates are the extension mechanism, and they are deliberately simple. The template system supports hex, RGB, RGBA, and stripped format modifiers, so one template can produce the different shapes a given application expects, and a stripped modifier produces a colour with no alpha, which several applications need and most templating systems forget about.

There are per application overrides, reload hooks, and post apply scripts. The reload hook is what makes the change visible without restarting each application, and the post apply script is the escape hatch for the application that needs a command run after its configuration is written, which is how a theme system stays useful for programs that do not reload on their own.

And you can add your own applications with custom templates, with two separate documentation guides covering the template system and the custom app support.

The extras round out the feature list with the accessibility contrast checker, the gradient generator, the undo history, and a headless CLI for scripting, keybinds, and automation.

The CLI, the protocol handler, and remote control

A theming tool that can only be driven by clicking is a tool you use once. Aether is built for scripting as well.

The CLI has three commands in the README, and the full set is behind the help flag.

aether --generate ~/wallpaper.jpg
aether --apply-blueprint "My Theme"
aether --list-blueprints

Generating a palette from an image without opening a window, applying a saved blueprint by name, and listing the blueprints you have are the three operations that matter for automation, and they are the ones a script or a keybind would use.

There is also a protocol handler. The repository contains a desktop entry for the aether scheme, and the documentation has a guide for registering those links, which is what lets a web page or another application hand a theme to Aether.

The remote control guide is the one with the most interesting implications, because it covers IPC commands and AI integration. Aether has an ipc directory in the source tree, and a desktop application with a local control channel can be driven by an assistant, which is the same idea as the MCP server in other projects in this space.

One behaviour is worth knowing before you install it, and it comes from the package management section. When pacman owns the aether binary, Aether does not check for releases or upgrade itself. The upgrade command prints the update command instead, which is one of the Omarchy update command, yay with a system upgrade, paru with a system upgrade, or a direct pacman system upgrade.

That is a deliberate design decision rather than a missing feature, and it is extensible. You can give the update command at build time, which is how the same binary behaves correctly on a distribution with a different package manager.

wails build -tags webkit2_41 -ldflags "-X 'aether/internal/update.packageUpdateCommand=sudo dnf upgrade aether'"

The stack, the build, and how the tests avoid your desktop

The build is a Wails application, which means a Go backend with a web frontend in a native window, and the dependencies reflect that. The Go module is named aether, requires Go 1.25, and depends on the godbus D-Bus library, the Wails framework, and the extended image library from the Go project. There is a large indirect list behind them, which is the usual cost of a webview shell.

The frontend is a separate package with its own tooling, and the lint staging configuration shows how the two languages are handled. The frontend files, TypeScript, JavaScript, Svelte, CSS, and HTML, are formatted with Prettier, including the Svelte and Tailwind plugins, and the Go files are formatted with gofmt. The commit hook is husky with lint staged, and the Prettier configuration itself lives in the root package.

The prerequisites for development are Go 1.25 or newer, Node 22.22.2 or newer or 24.15 or newer LTS, Wails v2, webkit2gtk, gtk-layer-shell, gstreamer, and the good gstreamer plugins. The Makefile handles the WebKit version difference by asking pkg-config whether webkit2gtk 4.0 exists and falling back to the newer build tag when it does not, which is the sort of detail that would otherwise break the build on an older distribution.

The testing arrangement is the part I would point at first. Make test runs the Go package tests, and with the native build dependencies installed, the race detector run over the whole module also covers the application entry points, with the tag omitted on WebKitGTK 4.0 systems. On the frontend, the commands are the install, check, test, and build steps, and the important detail is that the frontend regression suite uses mocked Wails calls, so it does not change your desktop. A theme application that rewrote your configuration during a test run would be a terrible test suite, and this one is careful about it. For manual verification of the native dialogs, the rendering, and the theme application itself, there is a separate make dev target.

The documentation set is unusually complete for a project of this size, with eighteen guides covering installation, the CLI reference, how the colour extraction algorithm works, Base16 import, the wallpaper editor, the two wallpaper sources, favourites, blueprints, custom templates and apps, the file system layout, remote control, the protocol handler, the Omarchy shell plugins, the standalone setup, and troubleshooting.

Editorial conclusion

Aether fits a Linux desktop user who wants their applications, bars, and terminal to match one wallpaper without hand editing a dozen configuration files, and who is happy to let a generated palette drive the result. It does not fit a user who needs pixel level control of a theme, since the palette is generated and then adjusted with sliders rather than specified, and it does not fit a machine without the native webkit and gtk stack it is built on. Verify first that the applications you actually use have a template, that the extracted palette passes the contrast checker for the text you intend to put on it, and that you have read the package management behaviour, because on a pacman managed system the tool deliberately refuses to upgrade itself and only prints the command to run.

Frequently asked questions

Official sources

1. Issues
2. omacom/aether on GitHub
3. Project website
4. README
5. Releases