Wayland *can work* with SSD. There are protocol extensions that allow the client and the compositor, if both support the extension, to negotiate using SSD in a particular case (for one toplevel window) — xdg-decoration (which is imo a really unfortunate name that makes it sound as if server-side decorations are endorsed or recommended by XDG) and an older KDE-specific extension. xdg-decoration in particular always allows the compositor to override the client's preference and enforce its preferred mode.
Uh, so a clarification: setting aside technical advantages and disadvantages, there are people — and compositors — that prefer SSD. And that's what protocol extensions are for!
If your favorite toolkit and your compositor of choice implements SSD, great!
But if they don't, that's normal and in fact the default, and you have to support that. You cannot just pretend everyone has to implement your protocol, and then when many don't, blame GNOME for everything, like some people here like to do.
@bugaevc at least take responsibility, god dammit. There's no denying the disruptive effect GNOME has had on attempts to standardize. When there exists a standard and GNOME is the only one who's not implementing it, who's in the wrong here? Maybe GNOME deserves some blame, eh? Christ.
@sir how would this be my responsibility? You're mistaking me for GNOME developers.
GNOME is not the only one, I think we have already established that. Let me ask you this (and I'm genuinely curious) — are there any other compositors besides KWin and wlroots-based ones that implement xdg-decoration, perhaps some minor or experimental ones? I haven't seen any, but I assume you would know.
@sir Because the way you make it sound, everyone but GNOME supports a standard; but the way it looks to me is KWin and wlroots share a protocol that you've pushed onto upstream wayland-protocols repo so that KWin, wlroots, GTK and Qt don't have to ship their own copy.
@sir Besides, what would Mutter (-based compositors, assuming Gala adds Wayland support in the future) supporting xdg-decoration and telling every client to use CSD get you? — in xdg-decoration, unlike in the old KDE protocol, the server gets the final say, and the client cannot even announce what it supports.
Regarding Mir and Enlightenment - ok, haven't thought about those two. Mir seems to be doing well. Enlightenment is harder to tell without actually trying it, but I'll assume their move to Wayland is going well too.
But you're saying there are people using Weston as a daily driver?
@Wolf480pl there's also Sommelier (ChromeOS) that I forgot, and I believe Sailfish OS uses something called Lipstick (but I know very little about it). I've also heard that (modified versions of) Weston are used in Tizen and in automotive industry for IVI (in-vehicle infotainment) — meaning many people may use these compositors without knowing it.
@bugaevc I think you'll agree that IVI is out of scope of the CSD vs SSD discussion - they're using ivi_shell, not xdg_shell.
Does the concept of window decoration even exist in IVI?
@bugaevc uh, no. We have a protocol for this and it's supported by every compositor except... well, I'll let you guess.
@sir do you know what "1/2" means? 😀
@sir speaking of which compositors support xdg-decoration, I believe KWin and wlroots-based compositors do, while Mutter, Weston and Enlightenment do not.
FWIW Owl lets the user switch between CSD and SSD for each particular window, but doesn't currently support xdg-decoration — maybe I'll implement it in the future, maybe not.
@bugaevc I'm well aware of the adoption, though Weston hardly counts (averages a commit a week and has virtually no users who are in-scope for this protocol). Hardly anyone uses E, either.
What is Owl?
@sir I don't know in which world Weston, the reference Wayland compositor written and maintained by upstream Wayland developers to showcase Wayland, is irrelevant.
See https://mastodon.technology/@bugaevc/101603518023241841 for Owl announcement; it's got a small user base consisting of myself, hence "FWIW".
@bugaevc this one. It hasn't been the reference compositor for a long time.
@bugaevc oh, I saw your second post. Even the snarky "this isn't endorsed by XDG" comments
@sir of course it isn't endorsed by XDG; protocols need not be, but naming them xdg-something makes them seem like they were. I'm aware of the recent discussion  about naming, and I'm not blaming anyone for naming xdg-decoration this way, but it's... unfortunate.
@bugaevc why? It's totally on-topic for the XDG namespace, per our old guidelines and the new. Just because GNOME doesn't like it doesn't change what it is.
@sir quoting the mail linked above:
> XDG is already overloaded enough that I'd like not to add 'stuff some people use but others feel very strongly about not using' to it. Some people also interpret XDG to mean 'freedesktop.org Certified Seal of Approval™', which is ... sort of the opposite of that.
@bugaevc alawys thought "CSD" is a misnomer. The the title bar is a part of application. It does not decorate, it does things.
@lkundrak yep, and we call it a "header bar" exactly because it's not just a "title bar".
But CSD is not just about the title/header bar, it's also about the shadow and I guess other details (and the beauty of it is, GTK gets to treats window shadow the same way it treats shadows behind other widgets such as a button!).
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either! We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Café list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators. Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!