While the two major open source desktop environments get most of the airtime – and for good reason, since they’re both exceptionally good – there’s a long tail of other desktop environments out there catering to all kinds of special workflows and weird niches. I think we can all agree that Xfce leads this long tail of more niche desktop environments, without really being niche itself. Xfce may not be as popular as KDE or GNOME, but it’s an amazing full-featured desktop environment that offers a slightly more traditional, less fast-paced desktop for those that desire so.
Xfce, too, is moving to Wayland, which can mean significant efforts in certain places, not the least of which is the window manager. Xfce originally planned to adapt its venerable xfwm4 to support both X11 and Wayland at the same time, but this turned out to be too complex for a variety of reasons, all more or less caused by differences between X11 and Wayland. On top of that, this approach would risk introducing new bugs to the X11 side of things, and the Xfce project does not want to subject its X11 users to that.
As such, they’ve decided to develop a Wayland compositor from scratch: xfwl4.
The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does, or as much as possible considering the differences between X11 and Wayland. Using xfwl4 should feel just like using xfwm4 on X11. We even plan to reuse the existing xfwm4 configuration dialogs and xfconf settings to ensure a seamless transition.
Xfwl4 will not be based on the existing xfwm4 code. Instead, it will be written from scratch in rust, using smithay building blocks.
↫ The Xfce development team
This project also includes related tasks like rearchitecting session-startup to support Wayland, implementing support for the xdg-session-management protocol, and adding support for XWayland. This is obviously anything but a small effort, but it seems like a practical solution. Xfce users generally seem to choose Xfce exactly because it’s a stable environment that does not move fast(er) and break (some) things. As such, keeping the X11 window manager separate and stable, without Wayland work possibly breaking it, seems like the kind of thing the average Xfce user can get behind.
Personally, I can’t wait for Xfce to become a full Wayland desktop, as dealing with X11’s nonsense feels decidedly retro to me now, and I don’t see Xfce as a retro environment at all. It’s going to take some time, of course, but thanks to countless generous donations to Xfce, longtime Xfce core developer Brian Tarricone will be paid to work on this project. Excellent news for everyone involved.
You can already run XFCE on Wayland using another compositor like LabWC and some distros ship it this way. Budgie decided to go Wayland-only without making their own compositor. But I think it makes sense for a desktop environment to define its own compositor behaviour and so it is great to see XFCE taking this on
The work it takes to write a Wayland compositor is dropping as the support libraries mature. Given that this will be the work of primarily one person, expecting a dev release in a few months is not too bad (mid-year is only 5 months from now). Smithay is the same foundation used for COSMIC and Niri so it will continue to improve though it already supports most protocols as the article says.
This is starting to show the benefits of the Wayland architecture in my view. XFCE has multiple Wayland frameworks to choose from and was able to pick the one with the features and language support they liked best. There are already smithay, wlroots, aquamarine, louvre, mutter, kwin, swc, and others. There will be more and writing a compositor is only going to get easier.
The part that seems like a waste of time for compositors these days is direct Xwayland support. Not because support for X11 apps is not important but because solutions like xwayland-satellite work so well.
https://github.com/Supreeeme/xwayland-satellite
But now that XFCE is going to end up with both xfwm4 and xfwl4 they are going to face the same dilemma as Budgie, GNOME, and KDE did. Do they maintain them both long term? Or will this lead to xfwm4 going away? I hope that xfwm4 sticks around.
I’m glad they are approaching this with caution and being mindful of X11 holdouts who, for various reasons, can’t make the move to Wayland yet. If it’s not obvious, I’m one of those holdouts. I know that Wayland is the future of desktop Linux, but I don’t just run Linux on the desktop, I also use FreeBSD and OpenBSD where Wayland won’t be a real solution any time soon. Also, while a lot of progress has been made with remote desktop use under Wayland, it’s still not 100% there and so I’m forced to continue to use X11 for real work.
I’m happy to wait for it to mature enough to be usable daily and do what X11 does for me now: just work and stay out of the way. That’s how all desktop components should be in my opinion, just do your damn job and don’t let me know you exist (by crashing or otherwise misbehaving).
Morgan,
I think XFCE’s position of keeping things stable and not jumping on bandwagons and breaking things willy nilly is kind of a rare quality in tech and I respect them for it too. Constant change and “innovation” seems to be the common refrain whether that benefits users or not. And I agree with XFCE that writing their own wayland compositor to be compatible with their old window manager is the best way forward without compromising the stability the project is known for. On the one hand I don’t like that we need so many wayland compositors because this obviously causes fragmentation, which is bad for users, and duplication of work, which is bad for developers. Here XFCE are introducing yet another one. But on the other hand it shouldn’t be held against XFCE IMHO. This outcome was set in motion by wayland’s project management years ago and their refusal to address common requirements and design issues sooner set wayland on a course that made future fragmentation inevitable. Ironically despite wayland’s status as the new standard, I suspect there could be a long term desire for a new unifying approach post-wayland to fix these unfortunate code duplication issues. Maybe this will happen in the 2030s, haha.
Edit: I feel that I need to clarify that it’s not my opinion that we should stick to X11 forever…it’s an ancient code base with it’s own problems. But I do wish we would learn how to roll out new FOSS projects better.
@Alfman
> XFCE’s position of keeping things stable
I have also liked XFCE’s approach. Cinnamon has also been very slow-and-steady with Wayland. MATE is about where XFCE was before announcing xfwl4. And I think even KDE has been pretty measured with regards to the Wayland transition given the pace with which they innovate generally.
> desire for a new unifying approach post-wayland to fix these unfortunate code duplication issues
I sure hope not. I do not want a single Wayland engine any more than I want a single web browser or a single SQL database. Competition between implementations is vastly superior in the long run in my view and serves both users and developers far better. Already, XFCE was able to choose a Wayland support library that supports the features and language ecosystem they want. There was no Rust implementation of Xorg for Brian to choose. That may not be your preference but it was his.
And the duplication is not in the compositors but in the support libraries. There are already dozens of Wayland compositors, just as there were hundreds of X11 window managers, but there are only a half-dozen Wayland support libraries or “engines”. Outside of KDE and GNOME, almost all the other Wayland compositors are built on one of just two: wlroots or smithay.
I suspect at some point we will see a Wayland compositor that acts like a “display server” only in that it bakes in the Wayland compositor, XDG-desktop-portal, XDG-session, XWayland, etc but does not dictate window management. Instead, it will provide a runtime interface to run a “window manager” on top, much like the relationship between X11 window managers and the X server.
You may prefer such an architecture. I will be happy if there are still other Wayland engines as well.
> Maybe this will happen in the 2030s
My hope for the 2030s is that Wayland is still going strong and will be meeting the needs of desktop users well. Various Wayland implementations may have come and gone but we have not had to throw out the ecosystem and start over because it had failed to keep up.
> X11 is an ancient code base with it’s own problems
The way to combat this is precisely with multiple implementations. They will compete. They will innovate at the edge and drive each other forward. If an implementation does fall behind, it will be replaced without getting to the point where the entire ecosystem stops being viable. Again, I look the world of web browsers. There have been multiple web browsers engines that have achieved dominant market share only to be replaced by something better (Mosaic, Netscape, Internet Explorer, Firefox, Chrome). It has been messy and there have been annoying incompatibilities at the margin but at no point did we have to throw away the ecosystem and start over. And we will probably not have to as long as we have different implementations pushing for supremacy. Maybe one of the new challengers will topple Chrome (Chromium/Blink).
In the same way, wlroots may fade away and be replaced by something better. We are seeing that happen in real-time maybe. And I see it as a good thing.
LeFantome,
I don’t mind users having a choice between implementations, but wayland doesn’t really buy us that after we’ve decided upon a desktop. I’ll use a battery analogy….
Each manufacture has their own competing battery implementation: Ryobi, Bauer, Milwaukee, Dewalt, Ridged, Makita, Bosch, etc. Obviously they’re all reinventing almost the same wheel. Ostensibly this competition is good. However this comes with some major caveats for the consumer. It is nice to have “battery competition”, but the fact that each battery comes with a proprietary interface significantly impedes the freedom to choose implementations independently from the tools being used.
It’s not that I disagree with you about the merits of competition, but I think manufacturers competing within robust interoperability standards could serve consumers even better. This way consumers would have the freedom to select the most competitive tool and battery without one choice being hamstrung by the other. Wayland compositors are in the same boat. When wayland was on the drawing board, a lot could have been done to avoid fracturing so it didn’t have to be this way. I wish wayland had handled this better, but because they did not fragmentation will be part of wayland for the foreseeable future.
It’s not the same though. Those X11 window managers could support X11 features out of the box without each needing to reimpliment those features. Things like screencasting and network transparency just worked regardless of your choice of desktop. Obviously X11 was never perfect, but this was a huge perk. For better or worse wayland pushes us towards new fragmentation problems that X11 didn’t have.
Yes, that’s likely to be the case. And I hope it comes to the point where everything can just work regardless of the desktop you choose, regardless of the duplication of work.
Maybe it’s just a terminology barrier, but I wasn’t against multiple implementations users can choose between. The problem is having a plethora of implementations that are incompatible and result in code duplication and feature fragmentation. We’re already seeing this with features that only work depending on the desktop you are using. X11 succeeded in unifying diverse software on diverse architectures and desktop environments. Maybe wayland is still better on the whole, but at least on this front wayland does feel regressive.
> But I do wish we would learn how to roll out new FOSS projects better.
Amen.
I am certainly not defending Wayland on that front.
Yeah, I think I’d trust/use this.
Debian 13 has an “XFCE4 (Wayland)” option in SDDM. I’ve had success with KDE 6 with Wayland but have not tried it, although XFCE4 with X11 works as well as it always has.. I wonder how well it works, if the XFCE developers are willing to create a new window manager upstream?