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 @karolherbst Since you mention a car infotainment system, I wonder if part of the problem is that, to the extent that there's actual money going into developing the Linux GUI stack, maybe it's primarily for applications like that, rather than conventional desktops. And I imagine there is especially not much funding going into developing the kind of conventional desktop environment that makes vocal power users happy.

@matt @Lyude Well.. Red Hat pays a bunch of gnome developers at least.

But I am also working on trying to secure funding for Freedesktop as a hole we could maybe contract people with.

But that's something for the board to figure out if we are willing to do that and deal with the necessary paperwork.

I'd love to get STA/STF funding directly for Freedesktop, so we can do more "general desktop" things instead of it being focused on a single desktop.

@karolherbst @matt @Lyude There are a few companies directly investing in conventional desktop Linux:

* Techpaladin (KDE)
* Blue Systems (KDE)
* Red Hat, Canonical (GNOME)
* Igalia, Codethink, Collabora (GNOME)

But beyond that, I don't think there's much.

@neal There is one more.

* SUSE (GNOME)

Joan Torres may only work on GNOME part time while working at SUSE. However, that is still more than SUSE was contributing than 5 years ago 😀.

@adilarif @neal he did join Red Hat recently jfyi :-)
@nielsdg @adilarif Yeah, I left SUSE out because I knew that he moved to Red Hat.

@neal @nielsdg Thanks for sharing guys. Red Hat got lucky hiring Joan. He is a rockstar.

Here is to hoping SUSE backfills that GNOME contributing position with someone else.