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 I think the biggest problem is, that people just hyperfocus on what gnome is or isn't doing.

Like why do people even care? I don't get it. Most of the rants really feel just like wanting to hate on the project for no reason besides hating on it.

People should just stop caring and do what they think is right. And if their app doesn't work on Gnome, then they can document it and just tell users to not use it on gnome and move on.

@karolherbst It's because we're already involved in these communities such that we already know the details around all of these things. But this really isn't discoverable for most app developers, and we've had plenty of incidents that give us bad PR and in turn give people the impression that we're just not intent on making Wayland work for application developers.
Like: you and I know cursor warping is "optional" as in "you won't have it on a car's infotainment system but it's pretty much guaranteed everywhere else". But we know that because we've been following this development for ages, how are others supposed to discover this sort of thing if we don't even really have a consensus that says this is expected across wayland desktops?

@Lyude normally there is https://wayland.app/ but it lists "no desktop" for "Pointer warp", but that's probably because nobody updated it 🙃

I do think we can document it, and maybe have something like "profiles" per use case, so I don't think it's necessarily a bad idea to make it easier to find what's supported across the desktop.

But I think it's mostly a documentation problem, because app developers need their own documentation (like https://wayland.app)

@karolherbst @Lyude having a top level filter for compositors on https://wayland.app/ so that it only lists protocols supported by the selected compositors would be useful
Wayland Protocol Documentation | Wayland Explorer

A better way to read Wayland documentation

@janne @Lyude yeah, sadly this project isn't affiliated with Freedesktop, sooo.. maybe check if they already have an issue filed on their github.

Though I _think_ some people were wondering if we could just move it under the wayland umbrella...

@karolherbst @Lyude there are few feature requests for that and https://absurdlysuspicious.github.io/wayland-protocols-table/ exists
Wayland protocols support table

@janne @karolherbst @Lyude This is amazing and going in my bookmarks, thanks! 😃