Cet article est aussi disponible en français.
This article contains quite a few technical terms, which I will explain these in the following paragraphs, those that are already familiar with these terms may skip to the next section. A basic understanding of linux and it’s desktop environments is assumed.
Server side decorations (SSD) is the term for when when the application’s titlebar is drawn by the system and client side decorations (CSD) is the term for when the applications draws it’s own titlebar. KDE prefers the former, while GNOME prefers the latter. KDE and most other desktop environments supports both, while GNOME only supports CSD.
Because they’re objectively better on a desktop.
Your compositor should control the window - if the poorly implemented client hangs, you can just click the server-side close button a couple times and get the “shall I force close this?” popup
The only reason for CSD is touch interfaces on small screens. In that case, you still need some other interface to handle misbehaving applications, but they tend to be harder to use, e.g. the removal of home/back buttons on Android
Edit: If you’re trying to improve on SSD, you could consider some model where the client can register some actions it would like to have displayed to the compositor, and the compositor can relay clicks back to the client. In this scheme, the compositor still owns the title bar, but the client can request special decorations
Even in this case I’d argue that on small screens most apps simply have no real decorations (not even client-side)… there’s typically not even a close button. Hamburger buttons are menus, which isn’t what’s typically considered “decoration”. One could argue that the bar at the bottom in Android with home/back/etc controls is effectively a form of SSD. Android offers system UI or gestures to send the app to the background (ie. minimize) or closing it, it does not require Apps to render their own, which is effectively what Gnome is asking with CSD.