Live data from Hacker News

Xfwl4 – The Roadmap for a Xfce Wayland Compositor

alexxcons.github.io

201–210 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#201

Earlier quoted context omitted.

> I just want X11 support not to fall into disrepair Are you also willing to maintain it?

Are you willing to write accessibility support for the new xfce only wayland compositor? How will you get every other wayland compositor to support your non-'wayland core' accessibility extension? People like to frame things like the waylands are some sort of default and nothing is being lost and no one is being excluded.

Everyone has settled on an accessibility standard (Matt Campbell's). So it's not "your" accessibility protocol, it's already "the" accessibility protocol. This is working as intended IMO: allow things to compete and future in the wild and then pick the fittest.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#202
post #151
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…

You seen to know your Waylands. Do you know if global shortcuts are solved in a satisfactory way, and if there easy mechanism for one application to query wayland about other applications. One hack I've made a while ago was to bind win+t command to a script that queried the active window in the current workspace, and based on a decision opened up a terminal at the right filesystem location, with a preferred terminal…

Currently, the Wayland protocol itself doesn't have a standard solution to global shortcuts. Instead, it's being pushed to the XDG Desktop Portal API, under the org.freedesktop.portal.GlobalShortcuts service:

https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

This should work with Hyprland provided that you are using xdg-desktop-portal-hyprland, as it does indeed have an implementation of GlobalShortcuts.

I'm not sure if this API is sufficient for your needs, or if it is too much of a pain to use. Like many Wayland things, it prescribes certain use cases and doesn't handle others. The "configure" call seems to rely on xdg-foreign-unstable-v2 support, but AFAIK Hyprland doesn't support this protocol, so I have no idea what you're supposed to do on Hyprland for this case.

I am sorry to see developers have to deal with things in a relatively unfinished state, but such is the nature of the open source desktop.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#203
post #46
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…

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…

Nitpick, it's "systemd" not "SystemD"

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#204
post #149

Earlier quoted context omitted.

> Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for. I don't know if others have experienced this but the biggest bug I see in Wayland right now is sometimes on an external monitor after waking the computer, a full-screen electron window will crash the display (ie the display disconnects). I can usually fix this by switchin…

Is it gnome or kde or what? That's like saying "the website doesn't work", without saying what browser you are using.

Happens on any DE running Wayland. Ive gotten it to happen on both Gnome and KDE.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

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

Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems. At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to sup…

Amen brother

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#206
post #130
post #80

Earlier quoted context omitted.

Can you cite any sources for that claim? I found this blog post that says wayland is pretty much on par with X11 except for XWayland, which should be considered a band-aid only anyways: https://davidjusto.com/articles/m2p-latency/

Here's one article: https://mort.coffee/home/wayland-input-latency/ It's specifically about cursor lag, but I think that's because it's more difficult to experimentally measure app rendering latency.

[dead]

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

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

Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems. At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to sup…

Wayland was the first display system on Linux I've used that just worked perfectly right out of the box on a bog standard Intel iGPU across several machines. I think that is a big draw for a lot of people like myself who just want to get things done. For me X11 represents the past through experience I had when I had to tinker with the X11 config file to get basic stuff like video playback to work smoothly without tearing. My first Wayland install was literally a "wow this is the future of Linux" for me quite honestly when I realised everything just worked without even a single line of config. I would recommend a Wayland distro like Debian to the average computer user knowing Wayland just works -- prior to Wayland I'd be like "well Linux is great but if you like watching YouTube you'll need to add a line to your xorg config to trun on the thingy that smoothes out video playback on Intel iGPUs". Appreciate others have different perpectives -- I come from the POV of someone who likes to install a OS and have all the basic stuff working out of the box.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#208

Earlier quoted context omitted.

> running XFCE on Wayland is going to make it slower Citation. None of the other desktops have slowed with Wayland, and gaming is as fast as, if not marginally faster on KDE/Gnome with Wayland vs LXDE on X. https://www.phoronix.com/review/ubuntu-2504-x11-gaming

I based it on this thread - https://news.ycombinator.com/item?id=46780901

Latency and throughput are very different things. However, it's worth noting that the comparison here is with and without compositing. If you were using compositing already on X11 (I believe XFCE offers it with "Desktop Effects" or something to that tune) then you've already been eating compositing latency, and you should actually get less latency in some situations.

But as far as it performing worse overall, I don't think that would be expected. Compositing itself does lean more on hardware acceleration to provide a good experience, though, so if you compare it on a machine that has no hardware accelerated graphics with compositing disabled, then it really would be worse, yeah.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#209

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

(xfwl4 author here.)

> I wonder how strictly they interpret behavior here given the architectural divergence?

It's right there in the rest of the sentence (that you didn't quote all of): "... or as much as possible considering the differences between X11 and Wayland."

I'll do my best. It won't be exactly the same, of course, but it will be as close as I can get it.

> As an example, focus-stealing prevention.

Focus stealing prevention is a place where I think xfwl4 could be at an advantage over xfwm4. Xfwm4 does a great job at focus-stealing prevention, but it has to work on a bunch of heuristics, and sometimes it just does the wrong thing, and there's not much we can do about it. Wayland's model plus xdg-activation should at least make the focus-or-don't-focus decision much more consistent.

> I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?

I'm not sure yet, but I suspect your fears are well-founded here. On modern (and even not-so-modern) hardware, even low-end GPUs should be fine with all this (on my four-year-old laptop with Intel graphics, I can't tell the difference performance-wise with xfwm4's compositor on or off). But I know people run Xfce/X11 on very-not-modern hardware, and those people may unfortunately be left behind. But we'll see.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

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

> 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 functions can be in other processes, communicating over standard interfaces.

Post reply on HN