I’m currently writing an article on the subject, and want to properly represent people’s views.
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
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 for argument is basically the following
- Wayland as a protocol was designed around CSDs, protocols for SSDs came years later
- Having the client control the CSDs simplifiies things for the compositor and apps
- The compositor has less things to implement and test
- Modern apps tend to prefer CSDs anyway since it provides more flexibility, very common on MacOS and Windows
- It’s difficult to coordinate things between the client and compositor.
- Something that annoys me about KDE is that they do this headerbar look where the top part of the application will match the color of the the titlebar. However, the top part of the application is drawn by the application and the titlebar is drawn by the compositor. But when the color changes (such as going from unfocused to focused), they do not update at the same time, so for a frame or few the top part of the application is a different color than the titlebar. That wouldn’t happen under CSDs.
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 <thing > 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).
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.
(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.
Sorry I did not understood what SSD meant.
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).
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”
App Icons are the identity of an app. Changing an app’s icon denies the developer the possibility to control their brand.
Here’s an novel solution to that: fuck off! A lot of us use Linux because we’re sick of corporations and rightsholders trying to control how we use our devices while treating us as marketing tools by shoving their “vision” in our face.
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!!
I agree with them when they say distros shouldn’t be theming their apps by default. When the packager breaks a package, it misleadingly gives users the impression that the software is at fault. Unless the distro itself is willing to field all the user complaints and bug reports, it just ends up causing problems for the maintainers.
Where I will never agree with them is in the demand that the developer has exclusive control over the application icon. It’s inconsequential to the software’s functionality, and if anyone thinks their brand should have more rights to a computer than the person who owns it, they can rightfully fuck off with the likes of Apple and Microsoft.
