[shmerl]

> Further, it's not even clear that this kind of program is practically possible on Wayland.

It's pretty clear. But some are too stuck up to even research it or be part of shaping it. Which is common among legacy vendors who very rarely even care to communicate with Wayland developers about their needs.

Those who aren't stuck up deal with it just fine (OBS Studio for example).

[yjftsjthsd-h]

Lol - it's "stuck up" to prefer software that works? If you want people to switch, it'd help to actually cover their use cases. Showing up to proclaim software "obsolete" when the supposed replacement literally doesn't support the features in use, then... what, claiming we're bad people for not contributing to Wayland? is the cultural part of why people don't like Wayland. (In a distant second place behind the technical reasons people don't like it, which boils down to missing features and present bugs.)

[shmerl]

Stuck up means they don't care to collaborate. If they don't, how would anyone know about their specific needs? Those who don't have this dinosaur mentality do work with Wayland developers and their needs are addressed faster. Others learn the hard way but also usually like to complain that "things don't work".

[t0b1]

Maybe people don‘t because they see, for example, Valve (a billion dollar company) struggling to get GNOME to implement drm-leasing for VR headsets. IIRC they‘ve been at it for multiple years, too.

Or maybe it‘s because the compositor developers are not exactly concerned about ease of development. To quote a GNOME dev[0] about support for the aforementioned drm-leasing protocol:

> I honestly don't have a problem with forcing clients to implement the portal if they want to work on mutter.

I wouldn‘t blame the people who choose to simply not engage with that process, especially those who work on these things in their free time.

[0]: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2759