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.
an article explaining why GNOME should support SSD, but also arguing against the reasons often given for why they shouldn’t
If someone could repost this to r/GNOME I would appreciate it, since I don’t have a reddit account.
I don’t mind apps drawing their own titlebars if they have a real use for it (I’m typing this comment in a Firefox window where the titlebar has the tab bar in it), but not having any window-manager-level title bar as a fallback at all and requiring apps to do that themselves?! Window managers everywhere else have been doing this since what, the 1984 Apple Macintosh?
The idea is that it’s left up to the windowing toolkit itself (.e.g GTK or Qt, etc.), so the compositor can focus on just compositing, which makes sense IMO as it’s how other platforms handle it (Except they have a single OS provided windowing implementation). Problem is, that leads to massive fragmentation of functionality, every app has different toolbars and features based on the toolkit they use, and requires each app to handle it, which sucks and shouldn’t be the case.
Like in the Factorio case, it uses SDL for windowing, and SDL actually supports handling titlebars itself. But Factorio just wasn’t including the dependency that enabled it at that point, so all it took to fix it was including it and everything started working. But that’s still extra work that had to be done just to get minimum functionality, which wasn’t needed on e.g. KDE.
I mentioned in my other response, it’s the inflexibility that’s the actual problem. Lots of apps do want CSD, or at least control over how their windows are presented, but Gnome going “you’re on your own” is the worst outcome.
now that is truly idiotic
I don’t mind apps drawing their own titlebars if they have a real use for it (I’m typing this comment in a Firefox window where the titlebar has the tab bar in it), but not having any window-manager-level title bar as a fallback at all and requiring apps to do that themselves?! Window managers everywhere else have been doing this since what, the 1984 Apple Macintosh?
The idea is that it’s left up to the windowing toolkit itself (.e.g GTK or Qt, etc.), so the compositor can focus on just compositing, which makes sense IMO as it’s how other platforms handle it (Except they have a single OS provided windowing implementation). Problem is, that leads to massive fragmentation of functionality, every app has different toolbars and features based on the toolkit they use, and requires each app to handle it, which sucks and shouldn’t be the case.
Like in the Factorio case, it uses SDL for windowing, and SDL actually supports handling titlebars itself. But Factorio just wasn’t including the dependency that enabled it at that point, so all it took to fix it was including it and everything started working. But that’s still extra work that had to be done just to get minimum functionality, which wasn’t needed on e.g. KDE.
I mentioned in my other response, it’s the inflexibility that’s the actual problem. Lots of apps do want CSD, or at least control over how their windows are presented, but Gnome going “you’re on your own” is the worst outcome.