Weston being the reference implementation for the protocol, my point stands and you're now picking nits.
As they should've done with the many other features that are missing from the base protocol because some designer somewhere decided it was "beyond the scope of the project".
We even have a pattern for this in the way HTML5 was developed.
I swear, it's like the Wayland folks were absolutely hell-bent on repeating the mistakes of the browser world circa 2000. The only question, now, is which project will end up the IE5 of the Wayland compositor world...
I'm being serious here, I legitimately don't understand what you're pointing out. Yeah I too wish everything I was planning on 13 years ago turned out perfectly, things don't work like that though. And if you ask me, the thing that's most comparable to IE5 is the Xorg server.
Amazing how nothing is ever the fault of the people leading the Wayland project.
> Any implementor always has permission to do their own thing, that's the point of making a second implementation. Putting something in a spec somewhere doesn't make it mandatory or guarantee it will be implemented.
Ahh, now I've got it!
So what you're saying is that, in essence, since your claim is no one follows it, one must conclude that in fact there is no spec!
And given that everyone I've come across who's involved with Wayland has said "Wayland is just a protocol", and given protocols are defined by specs, if the spec doesn't exist, then neither does Wayland!
Neo would be proud.
> I'm being serious here, I legitimately don't understand what you're pointing out.
I can't think of anything that more succinctly describes what's wrong with how Wayland has been developed over the last 13 years.
Well, except there is no spec, so I guess nothing was developed at all? I dunno...
>I can't think of anything that more succinctly illustrates what's wrong with how Wayland has been developed over the last 13 years.
I don't understand why and I wish you wouldn't do this, this is leaning into flame war territory. If you can explain your point to me in a way I understand, then I'm ready to listen.
The entire point of a spec is to help drive interoperable implementations. If that's not the goal, then it has no purpose and it might as well not exist.
The core of Wayland is supposedly a standardized protocol and these various projects seemed to do just fine implementing against that core spec. There's a reason I can run a Qt Wayland app on Mutter or vice versa.
Evolution and development of that spec can be done in a collaborative way that takes into account the various needs of those projects, such that the standard can evolve in a way that furthers the whole ecosystem.
That the Wayland folks instead throw up their hands and just say "write a compositor extension" demonstrates their unwillingness to do the actual hard work of building an ecosystem, which is creating consensus and driving adoption of common features.
Is this hard?
Yes.
What they are doing is hard, and it's deeply naive bordering on irresponsible to engage in a project of rebuilding the entire display server ecosystem without recognizing the need for coordination and diplomacy across the open source world.
I look at the history of this and all I can think is that this is a group of people who have failed to learn the lessons of the past. Groups like the X11 and HTML5 standards bodies, the IETF, and so many more have demonstrated how to build a consensus-oriented specification that enables and encourages interoperability. Yet, to hear you speak of this, that must be a figment of my imagination because apparently that's impossible.
If you ask me, people only notice the ones where it takes a while to reach agreement. Just look at the PR we're commenting on, it took nvidia several years to come around and implement dma-bufs. Sucks but it happens. No one ever seems to pay attention to all the other areas over the years where there was consensus.
From the perspective of someone happily using X11 at the moment, Wayland (or whatever your preferred term for "the loose association of compositors, protocols, extensions, and nonstandard hacks making up the Wayland ecosystem" is) looks like a failed attempt at building an ecosystem with proponents who are now trying to push it on everyone else in an effort to get the rest of the open-source community to solve the problems they created.
Every compositor is doing their own thing, application and framework developers need to implement basic functionality in one of several different ways depending on which DEs/compositors/WMs they want to support, some stuff has no replacement at all, and we're going to have to throw out the entire X11 world in exchange for... smooth DPI scaling and vsync? Really?
I honestly want to switch to Wayland - some of the stuff I've read about the X11 codebase is terrifying - but the cost of doing that, throwing out the entire desktop world, and giving up legitimate use-cases as "you shouldn't want to do that" is just too high, and the benefits are minimal. I'd honestly be happy to switch, but the whole ecosystem feels like it's a decade or two from being ready to go.
A lot of the hate Wayland gets stems, in my view, from the way it's been pushed on people. Users who aren't invested in the ecosystem and just see people pressuring them to switch to a loose collection of half-finished software that doesn't properly replace what they already have.
A protocol should never, never, ever be defined in any way by its implementations. The entire purpose of a protocol is to abstract away the common interface such that it is entirely implementation-agnostic.
Indeed, you might say that a protocol prescribes exactly the intersection of all implementations.
That's a better way to put it and that's more what I was getting at.
How did they manage to get through the project without addressing this point, and make it even worse, by offloading stuff like "screenshots" that was taken as a given to the nonstandardized compositor layer?
I'd also have wanted to see much more of a "one true widget library"-- so Wayland!GTK or Wayland!Qt are just thin wrappers on top, which would ensure you get any native theming or customizability/accessibility tweaks cross all your software for free.