[CarelessExpert]

I've heard all the excuses.

None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases, or worse, to make those use cases someone else's problem (e.g. screen sharing), thereby creating fragmentation in the ecosystem due to a lack of standardization.

After all, it's pretty rich to blame Gnome or KDE for "[deciding] to do something different" when Wayland was very deliberately designed to offer no standard for how to do the thing in the first place.

I'd actually prefer it was unintentional, as that would imply simple oversight. If it was intentional, that implies deliberately bad design choices that have gotten us to the semi-broken place we are right now; a place we're only finally getting out of as other people (e.g. the PipeWire folks) step in to cover up the spike-filled holes that Wayland has left behind.

[kaba0]

> None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases

The wayland protocol is multi-layered, with the core being deliberately only used for displaying content in recrangles properly. That’s it. But it also allows for querying the capabilities of the compositor with versioning, making extensions possible. There was a recent Show HN submission with this site: https://wayland.app/protocols/

The not-yet-core extensions doesn’t create fragmentation, actually there is a decent cooperation behind the 3-4 major compositor “backends” on everything, and ultimately they all settle on the same thing. Also, it’s a bit generous to say that fragmentation is somehow the fault of Wayland, when it has always been a problem in linux desktops.

Also, why do you think adding screen recording into wayland would have been great? It is a complex problem with audio syncing, not-necessarily display-related programs accessing streams and the like, so it seems relevant only on a surface level. Pipewire is the good layer to handle it. And prebaking some API without pipewire being ready would have been just stupid. It is/will be supported everywhere (there is a portal frontend already for gnome, sway and I believe plasma as well).

[michaelmrose]

I'm pretty sure the goal is Linux with a single tightly coupled official ui with no extensions or themes with the single point of configurability will be an accent color.

This to be part of a monolithic identical system where different distros are only different in terms of default software installed and logo and the entire os is read only and not user serviceable.

Look up rethinking how we put systems together by leonart poetering and comments from gnome devs about disabling theming to improve brand awareness or arguing about the folly of letting users muck up their work with the horror of extensions.

[taway098123]

These aren't excuses, there are no other parties at play here. Weston was the first implementation. GNOME and KDE were the next implementations. They could have chosen to copy Weston's implementation, thus making those parts "standard" but they didn't. That's the way it played out. The way you're talking about it makes it sound like there was some outside force designing Wayland and convincing the other designers to exclude screen sharing, when it wasn't like that at all. You also seem to be suggesting that they could have designed everything in hindsight perfectly before the implementations even existed, I hope I don't need to point out why it doesn't work like that.

You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. The fragmentation here is because it's taken a lot of effort to redesign these core components. Ideally this would all be done already, but it takes time.

[CarelessExpert]

> You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire.

Given that Wayland was first released in 2008 and the first commit to the PipeWire project was in 2015, I'm quite confident at this point that you're rewriting history to support your position.

[taway098123]

You misunderstand, it was only Weston that was started in 2008, and it had screenshots back then. I'm talking about those other implementations, they didn't really stabilize and start aiming to have feature parity until a few years ago, and they decided not to copy Weston's screenshooting mechanism.

[CarelessExpert]

Weston being the reference implementation for the protocol, my point stands and you're now picking nits.

[taway098123]

I don't see how I am, and I don't understand your point. The reference implementation had screenshots. The other implementors decided not to copy that and did their own thing. What more could the Weston developers have done? They can't force the other implementations to write code that they weren't interested in writing.

[CarelessExpert]

Actually standardize the protocol and make the feature part of the spec instead of delegating the implementation to compositor extensions and effectively giving everyone permissions to do their own thing.

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...