Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
xfwl4_faq [2026/01/30 11:17] – kelnosxfwl4_faq [2026/01/30 11:20] (current) – kelnos
Line 7: Line 7:
 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). 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).
  
-=== How can I contribute? ===+===== How can I contribute? =====
  
 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. 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.
Line 13: Line 13:
 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. 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.
  
-=== Ok, so when is the preview release? ===+===== Ok, so when is the preview release? =====
  
 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. 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.
  
-=== What's going to happen to xfwm4 and X11 support? ===+===== What's going to happen to xfwm4 and X11 support? =====
  
 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. 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.
  
-=== Why Rust? ===+===== Why Rust? =====
  
 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). 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).
Line 29: Line 29:
 (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.) (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.)
  
-=== Is all of Xfce being rewritten in Rust? ===+===== Is all of Xfce being rewritten in Rust? =====
  
 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.) 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.)
Line 35: Line 35:
 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. 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.
  
-=== Why wasn't it feasible to base this work on the existing xfwm4 code? ===+===== Why wasn't it feasible to base this work on the existing xfwm4 code? =====
  
 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: 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: