I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would consider lightweight or minimal.
Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it. To me the reasoning is solid: Wayland appears to be the future, and Rust is a good way to help avoid many compositor crashes, which are a more severe issue in Wayland (though it doesn't necessarily need to be fatal, FWIW.) Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Of course, if they made the right choice, it should be apparent in relatively short order, so I wish them luck.
Afaik there exists only X11 and Wayland, and X11 is dying if not dead. And for rust I don't see why a desktop user would be concerned by the language used as long as it is good enough.
Yeah, I am staunch proponent of "don't try to fix what is not broken". Current XFCE is fast, light-weight, usable and works fine without major issues. While I don't fully understand the advantages / disadvantages of XFCE using Wayland instead of X, if, as someone else pointed out here on HN, running XFCE on Wayland is going to make it slower, it means these developers will be crippling one of XFCE's strongest feature. In that case other minor advantages seems pointless to users like me.
Long-time XFCE user here. We care that stuff works the same, we appreciate how much work it is to achieve that when the world is changing out from under you, and we appreciate that XFCE understands this and cares about it. Being in Rust is not a concern.
Wayland has lots of potential, but it's far from ready to replace X11, especially in multitasking environments. XFCE is taking their time, because their community is more very concerned stability.
I predict that XFCE will default to X11 until Wayland has reached broad feature parity, then default to Wayland but keep X11 support until the last vestages of incompatibility are delt with.
There's no reason that this wouldn't be accepted by their community, and it should be lighter weight, in the end.
I am an XFCE user since many years, and am pretty decidedly in the "traditional and conservative about technologies" camp, and I think this is neat and just fine and dandy -- as long as they're not in a hurry to depreciate X11. Whenever I eventually have to go Wayland I would like to continue to use XFCE, so thumbs up for doing the work.
I spent a month or so in 2024 attempting to refactor xfwm4 so it could serve dual purpose as both an X11 window manager and Wayland compositor, and ended up abandoning the idea. It was just getting ugly and hard to read and understand, and I wasn't confident that I could continue to make changes without introducing bugs (crashers, even). We want X11 users to be unaffected by this, and introducing bugs in xfwm4 wouldn't achieve that goal.
Note that we don't have to rewrite all of Xfce: xfce4-session, xfce4-panel, xfdesktop, etc. will all run on Wayland just fine (there are some rough edges that need to be ironed out for full Wayland support, but they're already fairly usable on wlroots-based compositors). This is just (heh, "just") building a compositor and porting xfwm4's WM behavior and UI elements over to it. Not a small task, to be sure, but much smaller than "rewriting all of Xfce".
Could you expand on why you describe Hyprland and XFCE4 as "a cursed combination"? Might provide some insight as to why the official XFCE project decided to create their own compositor.
If wayland support was there already I would be using xfce. I truly admire it, it's great to see this happening and I hope the project continues in great speed. With DE's requiring hard system-d support, I would rather have something like xfce
i'm trying to build a Linux desktop and the first thing I got stuck at is X11 versus Wayland for greetd. Next thing Il got stuck at his XFCE4 doesn't exist for Wayland. What the shit. if we want to tell me wayland is the future, fine. sure. great. Tt's been 11 years!
It depends on what you mean by send. Wayland doesn't have network transparency, there's a bit of a song and dance you have to do to get that working properly. I'm not sure the state of that or of Wayland compositors in general on Mac.
Rather than going fully protocol-based (like Waypipe), they used Weston to render to RDP. Using RDP's "remote apps" functionality, practically any platform can render the windows. I think it's a pretty clever solution, one perhaps even better than plain X11 forwarding (which breaks all kinds of things like GPU acceleration).
I don't know if anyone has messed with this enough to get it to work like plain old RemoteApps for macOS/BSD/Windows/Linux, but the technology itself is clearly ready for it.
I've used Smithay's Rust client toolkit for a few months now. For making apps it is still sometimes have unsafe wrappers disguised as safe. It has a lot of internals wrapped in Arc<>, but in my tests, the methods are not safe to call from different threads anyhow, you will get weird crashes if done so.
I will seek to dive-in to how Wayland API actually works, because I'd really like to know what not to do, when the wrappers used 'wrong' can crash.
I don’t see much Wayland hype. It’s boring plumbing for most people, isn’t it? Most of us are just going along with whatever the volunteer plumbing community decided to put together.
Some cognitive dissonance going on here. The vast majority of current Linux Desktop users are on Wayland, and X11 is phased out across the board. Calling it hype is absurd.
I'm also not a big fan of Wayland, to be honest. But that's the way the winds are blowing. X11 has its problems, but even if they are fixable, no one seems to want to work on Xorg anymore. I'm certainly not prepared to maintain it and push it forward. Are you?
Depending on Xorg today is more or less ok, but I do expect distros will stop shipping it eventually.
It was originally named XFce after the XForms library. As of Xfce 3, it uses GTK though, so it could be called GTKce, but renaming the project every time you change widget toolkits is probably not a good idea.
>The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does...
I wonder how strictly they interpret behavior here given the architectural divergence?
As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.
This leads to my main curiosity regarding the raw responsiveness of xfce. On potato hardware, xfwm4 often feels snappy because it can run as a distinct stacking window manager with the compositor disabled. Wayland, by definition forces compositing. While I am not concerned about rust vs C latency (since smithay compiles to machine code without a GC), I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
> As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.
Not that that's necessarily the best way to do it but nothing stops xfwl4 from simply granting every focus request and then applying their existing heuristics on the result of that.
I started off using twm / olwm / vtwm in 1991. Then FVWM and Afterstep / WindowMaker. I've been using XFCE since around 2007. As long as it functions similarly I'll be happy.
As someone that is sensitive to displays, one of the best features of XFCE, unlike others desktops, is that it doesn't cause eye strain, probably because it doesn't play tricks - a pixel at a certain color is stable, and not dithered(if you choose) and higher level primitives are also stable and don't play time/frequency based games.
I hope XFCE preserves this, it is a killer feature in today's world.
70 comments
[ 3.7 ms ] story [ 79.3 ms ] threadGreat to know there's work on the wayland support front.
Also, writing it in Rust should help bring more contributors to the project.
If you use Xfce I urge you to donate to their Open Collective:
https://opencollective.com/xfce
https://opencollective.com/xfce-eu
Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it. To me the reasoning is solid: Wayland appears to be the future, and Rust is a good way to help avoid many compositor crashes, which are a more severe issue in Wayland (though it doesn't necessarily need to be fatal, FWIW.) Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Of course, if they made the right choice, it should be apparent in relatively short order, so I wish them luck.
With that knowledge, I'm certain that XFCE will remain lightweight. It can be done, so I feel confident that the XFCE folks will get it done.
Wayland has lots of potential, but it's far from ready to replace X11, especially in multitasking environments. XFCE is taking their time, because their community is more very concerned stability.
I predict that XFCE will default to X11 until Wayland has reached broad feature parity, then default to Wayland but keep X11 support until the last vestages of incompatibility are delt with.
There's no reason that this wouldn't be accepted by their community, and it should be lighter weight, in the end.
(Instead of seeing this as "xfce jumps on bandwagon", I'm seeing it more as "bandwagon finally stable enough for xfce".)
I wonder how long it'll take them writing a compositor from scratch.
I spent a month or so in 2024 attempting to refactor xfwm4 so it could serve dual purpose as both an X11 window manager and Wayland compositor, and ended up abandoning the idea. It was just getting ugly and hard to read and understand, and I wasn't confident that I could continue to make changes without introducing bugs (crashers, even). We want X11 users to be unaffected by this, and introducing bugs in xfwm4 wouldn't achieve that goal.
Note that we don't have to rewrite all of Xfce: xfce4-session, xfce4-panel, xfdesktop, etc. will all run on Wayland just fine (there are some rough edges that need to be ironed out for full Wayland support, but they're already fairly usable on wlroots-based compositors). This is just (heh, "just") building a compositor and porting xfwm4's WM behavior and UI elements over to it. Not a small task, to be sure, but much smaller than "rewriting all of Xfce".
Could you expand on why you describe Hyprland and XFCE4 as "a cursed combination"? Might provide some insight as to why the official XFCE project decided to create their own compositor.
If an application is written for Wayland, is there a way to send its windows to (e.g.) my Mac, like I can with X11 to XQuartz?
https://docs.freebsd.org/en/books/handbook/wayland/
Rather than going fully protocol-based (like Waypipe), they used Weston to render to RDP. Using RDP's "remote apps" functionality, practically any platform can render the windows. I think it's a pretty clever solution, one perhaps even better than plain X11 forwarding (which breaks all kinds of things like GPU acceleration).
I don't know if anyone has messed with this enough to get it to work like plain old RemoteApps for macOS/BSD/Windows/Linux, but the technology itself is clearly ready for it.
I'm not sure how much farther along they are than that post though.
I will seek to dive-in to how Wayland API actually works, because I'd really like to know what not to do, when the wrappers used 'wrong' can crash.
The cognitive dissonance I perceive goes like "No one is being paid to work on X11, therefore I should volunteer to work on Wayland."
I'm also not a big fan of Wayland, to be honest. But that's the way the winds are blowing. X11 has its problems, but even if they are fixable, no one seems to want to work on Xorg anymore. I'm certainly not prepared to maintain it and push it forward. Are you?
Depending on Xorg today is more or less ok, but I do expect distros will stop shipping it eventually.
I wonder how strictly they interpret behavior here given the architectural divergence?
As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.
This leads to my main curiosity regarding the raw responsiveness of xfce. On potato hardware, xfwm4 often feels snappy because it can run as a distinct stacking window manager with the compositor disabled. Wayland, by definition forces compositing. While I am not concerned about rust vs C latency (since smithay compiles to machine code without a GC), I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
The compositing tax is just waiting for vsync; unless your machine is, like, a Pentium Classic, compositing itself isn't a problem.
Not that that's necessarily the best way to do it but nothing stops xfwl4 from simply granting every focus request and then applying their existing heuristics on the result of that.
I've been using popos for a while, but xfce will always have a place in my heart.
If it had tiling support I'd probably use it still. Being so lightweight is a massive boon.
I hope XFCE preserves this, it is a killer feature in today's world.