@schrottkatze @ch0ccyra1n What specific issues are you running into today, and on which DE? As there's a fairly good chance that they are DE issues rather than Wayland issues, by this point (with the important stuff being more or less stable now).

@joepie91 @ch0ccyra1n sway

can't find any half decent status bars (used to use polybar and waybar is a PITA)

wofi is cursed too and it's all just a meh ux

yes ik it's bc i havent' properly set up a lot of stuff, but still

i now need to look for a new statusbar (which is exhausting) and aaa ><

the standards for wayland apps seem to somehow be even lower then for x apps and that's really depressing.

also, no oneko :(

@schrottkatze @ch0ccyra1n Right, it looks like all of these don't work because they expect some sort of privileged access to the window manager (in the sense of being able to manage windows/layering and/or capture input)?

That's definitely one of the major items that still seems to be missing standardization - KDE has a custom extension (org_kde_plasma_shell) but only KWin implements that, and I can't immediately find a standardized equivalent :(

This is essentially the "no standard protocol for separating window manager from compositor" problem, as far as I can tell. Which is solvable in principle, but it doesn't seem like anyone has yet.

@schrottkatze in case you don't know - there is a (now pretty popular and packaged by several distros) fork of rofi with wayland support that works as well for me as the original worked on X11 https://github.com/lbonn/rofi

@ch0ccyra1n I don't know enough about the internal politics within desktop environment projects to know what exactly drove these decisions; all I can see from my perspective is Wayland *just about* starting to be usable (with a bunch of major features still in staging/unstable), but some DEs have already been shipping it for a long time with predictable complaints following that (like missing screensharing).

Maybe the devs were impatient, maybe some manager in a company somewhere jumped the shark, maybe it was a consequence of Xorg support being unsustainable, maybe it was something else, I really have no idea about that part, unfortunately.

(My perspective is mainly that of a Wayland implementer with no direct involvement in other implementations)

@joepie91 @ch0ccyra1n > all I can see from my perspective is Wayland *just about* starting to be usable

I've been using wayland ever since I switched to linux (around 2020-2021 I think?) and it has always been a better experience for me than xorg. And that was with nvidia proprietary drivers even. Xorg sucks.

The reason for the wayland push is/was (afaik, might be wrong) to get more people to use wayland, to get the issues fixed faster. The wayland issues aren't going to get fixed if no one's using it. And also devs want to retire xorg ASAP because its an awful mess that nobody wants to deal with. (so I've heard anyway, I don't have any xorg/wayland dev experience, only as a user of DEs and apps).

@aylamz @ch0ccyra1n When people talk about "issues with Wayland", they generally aren't talking about the general technical quality like the performance or tearing, but rather about tools they have come to rely on (toolbars, screenreaders, automation scripts, etc.) no longer working.

> The reason for the wayland push is/was (afaik, might be wrong) to get more people to use wayland, to get the issues fixed faster. The wayland issues aren't going to get fixed if no one's using it.

Sure, but there's a reason why tech companies have gradual rollouts and 'insider programs' and whatnot for these things. You want to do this in a controlled manner, and on an opt-in basis for as long as possible (even if actively encouraged), to avoid setting everyone's workflows on fire, like has been happening here.

The desire is understandable, but switching everyone over to an incomplete replacement and then letting them be the guinea pigs without ever getting their agreement, is absolutely the wrong way to go about this, and that is why people despise Wayland so much.

@joepie91 @ch0ccyra1n fdo/kde/gnome are not a tech company though, they are (mostly) volunteers and enthusiasts etc, working with way less resources and also the dynamic is completely different: the devs are much more motivated to fix stuff if their and their users' workflow is broken.

it's not great but that's just how FOSS with limited resources is I guess :/

@aylamz @ch0ccyra1n Indeed they are not tech companies, but I don't see why that would mean they can't do gradual rollouts or testing channels (especially with eg. GNOME getting backed by Red Hat). The concept is not very complicated to implement.

> the devs are much more motivated to fix stuff if their and their users' workflow is broken.

I'm sure, but is this software being made for the developers, or is it being made for the users? Because it's the users who end up suffering.