i am starting to think that we actually really do need a specification that defines a baseline of wayland protocols to try to get close to application developer's expectations.
I also like, really would like to see more expectations set around "please stop saying 'we're not trying to be windows'". i gotta be honest i'm starting to realize this is kind of a really dismissive response that ignores the fact that we have a protocol here that we are trying to get people to use, and people aren't really going to use something they're literally not able to develop for :\.
People tell me this isn't an issue but then i see stuff like this:
https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/
that was posted -literally this month-. And it's frustrating because out of the issues listed there:
- cursor warping is and has been supported for a while across multiple compositors. It is "optional" as in "you probably won't have it on a car's in-vehicle-infotainment system.". like, the expectation is -really- not about compositors deciding not to implement it
- clipboard issues have been solved for ages now?? i literally remember which clipboard issue they're talking about because I had it on my own desktop lol
KiCad and Wayland Support

The KiCad development team frequently receives questions about our support for Wayland. Given that Fedora and Ubuntu are both planning to drop X11 support from their main desktop environments in the near future, we want to provide clear, transparent guidance to our users about the current state of Wayland support in KiCad. Current Status Is Functional but Degraded KiCad does run on Wayland systems, but with significant limitations and known issues that substantially degrade the user experience.

@Lyude This is the moment where companies usually rebrand their product and then everybody is happy after the rebranding, because "this is much better, we can figure out the remaining issues"
@karolherbst i genuinely think we need to sit down and have an actual "this is what you can expect from any wayland desktop compositor that's marked as being desktop compliant". like going into a lot of these points it's not particularly surprising that they're worried people won't have consistent support for them. we have this tiny barebones core wayland protocol and then basically whatever other protocols a compositor chooses to support and just this assumption that some optional protocols will always be supported without any clear indication to app developers

@Lyude The issue is, that we don't want to enforce a trademark, and without that we have 0 leverage.

Like yes we could say "this and that is expected to be there", but if a desktop doesn't follow it, there is nothing we can do about it.

People talk about "spec body" and "you need a proper spec", but people forget those only work if you are actually willing to go to court over your trademark.

@karolherbst then we just have the spec and have desktops like kde implement it and leave people out who don't want to play ball until they realize that no one is writing applications for their desktop.
i don't feel like this is an issue we can ignore when a lot of these applications don't even have linux as a primary userbase. unless we're ok with wine becoming the most popular API for application development on linux :\
@karolherbst like, frankly, I do think having other compositors agree on a baseline would push things forward even if we have projects like gnome trying to avoid this. because at some point they'll still have to answer once most of their userbase is complaining that they can't even implement a basic standard everyone else agreed on. and if they don't, maybe at this point it's best we just leave them to their own devices until they can't ignore it anymore.

@Lyude Yeah.. it's a tough situation to be in.

The issue is, we are kinda one of the few FOSS projects who actually does something like that.

And we can't enforce anything. It's a social problem, and if desktops have different visions on what they want to achieve, then they'll just end up doing whatever they want anyway.

Like even the discussions around "veto"s. Not having them would change exactly nothing. And publicly shaming hasn't worked up until now either.

@karolherbst it's less about enforcement and more about getting the compositors that want to play nice with eachother to just do so, and then just letting natural pressure from the userbase push other projects into starting to support it as well.
we can still say "this is what we define as Freedesktop's desktop compositor base". if kde, sway, whatever other compositors we get on board support it and projects like gnome don't, it's not that we need to force them into it. it's just we're not going to wait around

@Lyude How is the union of wp and xdg protocol extension namespaces not what you ask for?

@karolherbst

@pq @Lyude @karolherbst enforcing things is always hard/impossible. Would a site that documents compositor support of protocols, akin to drmdb.emersion.fr, be helpful here?
Wayland protocols support table

@karolherbst @hwentland @Lyude There are expectations and then there is the current implementation status. Both seem important to me.