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.
@Alfman
This always feel argumentative. It is not meant to be. But I feel like we are not on the same page with the facts.
> [On X11] Things like screencasting and network transparency just worked regardless of your choice of desktop
There is, to my knowledge, no spec for screencasting on X11. It “works” because of the lack of security. Contrast this to Wayland where there is an actual spec.
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.ScreenCast.html
Of course, you have to actually implement support. GNOME and KDE have implemented the most features. Almost everybody implements screencasting by now but not everybody has implemented everything else.
https://wiki.archlinux.org/title/XDG_Desktop_Portal
> X11 window managers could support X11 features out of the box without each needing to reimpliment those features
A Wayland compositor does not have to implement the freedesktop portals themselves if they do not want to. Niri, as an example, uses xdg-desktop-portal-gnome.
xfwl4 could use another implementation if they wanted. It sounds like they plan to do it themselves.
> The problem is having a plethora of implementations that are incompatible
It is a lot like the web. It is less about incompatibility and more about maturity with some implementations supporting more of the standards than others. But eventually, all the major implementations cover almost everything. Like the web, some engines implement things before they are standardized and, like the web, others may implement these vendored versions. You can see that one of the reasons they chose Smithay here is for the protocol support, including WLR and KDE protocols.
> a choice between implementations, but wayland doesn’t really buy us that after we’ve decided upon a desktop
The choice is not offered directly to the end user. It is offered to the developer. Again, think web browsers. I cannot chose engines when I choose Zen or Edge as a browser. The developers have chosen Gecko and Chromium for me. But a new browser project can choose the engine they want (or write their own if they choose). As an end user, I can choose the best Wayland compositor and their choice of support libraries may well factor into that.
In this case, the XFCE team looked at the landscape of Wayland support libraries and chose Smithay (specifically over wlroots).
But there are not many Wayland support libraries just as there are not many web engines. There really is not that much code duplication overall. And it is not really fragmentation even then as they implement the same standards.
This will become more clear as the ecosystem matures. Because it certainly is true that there are not standards for everything yet and not everybody has implemented all the ones we currently have. If you look at websites like caniuse.com, and pick any given web tech, you will see that a few years ago support was spotty but that now almost every browser supports almost every feature.
https://caniuse.com/flexbox
The “caniuse” for Wayland will look the same 2-3 years from now. There will be a half-dozen Wayland support libraries. Almost everybody will use the same 2 or 3. And all the standards will be implemented by everybody. But, if things stagnate, somebody else can come along and shake things up. And they will not have to replace Wayland to do it.
LeFantome,
They are making inroads now (your link is copyrighted from 2023) but for most of waylands existence it was not speced and just left to compositors. I genuinely hope that wayland desktop compatibility keeps improving, but I still hold a gripe for their decade long foot-dragging and the related opportunity costs.
While this point is probably futile, a lot of X11’s issues stem from the fact that X11’s developers basically held it hostage when they started working on wayland. I don’t criticize developers for wanting to move on to wayland and starting with a clean state, I share the sentiment myself. But it does irk me that they didn’t leave X11 in the hands of the developers who still wanted to improve X11. A whole lot of arguments about wayland doing things that X11 can’t come across as disingenuous in this light. It has less to do with X11 not being able to do those things and more to do with the fact that X11 became bureaucratically feature locked. These arguments against X11 security are linked to X11 not being able to get those features on bureaucratic grounds rather than because they were technically unfeasible. Wayland fans like to boast about new features like HDR only existing in wayland, but it conveniently ignores the fact X11 did receive patches for things like HDR. However the wayland devs who control X11 didn’t want X11 to evolve.
So, while it’s logical to point out the shortcomings of X11 including the ones you are talking about here, these weren’t necessarily intrinsic to X11. X11 was being actively sabotaged from the inside.
It’s not that your point is wrong, but wayland didn’t have to plot a course that would put users through these fragmentation pains in the first place. Even more than a decade ago wayland were being criticized for not handling such common user requirements. They could have and should have listened. They were starting with a blank slate. Now they’re trying to patch things up after wayland fragmentation is already a fact of life. I guess there’s little point in complaining about it now, but I wish they had listened more earlier.
@Alfman
> I still hold a gripe for their decade long foot-dragging and the related opportunity costs
I hear ya.
> it’s logical to point out the shortcomings of X11
Not here to bash X11
> wayland fragmentation is already a fact of life.
I know it feels like that now but I truly believe all this goes away as the support libraries mature and they all support the same Wayland standards.. I mean, already I can switch between Plasma, Niri, and COSMIC and mostly not think about things like screen sharing because they just work.
> the wayland devs who control X11 didn’t want X11 to evolve
This is totally true of course. But I do not see it in such a negative light. The Xorg devs did not believe they could modernize X11 without breaking it. So, they decided to start fresh. In some ways, this is the same decision being made here with xfwm4 and xfwl4. One of the described motivations for having the two totally independent code bases in XFCE is that they do not want to break xfwm4 and so are leaving it alone while they build something new. My take is that this is what the Wayland devs did with Xorg. And now, Xorg only matters to them as Xwayland. If you want Xwayland to succeed at providing stable compatibility, the last thing you want to do is to be adding new features to it.
I get it is frustrating if you disagree with the premise that X11 could not evolve without breaking it. We are not allowed to mention the Xorg fork here on OSnews but, if you look at that project, you will see either them breaking things or unable to implement features properly compared to Wayland. The Wayland devs believed that, to evolve X11, you have to break it. And the Wayland devs chose a strategy of keeping the breakage in Wayland while leaving Xorg to keep working for everyone while they did. But they certainly stopped evolving Xorg as well.
I have lots of complaints over how Wayland feedback has been handled. “You are not listening” has been a Wayland problem for years. But “everything is broken” never bothered me as much since the whole point of Wayland was for it to be that. Xorg is still there if you prefer it. And while Xorg development was absolutely halted, nobody has set out to “kill” X11 either. The official Xorg project is in maintenance mode. By design.
The Phoenix project is interesting. They also seem to think that you have to break X11 in order to move it forward. And so they are. But they are doing it in a way that probably feels much more sane and stable to modern X11 users. If the Phoenix project had come around a few years ago, they could perhaps have stopped Wayland from gaining the traction it is currently enjoying. As things are now though, I don’t see how Wayland fails to reach over 90% Linux desktop market share in 2027.
> I wish they had listened more earlier.
Amen to that
LeFantome,
This is after many years of frustration and some wayland desktops are still left out. Anyway I can accept that you are less salty about it, haha.
I don’t hold anything against former X11 devs for leaving in favor of wayland, go for it. But to actively repress further development by others doesn’t quite sit right.
(Yeah, I’m not linking in sources like I normally do, Other posts of mine have gotten deleted just for bringing it up).
It’s obviously fair to have a debate on whether extending X11 is worth doing. Perhaps ironically I do favor starting with a clean slate. What bothers me is the bureaucracy and some of the misrepresentations. I know the kinds of issues X11 was running into, but they’re not unsolvable. Access control lists could have easily addressed X11’s open security concerns with less breakage than Xwayland. Some features like HDR require new modes/primitives, but so what? Xorg nixed it, but nvidia had already paid developers to add HDR to X11.
Solving technical challenges like this is nothing new for software developers, we encounter them all the time and make it work. On one project from the 90s I had to modernize the entire crypto stack with lots of complicated external dependencies that couldn’t be touched. Some might have said it was impossible without breaking everything, but I did my job and created the abstractions need to maintain external compatibility. X11 isn’t special or unique in this regard.
> 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?
@Angel Blue01
If XFCE on Wayland in Debian 13 is using Labwc (probably) then it works quite well including good support for Xwayland. I do not have experience with Wayfire but I am sure it works ok as well.
In both cases, xdg-desktop-portal-wlr is used. This gives you screen shots and screen sharing but does not implement many of the other features you will find in GNOME and KDE Plasma. Sway uses xdg-desktop-portal-wlr as well. So, you will get the same level of protocol support that Sway has.
Obviously lots of people find xdg-desktop-portal-wlr good enough. But you may want something it lacks (global shortcuts maybe). You can see how the different xdg-desktop-portal implementations compare on the Arch Wiki:
https://wiki.archlinux.org/title/XDG_Desktop_Portal
@Angel Blue01
When you run XFCE4 on Wayland today, you are using a non-XFCE compositor like LabWC. This is a bit like running XFCE on X11 but replacing xfwm4 with openbox or something. It works but it is not fully XFCE anymore.
This is why XFCE wants to implement their own Wayland compositor. With xfwl4, they can provide the same user experience on Wayland that XFCE users currently enjoy on X11. They will also be able to control the experience completely moving forward as they evolve the XFCE desktop. They may create their own xdg-desktop-portal for the same reason.
If XFCE continued to rely on LabWC or Wayfire, the XFCE desktop experience would be driven by whatever those compositors decide to do.
GTK3 has a bug in Wayland where when menus get too menu entries they’re not scrollable, where as on X11 scroll bars would appear on the top/bottom so you could access all your menu entries. It affects MATE/XFCE environments. Basically any environment using a Windows 95/98/2000 style Start Menu. It doesn’t affect desktops that use search boxes instead. I wonder if they’re writing a compositor so they can detect the screen edge and work around the issue.
I don’t think it’s a good idea to create a new wayland compositor. I’m using xfce4 and labwc, and it works pretty well. But initially, there were problems with Wine applications in labwc. I’m afraid these problems will crop up again, and then things will drag on with xfce.