Open-Source Graphical Shells: Part Three – Wayland, Niche Shells and What's Next

Open-Source Graphical Shells: Part Three – Wayland, Niche Shells and What's Next

Open-Source Graphical Shells: Part Three – Wayland, Niche Shells and What's Next

Part 3 of a three-part series on the graphical shells of the open-source world. 

[Read Part One: Desktop Environments] 

[Read Part Two: Window Managers]

Contents

The Wayland Generation 

Beyond the Mainstream 

Where This Is All Heading 


Parts One and Two of this series covered desktop environments and the window managers that either sit inside them or replace them outright. Both, for the most part, still assume X11 underneath. This final instalment closes the series with the technology actively replacing it — Wayland — alongside a handful of specialist and BSD-native shells worth knowing about, and a look at where open-source graphical shells go from here.


The Wayland Generation

Wayland isn't a desktop environment or a window manager in the traditional sense — it's a protocol, and the software that implements it on the server side is called a compositor, because on Wayland the compositor takes over window management duties that used to be split across a separate X server and window manager. That consolidation is a big part of why Wayland sessions tend to feel snappier and more secure than their X11 equivalents.


Sway was the project that proved this out for the tiling-WM crowd: an i3-compatible compositor that reads existing i3 configuration files with only minor changes, giving i3 users a near drop-in path to Wayland. It's built on wlroots, a modular compositor library that has become the shared foundation for a wide swathe of the smaller projects in this space, precisely so each new compositor doesn't have to reimplement core Wayland plumbing from scratch.


Hyprland, written independently in C++ rather than on wlroots, has become the poster child for Wayland's more expressive side — dynamic tiling combined with genuine visual flair: smooth animations, rounded corners, and blur effects that early Wayland sceptics assumed the protocol couldn't deliver without sacrificing performance. River, written in Zig, and Wayfire, a wlroots-based project explicitly inspired by the old X11 compositor Compiz, both stake out their own niches — River around a scriptable, tag-based tiling model, Wayfire around 3D-style desktop effects without abandoning tiling discipline. Labwc takes the opposite instinct to Hyprland: a deliberately minimal, wlroots-based stacking compositor directly inspired by Openbox, with "no bling" as an explicit design goal — it's become a common choice for lightweight setups, including on devices like the Raspberry Pi. Cage, also wlroots-based, solves a narrower problem well: it's a kiosk compositor that shows exactly one application full-screen and refuses to let the user do anything else, which is exactly what's wanted on a point-of-sale terminal or an information display, and rarely wanted anywhere else. And Weston, developed by the Wayland project itself, remains the reference implementation — the compositor other developers check their own work against, and one that shows up often in embedded and automotive Linux stacks precisely because of that reference status.


Beyond the Mainstream

Not every open-source graphical shell aims at a general desktop audience, and a few are worth knowing about specifically because they solve a narrower problem well — or because they matter more to BSD users than to the Linux mainstream this series has mostly covered so far.


Lumina, created by Ken Moore and developed by iXsystems, is a Qt-and-Fluxbox-based desktop environment built specifically for the BSD world — originally for the now-discontinued TrueOS, though it has since been ported to some Linux distributions too. It's worth a note of honesty here: Lumina's most recent stable release dates back to December 2021, so while it remains a genuine, official, actively documented project, it's not currently seeing the release cadence of the desktops covered in Part One — useful context if you're weighing it for anything beyond a hobbyist BSD box. WindowLab, a minimal X11 window manager with a look loosely inspired by the Amiga's interface, sits in a similar position: real, officially documented, and still installable, but with no stable release since 2010.


On the standalone side, DirectFB offers a lightweight graphics and windowing library that talks directly to the Linux framebuffer without needing a full X server — a common choice in embedded devices and set-top boxes where every megabyte of overhead counts. Mir, Canonical's own display server, is a useful case study in a project changing direction rather than disappearing: originally pitched in 2013 as a wholesale X11 replacement for Ubuntu's desktop and phone ambitions, it's continued development since as a toolkit for building kiosk and embedded Wayland compositors instead, with releases continuing into 2025. And the Enlightenment Foundation Libraries (EFL), mentioned in Part One as the toolkit behind the Enlightenment window manager, remain a fully-fledged, independent application framework in their own right for anyone building lightweight interfaces outside the GTK/Qt duopoly.


A candid note on sourcing, in keeping with how this series has approached every part: a couple of names that appear on some community-compiled lists of "BSD and Unix shells" — including one or two with no verifiable official website at all — have been left out of this section rather than repeated on trust.


Where This Is All Heading

A few trends look set to define the next few years of this ecosystem. Wayland's dominance is accelerating, not slowing — XWayland, the compatibility layer that lets older X11 applications run inside a Wayland session, remains genuinely important, but it's increasingly treated as a bridge rather than a destination, and new compositor projects now default to Wayland-only design from day one. Modularity keeps deepening: wlroots' role as shared infrastructure for Sway, Wayfire, Labwc and Cage alike is a genuinely different development model from the old days of every project reimplementing its own window-management core, and it's speeding up how quickly new, focused compositors can appear. And genuinely new entrants keep showing up — COSMIC in Part One, Hyprland and River here, are proof this isn't a closed club of decades-old projects; the ecosystem is still capable of producing something new that finds a real audience.


The tension that's shaped this whole series — feature-rich convenience versus minimalist control — isn't going away, and there's no reason it should. It's precisely what open licensing was always meant to protect: the freedom for both instincts to keep being built, indefinitely, by whoever wants to build them.


Conclusion

Across three parts, this series has moved from the desktops most people meet on day one, down through the window managers built for people who want to assemble their own, and finally into the compositors actively rewriting how the whole stack talks to the screen. What ties all of it together is the same thread from Part One: because the code is open, nobody has to accept somebody else's idea of the "right" desktop. That's not a minor technical footnote — it's the entire reason this ecosystem has stayed this varied, this long, and it's why there'll be new names in this space worth writing about again before too long.


Disclaimer

All product names, logos, and trademarks mentioned in this article — including Wayland, Sway, wlroots, Hyprland, River, Wayfire, Labwc, Cage, Weston, Lumina, WindowLab, DirectFB, Mir, and the Enlightenment Foundation Libraries (EFL) — are the property of their respective owners and are used here for identification and informational purposes only. The Distrowrite Project strives for accuracy but makes no warranty as to completeness; readers should consult official project sources before making deployment decisions. This article does not endorse or promote any activity involving malware, unauthorised access, or other conduct that could compromise the security or integrity of networks, devices, or infrastructure.


References


3️⃣👨🏻‍💻♨🎓⚛𝐈𝐈𝐈


Comments