Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xfwl4 – The Roadmap for a Xfce Wayland Compositor

alexxcons.github.io

Post reply on HN
Print view View original

211–220 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#211

Post by kelnos »

graemep wrote: post #184
LeFantome wrote: post #104

Earlier quoted context omitted.

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.

I do not have a strong opinion about Xorg vs Wayland. My only real concern is that it might make it harder for the BSDs but that seems to be being dealt with. I do like being able to use X over the nextwork but that is a problem that can be solved. I do dislike System D for two reasons. One is exactly because it s a monolith and, in effect, an extension of the OS. The other is the attitude of the developers which bec…

> My only real concern is that it might make it harder for the BSDs

Our OpenBSD packager has already said in our Matrix channel that he'll be testing here and there in order to keep me honest ;)

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#212

Post by kelnos »

BearOso wrote: post #50
coldpie wrote: post #11

Earlier quoted context omitted.

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

If Rust has one weakness right now, it's bindings to system and hardware libraries. There's a massive barrier in Rust communicating with the outside ecosystem that's written in C. The definitive choice to use Rust and an existing Wayland abstraction library narrows their options down to either creating bindings of their own, or using smithay, the brand new Rust/Wayland library written for the Cosmic desktop composito…

(xfwl4 author here.)

> using smithay, the brand new Rust/Wayland library

Fun fact: smithay is older than wlroots, if you go by commit history (January 2017 vs. April 2017).

> It would have been much easier and cost-effective to use wlroots

As a 25+ year C developer, and a ~7-year Rust developer, I am very confident that any boost I'd get from using wlroots over smithay would be more than negated by debugging memory management and ownership issues. And while wlroots is more batteries-included than smithay, already I'm finding that not to be much of a problem, given that I decided to base xfwl4 on smithay's example compositor, and not write one completely from scratch.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#213

Post by kelnos »

BrenBarn wrote: post #153

I see the words "feature parity". I hope those words are taken seriously. I feel like most Wayland advocates would do well to take those words seriously.

(xfwl4 author here.)

Absolutely seriously. To me, a big part of what makes Xfce is xfwm4's behavior. Even though most of the other Xfce components will run decently well on wlroots-based compositors, I don't really have an interest in using them, as that's not "Xfce" to me.

But it's not going to be perfect, though, as some things that we take for granted on x11 still just do not have Wayland protocols to enable them. This will take a long time. Alex's blog post says a developer preview around the middle of this year, and I expect I can deliver on that, and maybe (maybe!) even a stable release by next year (maybe!), but full feature parity will take years.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#214

Post by gf000 »

throw0101a wrote: post #177
gf000 wrote: post #160

Earlier quoted context omitted.

For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it. X's network transparency was made at a time when we drawn two lines as UI, and for that it works very well. But today even your Todo app has a bunch of icons that are just bitmaps to X, and we can transfer those via much better means (that should probably not…

> For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it. I used run and use diskless SparcStation 5s with remote X on 10BASE2 network with the binaries running on Sun E3500s: it worked well enough for non-video web sites running Netscape 3.x. Also Matlab, Octave, Emacs, Vi(m), etc . I've used it to run backup app…

Well, we are using much higher resolutions with much higher frame rates and with more media-rich content.

You surely agree that not having a good compression here is less than ideal.

And it begs the question whether this is indeed the task of the display manager, or it's packing an unrelated functionality that could be better solved by another software.

And we haven't even gotten to sound - should a display manager now suddenly also handle sound?

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#215

Post by kelnos »

tasn wrote: post #4

Very interesting that they opted for a rewrite in Rust instead of adjusting the existing codebase. I wonder how long it'll take them writing a compositor from scratch.

(xfwl4 author here.)

I spent a month or so in 2024 attempting to refactor xfwm4 so it could serve dual purpose as both an X11 window manager and Wayland compositor, and ended up abandoning the idea. It was just getting ugly and hard to read and understand, and I wasn't confident that I could continue to make changes without introducing bugs (crashers, even). We want X11 users to be unaffected by this, and introducing bugs in xfwm4 wouldn't achieve that goal.

Note that we don't have to rewrite all of Xfce: xfce4-session, xfce4-panel, xfdesktop, etc. will all run on Wayland just fine (there are some rough edges that need to be ironed out for full Wayland support, but they're already fairly usable on wlroots-based compositors). This is just (heh, "just") building a compositor and porting xfwm4's WM behavior and UI elements over to it. Not a small task, to be sure, but much smaller than "rewriting all of Xfce".

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#216

Post by gf000 »

ux266478 wrote: post #186
gf000 wrote: post #160

Earlier quoted context omitted.

For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it. X's network transparency was made at a time when we drawn two lines as UI, and for that it works very well. But today even your Todo app has a bunch of icons that are just bitmaps to X, and we can transfer those via much better means (that should probably not…

>It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it. This is extremely misleading. Web browsers (and games) are the worst case for X11's network transparency. The overwhelming majority of applications belong in the same category as xeyes. > the original X network transparency's modern analogue might very well be the web It's Arcan,…

> The overwhelming majority of applications belong in the same category as xeyes.

Well, I'm not sure you are using that many xmotif apps. Most of the GUI programs are gtk/qt (and let's be honest, electron) - and they are mostly bitmaps to X's eyes (pun not intended). They don't use draw commands with such a small granularity that network transparency would benefit.

And Arcan is so many things at once I'm not convinced it is a good alternative to Wayland. It has good ideas, but they sort of require the whole package. Meanwhile Wayland is just a minimal API over the Linux kernel API for managing display buffers, that can be extended with additional protocols.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#217

Post by kelnos »

uecker wrote: post #118

Wow, this is annoying. I really like Xfce, but there are plenty of minor things which would need improvements. Instead of fixing all these minor things, they waste a lot of their donations on a rewrite for Wayland / Rust - apparently for exactly the same reason as all the other Wayland stuff and Rust reworks. Developers like to write new code more than actually maintaining / improving fixing existing things and finds…

(xfwl4 author here.)

That's a fair criticism sometimes, but, frankly, if you want things the way you want them, learn to code and dig in. Otherwise it's not really fair of you to complain about stuff that people have built for you for free, in their spare time.

In this particular case, it's not fully a "new and shiny, must play!" situation. I personally am not even a big fan of Wayland, and I'm generally highly critical of it. But Xorg is more or less unmaintained, and frankly, if we don't have a Wayland compositor, we'll become obsolete eventually. That's just the way the wind is blowing.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#218

Post by kelnos »

prima-facie wrote: post #15

Am I the only one who's not buying into the Wayland hype? I just want X11 support not to fall into disrepair, as I see nothing wrong with it.

(xfwl4 author here.)

I'm also not a big fan of Wayland, to be honest. But that's the way the winds are blowing. X11 has its problems, but even if they are fixable, no one seems to want to work on Xorg anymore. I'm certainly not prepared to maintain it and push it forward. Are you?

Depending on Xorg today is more or less ok, but I do expect distros will stop shipping it eventually.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#219

Post by nosrepa »

dyingkneepad wrote: post #117
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

To me the most painful switch was Gnome 2 to Gnome 3. I still miss Gnome 2. I left Gnome 3 for other WMs (eventually settled on cinnamon), but every once in a while I decided to give Gnome 3 a try, just to be disappointed again. I felt like those people in abusive romantic relationships that keep coming back and divorcing over and over again. "Oh, Gnome has really changed now, he won't beat me again this time!".

Kde 3 to 4 for me. I still miss you amarok 1.4.10.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#220

Post by saurik »

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.

How is Wayland more modular? It conflates the window manager, the compositor, and the display server, all into a single component that must be replaced as a single unit. This kind of new conflation is exactly what people dislike about systemd.
Post reply on HN