Mango Wayland Compositor: dwl With Tags, Animations and Scenefx Effects

What Mango Adds on Top of dwl

Mango is a Wayland compositor built on dwl, which itself sits on wlroots. The README states the project "starts where dwl ends": it keeps the lightweight, fast-build philosophy and adds features the author considers necessary for daily use. The target user is someone who already likes dwl's model, a small C codebase configured by editing source and rebuilding, but wants more window management and visual polish than dwl ships with.

The feature list is the substance here. Tags instead of workspaces, where each tag keeps its own independent window layout. Layouts including scroller, master-stack, monocle, dwindle and grid. Window states including swallow, minimize, maximize, global, overlay and fakefullscreen. Window effects (blur, shadow, corner radius, opacity) delivered through scenefx. A Sway-like named scratchpad. An overview mode the README compares to Hycov. IPC so external programs can send and receive messages. Hot-reload of configuration, so keybinding changes do not require a restart.

The XWayland claim deserves attention because it is specific: the README says Mango supports scale without blurring. Blurry scaled X11 clients are a common complaint on Wayland, so if that claim holds in practice it is one of the stronger reasons to pick Mango over a plainer dwl build. I cannot verify it from the README alone, and the documentation does not quantify it.

Architecture: dwl, wlroots and scenefx

The repository layout tells you most of what you need to know before reading any prose. The top level contains meson.build and meson_options.txt, so the build system is Meson, not a hand-written Makefile. There is a src/ directory for the compositor code, include/ for headers, protocols/ for protocol definitions, and mmsg/ for the IPC message tooling. A flake.nix plus flake.lock and a nix/ directory mean Nix users get a supported path. There is also mangowm.scm, a Guix package definition, and format.sh with .clang-format and .clangd for the C tooling.

The dependency chain is stated in the acknowledgements. wlroots provides the Wayland protocol implementation. dwl is the foundation. scenefx is the window effects library behind blur, shadow, corner radius and opacity. owl provided animation groundwork, and sway is cited as a protocol reference.

That layering has a practical consequence. Mango inherits wlroots' backend behaviour and its protocol coverage, and it inherits dwl's tiling model. Anything wlroots does not implement, Mango does not implement either. The project's own scope statement in the README supports this: features are added when they improve daily workflows, and niche requests are evaluated by community interest rather than by completeness against other compositors.

Installing Mango on Arch Linux and Starting It

The README gives one concrete install command, for Arch Linux, using the AUR helper yay. It installs the git package, so you are tracking the main branch rather than a tagged release.

yay -S mangowm-git

For every other distribution the README does not list a command. It points to the Installation Guide at mangowm.github.io/docs/installation, which the README says covers Fedora, Gentoo, Guix, NixOS, openSUSE, PikaOS, AerynOS, and building from source. The repository also ships flake.nix and mangowm.scm, which are consistent with the NixOS and Guix entries on that page.

The README also offers a ready-made configuration from the maintainer, cloned into the standard config directory. This is optional, and it pulls in a large dependency set.

git clone https://github.com/DreamMaoMao/mango-config.git ~/.config/mango

If you take that route, the README lists the packages the config expects, including rofi, foot, xdg-desktop-portal-wlr, swaybg, waybar, wl-clip-persist, cliphist, wl-clipboard, wlsunset, xfce-polkit, swaync, pamixer, wlr-dpms, swayidle, brightnessctl, swayosd, wlr-randr, grim, slurp, satty, wlogout and sox, installed through the same yay command. That is a full desktop stack, not a minimal compositor install, and it is the fastest way to see what Mango is supposed to look like on a real machine. What you see after starting it should be the default tag layout with the bar and launcher from that config; the README does not describe a first-run experience beyond this.

Where Mango Is the Wrong Choice

The README's vision section is honest about the project's stage: stability first, after months of testing, with the claim that breaking changes will be minimal. "Minimal" is not "none", and the release history bears that out. Versions 0.17.1, 0.17.2 and 0.17.3 all landed between 2026-09-15 and 2026-09-22, three patch releases in eight days. That cadence suggests active bug fixing rather than a frozen interface. If you need a configuration format you can write once and forget for a year, this is not that compositor yet.

The documentation split is a second problem. The README covers installation on Arch and links out for everything else. Configuration reference, keybindings, layouts and IPC are on the website, and the GitHub Wiki is explicitly community-maintained, which means its accuracy is not guaranteed by the project. The README does not document rollback, downgrade or migration between versions. If a 0.17.x update changes behaviour you depend on, the README gives you no procedure.

There is also a scope limit. The README says niche requests are evaluated by community interest and that significant upvotes move things forward. That is a reasonable policy, but it means a feature you need that few others need may never arrive. If your workflow depends on a specific protocol or effect that Mango does not implement, waiting is not a plan.

Mango Compared with Sway and Hyprland

The closest comparison the README itself invites is Sway, and it is a comparison of configuration model rather than features. Sway uses a runtime configuration file and a command interface; you edit a text file, reload, and never rebuild. Mango follows dwl: the compositor is a C program you configure and compile, with hot-reload covering keybinding changes specifically. The README's mention of "Sway-like scratchpad" and "Hycov-style overview" makes the borrowing explicit. If you want a compositor where configuration is code and the build is part of your setup, Mango is the dwl lineage. If you want to change a keybind without a compiler, Sway is the other lineage.

Against Hyprland, the difference is the foundation. Hyprland is its own compositor with its own configuration language and animation system. Mango builds on dwl and wlroots and takes its effects from scenefx. The practical difference is dependency surface and how much of the stack you can reason about: Mango's acknowledgements section names every upstream it relies on, and each of those is a project you can read independently.

Against plain dwl, the difference is everything in the feature list. Tags with independent per-tag layouts, animations, the six window states, scenefx effects, IPC and the overview mode are the delta. If you do not want any of those, dwl is smaller and has fewer moving parts.

Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-23. The most recent release is 0.17.3, published on 2026-09-22, one day before that push. On the evidence of the release dates, this is a project under current development, and the README's stated policy is that breaking changes will be minimal rather than absent.

Upgrade cost depends on how you installed it. The Arch package in the README is mangowm-git, which tracks the git repository rather than a tagged release, so an upgrade pulls whatever is on main at that moment. If you want to follow tagged releases instead, the README does not give a command for that, and the Installation Guide is the place to check. Because configuration in the dwl model lives close to the source, an upgrade can require merging your local changes against upstream, and the README does not describe a strategy for that.

On licensing, the README displays a GPL-3.0 badge linking to the LICENSE file, while the repository metadata reports the license as NOASSERTION. Those two signals disagree, so read the LICENSE file yourself rather than trusting either the badge or the metadata. If you redistribute Mango or a modified build, the terms of whatever that file says apply to you. This is not legal advice, and the project does not offer any.

Editorial conclusion

Adopt Mango if you already run dwl or another wlroots tiling compositor, want tags rather than workspaces, and are willing to read the website docs at mangowm.github.io because the README alone does not document configuration. Do not adopt it if you need a stable configuration schema, a documented rollback path, or a compositor with a long release history you can audit. Before installing, check the Installation Guide page for your distribution, confirm the GPL-3.0 badge against the LICENSE file in the repository, and decide whether you are prepared to track 0.17.x releases, which shipped three times in the week before 2026-09-22.

Frequently asked questions

Official sources

1. Issues
2. mangowm/mango on GitHub
3. Project website
4. README
5. Releases