[traverseda]

Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing.

The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support but it's still all unpaid volunteers.

There also used to be some more leeway about protocols and extensions. For a long time now Gnome has been saying "you're either a gnome app or you're not" when they deprecated stuff like tray icons. But there was generally a way back, a way to run your non-gnome app cleanly on Gnome. With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. There are common desktop extensions that Gnome just isn't really interested in developing.

[tristan957]

> unpaid volunteers

This is not entirely true. A few GNOME developers within GTK/Mutter/GNOME Shell are paid to work on this kind of work at least part-time. SourceHut also pays Simon Ser to do some Wayland work, whether that is maintaining wayland-protocols or something else.

> With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now.

This is also not true. GNOME has designs for tray icons in their GitLab repo. The thing that is blocking better tray icons in Linux is a lack of interest in finishing the protocol proposal. The ticket hasn't seen much traction in the last couple of months.

https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...

[traverseda]

I didn't mean unpaid Gnome developers, I meant everyone else. People like this SDL developer: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552...

He's certainly not getting paid to make SDL work on Gnome, and I think does a pretty good job of explaining why the proposed solutions from Gnome will result in a poor user experience.

>This is also not true. GNOME has designs for tray icons in their GitLab repo.

Yeah, but every other wayland compositor seems to have gotten it to work already. This is what people mean when they talk about "splitting the linux ecosystem". If they're not able to manage the complexity of implementing stuff like tray icons, things that are really important for cross-platform apps, maybe they should pivot to using a library like wlroots.

[sho_hn]

I don't know about the "on Gnome" part, specifically, but I think Ryan has done work on SDL on contract, or contributed to SDL as part of contract work on e.g. game ports. He's a prolific guy with many stories to tell about the Linux desktop, see https://icculus.org/~icculus/

I do get your point, though, and it's true, there's of course a lot of manhours on e.g. app fixes and porting, and many other things, that happen on a volunteer basis in the community to make it all work.

[traverseda]

Yeah, Icculus' case is a bit odd but also one of the strongest showing this in action. Barrier/synergy/input-leap (or whatever they're calling themselves these days) is another good example, but I can't just link to one polemic thread to get the point across. They've more or less just given up, despite the like 3 grand bug bounty for getting it working on wayland. Waypipe works, but ironically you can't forward x11 apps so you get into this weird situation where you need to use different protocols for different apps and you don't know which ahead of time.

OBS seems to finally be working with linux/wayland again, semi-reliably, and of course most things continue to work via x11 shims. It's getting closer, especially as Gnome gets closer to actually implementing a full set of desktop app protocols, but it is just a lot of work for toolkit developers to port everything over.

I still don't know how you'd go about running GUI apps inside docker containers, something we do at work for a few complicated deployments of ROS stuff (yes I'd rather do it some other way, but we don't have the man power).

[bombela]

And Gnome is slow, with a completely limited UI that barely gives you anything of utility. The file selector is so bad (try selecting a file with the keyboard) and slow it's not even funny, it even has concurrency issues if you select things too fast!?, in Gnome applications, buttons keep changing places for no reasons, 30y olds shorcuts stop working an update to the next (like, press enter to validate), they refuse fractional scaling for... I don't know actually, etc, etx. I am sorry for the well intentioned people working on Gnome. But it's just a dumpster fire at this point.

And the tone in the Gnome issue tracker is insufferable. Everybody that suggest something or tries to help is a moron from their point of view.

I cannot help but think the people working on Gnome live in a weird bubble.

[hollerith]

>they refuse fractional scaling

Huh? I'm using Gnome instead of MacOS because I can choose the size of the text and the other UI elements. On MacOS, the only choices that aren't blurry are 100% scaling and 200% scaling, but Gnome lets me set the scaling to an arbitrary value without blurriness. (I had to fuss with Emacs and my web browser to get them to be non-blurry when the scale factor is something other than 100%.)

Are there stupid design decisions in Gnome? Yes, but I've found Gnome to be usable with a little research (i.e., on how to set keyboard shortcuts for switching between apps instead of the "activities view").

[bombela]

Ok now I am not sure which is which, what it working and what isn't anymore: https://wiki.archlinux.org/title/HiDPI#Fractional_scaling

[type0]

> There are common desktop extensions that Gnome just isn't really interested in developing.

In GNOME 45 all current extensions will loose backward compatibility, that's one of the yet more changes that will force many to migrate to other desktop environments

[tadfisher]

There is a really good technical reason for that, and honestly, I don't want to use extensions that aren't being maintained as new versions of Shell get released.

The reason Gnome doesn't have a stable extensions API is the same reason extensions are powerful: extensions are user code running in the same JS environment as Shell and can do anything. I think that's a decent tradeoff for a best-effort system without a ton of manpower and ecosystem involvement.

[hulitu]

> expecting a bunch of unpaid open source developers to go and re-implement everything

We are really wondering why those "unpaid open source developers" would want to "re-implement everything". Fixing existing systems is hard, i presume. /s