As much as is possible, yes. The holy grail would be if you can't even tell that you're running xfwl4 instead of X11+xfwm4.

In reality, that won't quite be the case. Some desktop environment concepts are just not standardized on Wayland, and aren't implementable. It will take time to achieve feature parity with xfwm4, so some things might be missing for a while. And while I'll do my best, I'm sure I'll make mistakes, and some things won't be quite the same (but I'm happy to try and fix any cases of that if it's brought to my attention).

At this point, you shouldn't; doing so would frankly just slow things down and be counter-productive. Later, when things are more stable, and development has slowed down, more people can (and should!) get involved.

For now, also please do not file any issues, feature requests, or merge requests on the Gitlab issue tracker. Things will be missing and broken, and it's likely I already know about whatever it is you're going to report. (And if I don't, it's off my radar, and trying to put it there will only get in my way.) After we have a preview release, then it will be time to report problems.

I'm aiming for sometime in the middle of 2026. No hard date, and things can change, but I do want to get something usable into people's hands as soon as possible.

xfwm4 will continue to work as an X11 window manager as it always has. Xfce should continue to run on X11, and there are no plans currently to drop support, or change things so parts of the desktop only run properly on Wayland.

The usual reasons: not having to deal with memory safety issues or data races; strong, expressive type system; algebraic data types; ability to sprinkle functional programming throughout; strong community; etc. But mainly, I (Brian) just prefer it over C, and I'm not interested in starting a new C project. I no longer have the patience for tracking down segfaults and UAFs and memory leaks when I can use a language I like that offers similar performance and doesn't let me compile programs with those kinds of bugs (at least not without me explicitly asking it to).

Since refactoring xfwm4 to turn it into a Wayland compositor wasn't feasible, and I was going to have to start from scratch, I decided to take the opportunity to start with a language I think is better-suited for the task.

(You may disagree that Rust is better-suited than C here; my view is a subjective one, after all. That's fine, but this decision is not up for further debate, and comments about the choice of Rust are boring and will not lead to productive or useful discussion.)

No, definitely not. RiiR (“Rewrite it in Rust”) is (IMO) an unproductive use of time, outside of some special cases. (Not that I'll look down on anyone who wants to do that in their spare time. Everyone can enjoy their time however they want.)

For some extra detail here: if you're not aware, Xfce is made up of quite a few different components, each of which are separate programs. The only one that is being replaced/rewritten for Wayland is xfwm4. The rest, fortunately, can be (or have been) modified to serve double duty and can run under both X11 and Wayland, without needing major, fundamental changes. Those other components are written in C, and nothing is changing there.

I tried this, back in 2024. The idea was to refactor things so that xfwm4's behaviors were split away from the X11 details. Then both the existing X11 code, and new Wayland code, could use the same behavior code. This turned out to be incredibly difficult. I spent about 3 weeks working on this, and learned:

1. I was nowhere near done, and there would still be months of work to do, even before writing any functional Wayland code.
2. Several times during the process, despite a high level of care, I broke it (crashes, broken windowing behavior). I wasn't feeling confident that the result would be high-quality and regression-free.
3. It's probably easier to write a Wayland compositor that you later turn into an X11 window manager, than it is to do the reverse.
4. Xfwm4's design relies heavily on the GTK/Glib main loop. and uses it in some unusual but quite clever ways (e.g. using gtk_main() recursively to make some operations “synchronous”). Much of this is fundamentally incompatible with how wlroots and a wl_display server need to be driven.
5. Solving these problems in xfwm4 would either a) lead to two parallel, duplicative code paths, one handling X11, the other handling Wayland, in a confusing manner, or b) a major refactoring of how xfwm4 works that would almost guarantee regressions and new bugs.

I really wanted to use xfwm4, as it's an extremely high-quality piece of software that's been battle-tested over decades. But I could only conclude that it wasn't going to be the best, least-risky option.