I’m currently writing an article on the subject, and want to properly represent people’s views.
You mean about adding SSD to gnome, which will not happen?
As an argument in favour, I see:
- Support for more applications that “don’t want” to implement CSD (i.e. foot terminal, davinci resolve, that one archive manager I can’t remember)
- Lifting burden for applications that don’t need custom decoration buttons, and so don’t care about implementing their own decorations
- Making the decorations on those applications consistent with the theming of the system
As an argument against, I personally don’t see any. Sure, most gtk apps are designed for CSD and will not translate well to SSD, but I just don’t see why that should stop gnome from implementing SSD. I remember the gnome maintainers were strongly convinced against SSD, but I don’t remember their argument
The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs? ~~There are many new Linux users who try to get something like DaVinci Resolve running and then can’t maximize it because it doesn’t have CSDs. For these users it just makes using Linux feel broken for basically no reason.~~¹
This is also a burden for application developers. Maybe the DaVinci Resolve devs should just fix their app (from what I heard it’s a massive PITA in all aspects imaginable), but is it really reasonable to also expect e.g game devs to add dependencies on libdecor or whatever solely to unbreak window mode on GNOME Wayland?
¹ Edit: I have since learned that Resolve actually does draw CSDs, it just doesn’t draw the window buttons. That’s certainly a choice… I think the overall point isn’t too affected but this specific app isn’t a good example since it would still be broken if GNOME had fallback SSDs.
The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs?
Wayland requires apps to be able to draw CSDs, so that’s just a broken app. SSDs are optional extension. So the app should either use X11 (and rely on Xwayland to provide the decorations), or implement Wayland properly.
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!
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.
To be a normal DE that works like all other platforms and desktop (apart from macOS maybe, idk, likely also has support)
KDE also uses CSD if apps support it, but if not, apps dont break for no reason
(Edit: I always mix up the terms server side and client side decoration. Hopefully by my description its clear which one I’m referring to.)
Pro SSD: the window manager should decide how the apps look
- user: consistency across the operating system usage
- dev: generalized and less burden on the dev, less dependencies to worry about and development specific to GNOME
- both: flexible, change your window manager and the app changes without modifications (at least in ideal world)
At least for a normal window. I wouldn’t mind if an application can request with a high priority that it wants to display its own decorations. In that case there should be an option to disable decorations from the window. That is how some applications do work and allows for a flexible usage based on users configuration. Now if there was just an official API from all window managers that can check this configuration, then the user wouldn’t even need or know there is a setting for.
Now if there was just an official API from all window managers that can check this configuration
This actually does exist. Reasonable Wayland Compositors will negotiate with their clients on whether they should use CSDs or SSDs. To an extent Qt does this: It prefers SSDs but it can draw CSDs if the compositor can’t draw SSDs (or signals that it doesn’t want to), which is why proper Qt apps are perfectly usable on GNOME Wayland despite missing SSDs.
It would be possible to go even further and make apps that display menu and tool bars on compositors that prefer SSDs (like Plasma/KWin) and nice GTK-style decorations on others. It just happens that most apps either really want to draw their CSDs (mostly because they’re made for GNOME, a.k.a. anything using Libadwaita) or they don’t really have a use for them (like regular Qt apps).
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.
I haven’t noticed a difference between server and client side decorations when using GTK apps, but it’s nice to have uniform server side decorations for apps that are not GTK
Check https://stopthemingmy.app/. They will give you the fors.
That’s just about themes, they don’t mention SSD vs CSD at all.
The main arguments for seem to be “It’s not a core spec” and “CSD is better”
That’s a largely unrelated topic… You can have theming without SSDs (as seen in most standalone compositors and also kind of Cosmic) and you can have SSDs without theming (at least in theory, I’m not aware of a project actually taking this stance).
Sorry I did not understood what SSD meant.
