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.
Xfwl4 – The Roadmap for a Xfce Wayland Compositor
201–210 of 339 posts
Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor
#202Earlier 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…
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
#203Earlier 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…
Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor
#204Earlier 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.
Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor
#205I 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…
Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor
#206Earlier 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.
Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor
#207I 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…
Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor
#208Earlier 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
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…
> 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
#210Earlier 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.
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.