Xfwl4 – The Roadmap for a Xfce Wayland Compositor • Hacker News Board

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#301

Post by jeltz » Thu, Jan 29, 2026, 2:30 AM UTC

mcswell wrote: post #125

jchw wrote: post #88

Earlier quoted context omitted.

Here's my PoV: - Having a single X server that almost everyone used lead to ossification. Having Wayland explicitly be only a protocol is helping to avoid that, though it comes with its own growing pains. - Wayland-the-Protocol (sounds like a Sonic the Hedgehog character when you say it like that) is not free of cruft, but it has been forward-thinking. It's compositor-centric, unlike X11 which predates desktop compos…

> xdg-session-management for being able to save and restore window positions > is still not merged, so there is no standard way to implement this in Wayland For me, this is a real reason not to want to be forced to use Wayland. I'm sure the implementation of Wayland in xfce is a long time off, and the dropping of Xwindows even further off, so hopefully this problem will have been solved by then.

Yeah, this is a feature I use a lot. If it was no longer there I would need to switch to a scriptable window manager and manually script positions.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#302

Post by jeltz » Thu, Jan 29, 2026, 2:38 AM UTC

poulpy123 wrote: post #56

Isn't the switch from X11 to Wayland the most painful switch that happened in the linux world ? Even going from python 2 to 3 was not as bad

I think Python 2 to 3 was the by far worst.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#303

Post by gf000 » Thu, Jan 29, 2026, 5:15 AM UTC

throwaw111 wrote: post #297

gf000 wrote: post #295

Earlier quoted context omitted.

Because on the web we have a very very complex protocol(s) built up over decades to tell a client what to draw locally. That's html/css/js and its scope is far larger than of x draw commands (it's also an application model). But again, GUI apps don't use X draw commands for the most part, so they are effectively a bitmap/video stream to X's eyes. And what's better to transport a video stream than a format designed fo…

Idk given there is no concept of cache. But also I'm looking at GTK menu, it is a simple menu, white bg. May be it can be rendered using draw calls. May be the complex UIs is just fashion and will be gone in a few years. The GUIlib could detect if program is running on a remote computer and reduce the effects, but they will need a concept of network for that. Also the font rendering. The client could then just send t…

It's not "complex UI", it's what programs are generally used. It's gtk, qt, and a bunch of other cross-platform platforms all doing their own thing. They simply render (in a hardware-accelerated way) to a local buffer and that's the only commonality.

Could random draw calls be transported over the network? Sure, and for certain kinds of GUIs it is definitely more efficient than rendering and sending some compressed artifact.

Will XMotif suddenly change the world and apps will be written in it? Absolutely not. It's not even a thing on the minuscule Linux desktop, let alone elsewhere. We are running electron apps and whatnot.

And as I said, this "send draw commands" exists: SVGs are possibly the closest thing, but the web as a whole is literally this with a couple of more features.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#304

Post by account42 » Thu, Jan 29, 2026, 9:43 AM UTC

Fiveplus wrote: post #28

>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 fo…

> 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.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#305

Post by account42 » Thu, Jan 29, 2026, 9:49 AM UTC

kllrnohj wrote: post #285

josefx wrote: post #254

Earlier quoted context omitted.

It isn't always pure overhead, but also jitter, additional delays and other issues caused by the indirection. Most systems have a way to mostly override the compositor for fullscreen windows and for games and other applications where visible jitter and delays are an issue you want that even on modern hardware.

> Most systems have a way to mostly override the compositor for fullscreen windows and for games No, they don't. I don't think Wayland ever supported exclusive fullscreen, MacOS doesn't, and Windows killed it a while back as well (in a Windows 10 update like 5-ish years ago?) Jitter is a non-issue for things you want vsync'd (like every UI), and for games the modern solution is gsync/freesync which is significantly b…

X11 doesn't have an exclusive fullscreen mode either. [*] It's always has relied on compositors and drivers to detect when fullscreen windows can be unredirected. Some programs chose to implement behavior like minimizing on focus loss or grabbing input that is closer to Windows's exclusive fullscreen mode but the unredirecting of the display pipeline doesn't depend on that.

[*] Well, there was an extension (can't recall the name right now) but not much used it and support was dropped at some point.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#306

Post by account42 » Thu, Jan 29, 2026, 9:50 AM UTC

josefx wrote: post #290

kllrnohj wrote: post #285

Earlier quoted context omitted.

> Most systems have a way to mostly override the compositor for fullscreen windows and for games No, they don't. I don't think Wayland ever supported exclusive fullscreen, MacOS doesn't, and Windows killed it a while back as well (in a Windows 10 update like 5-ish years ago?) Jitter is a non-issue for things you want vsync'd (like every UI), and for games the modern solution is gsync/freesync which is significantly b…

> I don't think Wayland ever supported Isn't that true for even the most basic features you expect from a windowing system? X11 may have come with everything and the kitchen sink, Wayland drops all that fun on the implementations. GNOME does unredirect on Wayland since 2019: https://www.reddit.com/r/linux/comments/g2g99z/wayland_surfa... > Windows killed it They replaced it with "Fullscreen Optimisations", which is m…

"Fullscreen Optimisations" is how X11 has always worked.

Window's actual exclusive fullscreen always caused tons of issues with Alt+TAB because it was designed for a time when you couldn't fit both a game and the desktop in VRAM.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#307

Post by account42 » Thu, Jan 29, 2026, 9:58 AM UTC

drob518 wrote: post #188

wtallis wrote: post #179

Earlier quoted context omitted.

Refresh rate directly affects one of the components of total input lag, and increasing refresh rate is one of the most straightforward ways for an end user to chip away at that input lag problem.

Well, sure. But so is buying a faster processor.

Empirically latency has gone up instead of down with faster processors.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#308

Post by account42 » Thu, Jan 29, 2026, 10:02 AM UTC

coldpie wrote: post #11

jchw wrote: post #3

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…

> 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. Very long time (since 2007) XFCE user here. I don't think this is accurate. We want things to "just work" and not change for no good reason. Literally no user cares what language a project is implemented in, unl…

> The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about.

Being proud of how you are uncaring towards others is a sad state of affairs.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#309

Post by account42 » Thu, Jan 29, 2026, 10:05 AM UTC

LeFantome wrote: post #104

graemep wrote: post #46

Earlier quoted context omitted.

I used XFCE for a long time and I very much agree. it just works, and is lightweight. I use KDE these days but XFCE would be my second choice. > The X11 diehards will go the way of the SysV-init diehard I hope you are not conflating anti-systemD people with SysV init diehards? As far as I can see very few people want to keep Sysv init, but there are lots who think SystemD init is the wrong replacement, and those prim…

It is refreshing to see somebody else notice that the complaints about systemd and Wayland are philosophically incompatible. Systemd is creating the same kind of monolith monoculture that Xorg represented. Wayland is far more modular. Regardless of your engineering preferences, rejecting change is the main reason to object to both.

> It is refreshing to see somebody else notice that the complaints about systemd and Wayland are philosophically incompatible.

Only in reductio ad absurdum.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#310

Post by account42 » Thu, Jan 29, 2026, 10:07 AM UTC

gf000 wrote: post #245

kelnos wrote: post #210

Earlier quoted context omitted.

> Wayland is far more modular. Not sure I agree here, assuming you mean "... than X11". With Wayland, you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process. (Though there is a Wayland protocol being worked on to allow moving the WM bits out-of-process.) With X11, display and input-handling are in the X server, and all those other fun…

> you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process That's an implementation detail. You can absolutely separate one out from the other and do IPC - it just doesn't make much sense to do so for most of these. The only one where I see it making sense is the window manager, which can simply be an extension/plugin either in a script…

It's not an implementation detail that X11 specifies interfaces between those separate components and Wayland does not - X11 is designed for for the window manager being separate from the display server, Wayland is designed for them being the same.