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?

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.

On X, we had Xorg and that is it. But at least Xorg did a lot of the work for you.

On Wayland, you in theory have to do a lot more of the work yourself when you build a compositor. But what we are seeing is libraries emerge that do this for you (wlroots, Smithay, Louvre, aquamarine, SWC, etc). So we have this one man project expecting to deliver a dev release in just a few months (mid-2026 is 4 months from now).

But it is not just that we have addressed the Wayland objection. This project was able to evaluate alternatives and decide the smithay is the best fit both for features and language choice. As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward. That is how Open Source is supposed to work.

Great 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

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 have an old Thinkpad. Firefox on X is slow and scrolls poorly. On wayland, the scrolling is remarkably smooth for 10 y/o hardware, and the addition of touchpad gestures is very nice. Yes, there's more configuration overhead for each compositor, but I'm now accepting this trade.

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?

I only fear that this is manifestation of a wider phenomenon when new software developers are unable to maintain software created by old software developers. If that is so, they will try to simplify the software to what they can actually maintain and rewrite it into a form in which they can maintain it.

If i assume this is true, then all of this is annoying, but actually makes sense: Wayland is simpler than X11, so people will tend to maintain Wayland-related software rather than X11-related. Rust won't let unskilled coders to make some mistakes, so from their point of view it is going to be simpler to rewrite something in Rust.

Although, goodbye network-transparency, goodbye performance, goodbye stability. Oh well, but it's that time of the year.

I hope XFCE preserves this, it is a killer feature in today's world.

- speed

- memory consumption

- simplicity to use

- customisability

- if it's X11 or Wayland

If everything above the last remains the same in the Wayland version, I stay, else there is LXDM.

Now the last 3 times I tried Wayland everything ended up a blurry mess and some windows just ended up the wrong size, so.

I suppose I'll just keep holding out hope.

    • smithay has great documentation.

I wonder how long it'll take them writing a compositor from scratch.

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.

The beginning of the end, or are there plain and simple alternative microsoft rust compilers? Is microsoft rust syntax at least as simple than C?

Or the right way will be to use an alternative wayland compositor with the rest of xfce?