Xfwl4 – The Roadmap for a Xfce Wayland Compositor
Reception to an XFCE Wayland Compositor in Rust
- Many long‑time XFCE users welcome a Wayland compositor and see this as key to XFCE’s survival as distros deprecate X11. Several mention donating or planning to switch once Wayland support lands.
- A few are annoyed the project is funding a new compositor rather than fixing longstanding “small” issues, but the compositor author responds that without Wayland XFCE will become obsolete.
- The author explains they tried refactoring xfwm4 to support both X11 and Wayland but abandoned it as too complex and risky for existing X users; a fresh Wayland compositor (xfwl4) in Rust, reusing smithay’s example, was judged safer.
- Only the window manager/compositor is being rewritten; panel, session manager, desktop, etc. already run under wlroots-based compositors, albeit with rough edges.
- “Feature parity” with xfwm4 is a primary goal, but some behaviors can’t be matched until corresponding Wayland protocols exist; full parity is expected to take years.
Wayland vs X11: Future, Features, and Friction
- Pro‑Wayland comments emphasize: security and isolation compared to X, better HiDPI, fractional scaling, HDR, VRR, multi‑monitor behavior, docking, and “just works” experiences on Intel GPUs and old laptops. Gaming performance is reported similar or better than X11 on major desktops.
- Skeptics describe Wayland as a downgrade pushed by vendors: missing or delayed features (session restore, global shortcuts, embedding, some accessibility, window coordination), compositor‑specific fragmentation, and workflows broken or made more complex.
- Latency is a recurring concern: uncomposited X11 can feel snappier on very old hardware; compositing and atomic DRM add measurable but small delays, especially noticeable at 60 Hz. Some accept this as a trade‑off for smooth, tear‑free rendering; others do not.
- X11 is described as “not dead” with active forks (e.g., X11Libre), but also as effectively unmaintained in mainstream distros. There are accusations that large vendors deliberately starved X to promote Wayland; others attribute X’s decline to lack of maintainers and architectural limits.
- Network transparency is debated: X11’s ssh‑X model is praised; Wayland alternatives (waypipe, RDP‑based approaches) exist but are more complex.
Rust and Ecosystem Trade‑offs
- Several argue end users don’t care about implementation language; others note Rust’s ecosystem habits, binary size, compile time, and FFI ergonomics do affect maintainability and system footprint.
- There is disagreement over Rust–C interop: some say auto‑generated bindings and
unsafeare fine; others describe large C‑interop surfaces as effectively “writing C in Rust syntax” and not worth it. - Choosing smithay over wlroots is defended by the compositor author as a productivity and safety win given their Rust experience, despite wlroots’ maturity in C.
XFCE Identity and User Priorities
- XFCE users consistently prioritize: speed, low memory use, stability, minimal visual “tricks” (important to those with eye strain), traditional workflows, theming, and simple configuration.
- Many stress they’ll accept Wayland and Rust only if these characteristics are preserved; otherwise they would consider lighter alternatives.