That's true from a technical perspective. But in reality devs (especially ones who aren't making "Linux apps" but are doing things like porting a previously Windows-only game to Linux) will occasionally ship a broken Wayland client. The compositor could then still give that a basic titlebar with window buttons like KDE and Cosmic do, or alternatively it can refuse to do it and make the novice user annoyed at the system as a whole.

I'm not really convinced that requiring all Wayland clients to draw their own decorations was the correct decision in the first place, but even if we accept it, I think there's still a convincing case for fallback SSDs.

so that’s just a broken app

technically, yes. but at the end of the day, in the real world, that app would work fine on ~all but ~1 desktop compositor

wayland doesn't require SSDs, because it's not just meant for desktop computing. in the context of desktop computing, it's been a standard for decades now to have a title bar on a window, so it does make sense that apps would assume they can get one without having their own drawing code or relying on a third-party library!

Wayland as a protocol was designed around CSDs, protocols for SSDs came years later

That's not an argument for anything. The core protocol isn't useful on its own, you always need extensions that came later to even create a window. As another example, Wayland as a protocol was designed around shared memory buffers, protocols for hardware acceleration came later. Doesn't mean you're supposed to leave that out.

Modern apps tend to prefer CSDs anyway since it provides more flexibility, very common on MacOS and Windows

That too is not an argument for not implementing what a ton of apps need.

MacOS and Windows don't do the same sort of CSD as Gnome FYI, it's more of a hybrid approach, where parts of the decoration are rendered by the system and parts by the app.

It's difficult to coordinate things between the client and compositor.

That too isn't relevant, libdecor doesn't coordinate shit either. And if you want to (which is being looked into), you can absolutely sync things with SSD too.

The actual and only reason Gnome doesn't support SSD is that they think CSD is a "better architecture".

The point 2.1 "less to implement in the compositor" doesn't apply, because for xwayland go work (which is intended to stay around for the foreseeable future) mutter still needs to implement SSD, it's only skipping on implementing the Wayland SSD protocols.

Points 1 and 2.2 are not strong points. "We do because we always did before <thing 2>" is not a good point. For example, after all, we always used X10 before Wayland, and we always did implicit sync before last year. And compositor shouldn't limit programming styles, they should support as many things as possible, and let the application decide their programming design. Plus, most modern applications on windows and macos embed a copy of chrome to display a single offline Web page, but I don't see you suggesting we replace compositors with browsers.

Point 2.3 is also weak because most of the things a compositor does are already hard, but they implement them because it makes the experience better. If something is hard, it just means it will be worked on more. Take a look at explicit sync, it took like 4 years to be rolled out, but it was necessary and got implemented.

I'll give you point 2.3.1... in general I think KDE looks pretty bad, and gnome is really more polished in many aspects. Unfortunately I really prefer the KDE workflow on big screens (but gnome on laptops).

Warning! The protocol described in this file is experimental

Nice, I didn't know about that. But the problem with Wayland is like always it takes too long. That's why nobody implements it.

Grrr a bunch of people who make and maintain the free software I use won't officially support me doing whatever I want, what's wrong with them!!