Omarchist gives Omarchy users a window instead of a config file

An add-on for one distribution, not a general desktop configurator

Omarchist is a GUI app for Omarchy, written in Rust, and the README is explicit about the scope. It works only on Omarchy Linux, and version 2.x targets Omarchy Quattro, which is version 4, while Omarchy 3.x users need an Omarchist 1.x release. That is the first filter for anyone considering it. Omarchy itself is a Linux configuration built around Hyprland, and Omarchist's job is to put that configuration into a window: design themes, tune Hyprland, change keybinds and chain actions into flows, without editing config files by hand. The README calls it an optional add-on, and that framing is accurate. It is not a desktop settings panel, and it is not trying to be a general Hyprland configuration front end for every distribution. The audience is an Omarchy user who likes the distribution and wants a visual path to the parts of it that normally mean editing Lua and TOML by hand.

It writes its own config and adds one line to yours

The design decision that makes the add-on safe to use is how it touches your configuration. The configuration page covers gaps, borders, blur, keyboard, mouse and touchpad, applied as you change them, and Omarchist writes its values to ~/.config/hypr/omarchist.lua. It only adds the one line to your hyprland.lua that loads it. So the file you edit is the file the app owns, and your compositor configuration is touched by exactly one line. The same pattern appears in the theme designer. You create a theme from scratch or from an image, Omarchist writes colors.toml, and Omarchy generates your terminals, borders, bar and editor themes from it. The app is not a theme previewer, it is a generator of the file Omarchy already reads. The repository layout backs the picture up, with defaults/ holding default content, ui_themes/ holding the app's own light and dark looks, assets/ for images, and src/ and tests/ for the Rust code.

The keybind editor never touches your bindings file

Keybinds get their own page, and it is the part of the app with the most careful wording. You search and change every Hyprland keybind on your system, and you can record a combination the way you would in an editor, or type it in Omarchy's syntax for keys the compositor keeps to itself. The important sentence is the last one in that section: your bindings.lua is never touched. That is a meaningful boundary, because the file that defines your own keybinds is the one most likely to contain a shortcut you rely on and would hate to have rewritten by a GUI. The distinction from the configuration page is worth noticing. The configuration page writes Omarchist's own file and adds a loader line, while the keybind page edits the system's keybinds directly, and it does so without claiming ownership of the file that holds them. The repository also carries a gpui-component dependency with the tree-sitter-lua feature enabled, which is the parsing side of that editing.

Flows are the scripting surface, triggered six ways

Flows are the feature that goes beyond settings, and the README compares them to Shortcuts on a Mac. A flow strings actions together: it can open apps, change settings, ask you something, pass what one step produced to the next, decide with If, and repeat. The triggering options are wide, and that is the point of the design. A flow runs from a keybind, from the app launcher, from the Files menu, at startup, or anywhere with the command line entry omarchist flow run <name>, and an automation can start one at a time, when an app opens, or when the charger is unplugged. That last trigger is the clearest statement of intent, since the app is a general automation surface for the machine rather than only a settings form. Flows can also be shared, either from a template or from the Catalog where people share flows that reviewers have read, and installing one shows you every step before anything is saved, which is a sensible default for code that will run on your machine.

Keyboard first, and a UI built on Zed's gpui

The interface commitment is that every page, dialog and control works without a mouse, with Ctrl+/ listing every shortcut and Ctrl+Shift+P opening a command palette. For a Hyprland-centric distribution where the keyboard is the primary input, that is a reasonable requirement rather than a flourish, and the keybind recorder described earlier follows the same idea by letting you press the combination you want instead of picking from a list. The toolkit behind the interface comes from Zed. The acknowledgements credit zed-industries for gpui and Huacnlee for gpui-kit, and the Cargo manifest makes the dependency unusual in a way worth flagging. The gpui crates are pinned to exact versions, because gpui-pre is a weekly snapshot of Zed's unstable gpui and every gpui crate is bumped together, and the gpui-platform dependency is enabled with both wayland and x11 features. A weekly upstream snapshot pinned exactly means reproducible builds now and a coordinated upgrade later.

Installing from the AUR, and where the version boundary sits

Installation is a single command on an Arch based system:

yay -S omarchist-bin

That is the whole install instruction, which is unsurprising for a distribution specific binary package. The note that follows is the part to read before running it. Omarchist only works on Omarchy Linux, version 2.x targets Omarchy Quattro, and for Omarchy 3.x you should use an Omarchist 1.x release. If you are on the older Omarchy line, installing the current package is the wrong move. The documentation lives at omarchist.com. The build for a developer is a Cargo project with a justfile for the common tasks, where the run target uses a fast-compiling dev-fast profile, the build target is a release build, and the release target checks and tests first, refuses to continue if the working tree is dirty, and then tags and pushes a version read from Cargo.toml. The project version in Cargo.toml reads 2.2.0, with releases v2.2.0, v2.1.0 and v2.0.0 published in October 2026, and the last push was on 2026-10-17.

Where an add-on like this stops

The limits are structural rather than incidental, and they are visible in the design. First, the platform lock is absolute. The project states it only works on Omarchy, so it is not an option for a Hyprland user on another distribution, and even within Hyprland the Omarchy conventions it depends on are the ones Omarchy provides. Second, the keybind page is a convenient editor rather than a validator. It can record a combination or accept Omarchy syntax for keys the compositor reserves, but the README does not claim it checks a binding against the ones already in use, so a clash is something you find at runtime. Third, the flows feature is the most powerful and the least documented part, with the details split between the README, the site documentation and the shared Catalog, and the Catalog introduces the trust question that any catalogue of user shared automation introduces even with a review step. Fourth, the dependency on a weekly gpui snapshot means the app tracks an unstable upstream, and the pinned exact versions are what keep a build working while that upstream moves.

Editorial conclusion

Adopt Omarchist if you run Omarchy Quattro and want to design a theme, adjust Hyprland settings, remap keybinds or script routine tasks without editing config files by hand. Do not adopt it on any other Linux distribution, since the project states it only works on Omarchy, and do not use it on Omarchy 3.x, which needs an Omarchist 1.x release. Verify first that your Omarchy version matches the 2.x line, that the keybind editor leaves your own bindings file untouched as documented, and that you understand the install step it adds to hyprland.lua, since that is the point where an add-on becomes part of your compositor startup.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tahayvr/omarchist on GitHub