Denial: a Wayland compositor with a Flutter shell you can edit live

What Denial solves, and for whom

Most Wayland compositors ask you to express your desktop in a configuration file. Denial takes the opposite position. The README lists settings for layouts, displays, input, shortcuts and appearance, and adds a line that reads like a thesis: "It's a desktop. You should be able to configure it with a mouse." That is the audience. People who want stacking, tiling and scrolling tiling layouts without hand-editing a text file, and who are willing to run beta software to get there.

The second audience is narrower and more interesting. Denial's shell is Flutter code, not a compiled binary you are stuck with. If you have ever wanted to move a panel, change an animation curve or restyle a launcher and have the change appear without restarting your session, that is the feature the project is built around. The README pitches it directly: change a widget, save, and watch your desktop update while your Wayland apps keep running.

It is not aimed at people who want a compositor they never think about. The README is explicit that Denial is in public beta, that it runs on Linux, and that configuration and developer interfaces may change before 1.0. Treat the beta label as a statement about API churn, not about polish.

Rust for the protocol, Dart for everything you see

The split is stated plainly in the README: Rust and Smithay handle Wayland, input and displays. Flutter draws the shell and application windows together. The repository layout matches that description. There is a compositor/ directory, a dart_shell/ directory, a settings_app/ directory, and a protocol/ directory, alongside packaging/, prebuilt/ and third_party/.

So Flutter is not a panel bolted onto someone else's compositor. It is the rendering path for both the shell and the windows, which is why the repository carries an Impeller topic and why the README can claim smooth animations and transitions as a property of the design rather than a patch on top. The compositor owns the protocol work, the Flutter side owns what you look at, and the settings app is a separate entry in the tree rather than a config file with a GUI wrapper.

The practical consequence is that the two halves have different failure modes. A bug in the Rust side looks like a display, input or Xwayland problem. A bug in the Dart side looks like a widget that will not draw. The README mentions Wayland and X11 apps through Xwayland, multiple monitors, screenshots and screen sharing, but it does not document a fallback path when the shell fails to start. The documented recovery is denialctl ui restore, which is described as working even when Settings cannot open. That is a narrower safety net than a text config gives you, and it is worth knowing before you edit anything.

Installing Denial on Arch, Debian, Ubuntu or Fedora

First-party Linux binary packages are currently x86-64. The README points at a repository setup script and asks you to review it before running anything, which is reasonable advice for a curl-to-shell installer. The script shows its plan and asks for confirmation before using sudo.

curl -fsSL https://install.denialwm.org | sh

Once the signed repository is added, install with the command for your distribution. On Arch Linux, CachyOS or Omarchy 4.0:

sudo pacman -Syu denial

On Debian 13 or Ubuntu 24.04 LTS:

sudo apt update && sudo apt install denial

On Fedora 44:

sudo dnf install denial

After installing, choose Denial from your display manager's session menu. That is the whole first run. Alpine Linux 3.24 has signed APK downloads in docs/INSTALL.md. ARM64 builds are supported from source through docs/BUILDING.md, and NixOS and Void Linux have been tested with no first-party binaries yet. The README also notes, without elaborating, that someone got it running on StarryOS's starry-kernel. If you are on ARM64 or a distribution outside that table, you are compiling, and docs/BUILDING.md is the only path the README offers.

Live shell editing and the way back

The development tools are a separate package, and the README says it is available only through the Pacman repository. That is a real constraint: if you are on Debian, Ubuntu or Fedora, the live-editing workflow described here is not offered to you by the documented install path.

sudo pacman -S denial-ui-development
denialctl ui setup

The setup command generates a workspace. Open its dart_shell directory in VSCodium for hot reload on save. The recovery command is the part to remember:

denialctl ui restore

The README states that this gets you back to the packaged shell even when Settings cannot open. That phrasing tells you the authors expect the failure mode where a bad edit takes the settings UI down with it. If you are going to edit the shell, run the restore command once before you start, so you know it works on your machine rather than discovering it later. The README does not describe what hot reload does when a widget throws during build, and it does not document rollback beyond the restore command.

Where Denial is the wrong tool

The beta label is the first limitation and the README states it without hedging: configuration and developer interfaces may change before 1.0. If you maintain machines for other people, that sentence is the whole review. A compositor whose configuration format is still moving is a poor fit for a fleet.

The second limitation is the packaging gap. First-party binaries are x86-64 only. The live-development package is Pacman only. If you run Debian, Ubuntu or Fedora and your interest in Denial is specifically the editable shell, the documented path does not include you yet. You can still install the compositor, but the feature that makes Denial different is out of reach through the instructions the README gives.

The third is that a Flutter shell is a large surface. The README lists glass effects, blur, light and dark themes, accent colors, workspaces, touchpad gestures and three layouts, all rendered through Flutter. More moving parts means more places for a rendering problem to appear, and the README does not describe a minimal mode that turns the shell down to something plain when something goes wrong. Subtlety, it says, is available in Settings. That is an aesthetic control, not a recovery mode.

Hyprland and niri, and what the difference actually is

The README addresses this directly with a line aimed at people already running something else: "Hyprland and niri users are welcome. We won't tell." Both are Wayland compositors with tiling layouts and configuration files, and both have users who care about animation quality.

The difference is where the desktop lives. Hyprland and niri express their behaviour through configuration, and changing the look of a bar or launcher means changing a config value or swapping in a separate program. Denial puts the shell in Flutter source. That is not a better or worse answer in the abstract. It is a different answer. If you want to restyle a launcher by editing a widget and watching it update while your applications keep running, Denial is built for that and the others are not. If you want your desktop defined by a file you can copy between machines and version in git, the configuration model is the more predictable one, and Denial's beta warning about changing interfaces makes that predictability worth more, not less.

The same trade-off applies to the settings app. A GUI for layouts, displays, input, shortcuts and appearance lowers the barrier to a first working desktop. It also means the state you care about is not a file you can diff, which makes the restore command the thing you rely on instead.

Licence, maintenance and upgrade cost

The repository's LICENSE badge says GPL-3.0-or-later, and the repository carries both a LICENSE file and a LICENSES/ directory. The licence field reported for the repository itself is NOASSERTION, which is a statement about how the metadata is filled in rather than about the terms. Read LICENSE and the LICENSES/ directory before you build anything you intend to distribute, and get your own advice if the answer matters. Nothing here is legal advice.

The maintenance picture is straightforward. The repository is not archived, and the last push was on 2026-09-16. Releases v0.4.0, v0.4.1 and v0.4.2 all landed between 2026-09-13 and 2026-09-16, which is a tight cadence. Upgrade cost is where the beta warning bites. The README says configuration and developer interfaces may change before 1.0, so a minor version bump can move something you depend on. If you edit the shell, keep your changes in the generated workspace and expect to reapply them after an upgrade, because the documented recovery path is restoring the packaged shell, not merging your edits forward. The CHANGELOG.md at the repository root is the place to read before upgrading, and the README does not describe an upgrade procedure beyond the distribution's own package manager.

Editorial conclusion

Denial is worth installing if you run Arch, CachyOS, Omarchy 4.0, Debian 13, Ubuntu 24.04 LTS or Fedora 44 on x86-64, and you want a compositor whose shell is Flutter code you can change while your Wayland apps keep running. It is the wrong choice if you want a stable desktop today: the README calls it a public beta and warns that configuration and developer interfaces may change before 1.0. It is also not the tool for ARM64 users who need first-party binaries, since those builds are supported from source only. Before you commit, read install.sh, check that denial-ui-development is present in your Pacman repository if you want live editing, and confirm that denialctl ui restore works on your machine, because that command is the documented way back to the packaged shell when an edit leaves Settings unable to open.

Frequently asked questions

Official sources

1. denialwm/denial on GitHub
2. Issues
3. Project website
4. README
5. Releases