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.
What now? GNOME doesn’t support server-side decorations? It’s been years since I last used GNOME, so I may be out of touch; but if this is true, what happens if you do run something on GNOME that simply doesn’t have any code that draws its own titlebars? Or am I misunderstanding how any of this works?
Their go-to solution is libdecor, which is just a library that implements a titlebar, still putting the burden on apps (Or rather, whatever windowing library they use) to be responsible for it.
Worst thing is, I kinda get their argument against supporting it, they’re just really inflexible about it which just makes the whole issue too heated.
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.
Certain applications work poorly without SSD. These apps end up having either no titlebar or a weird one, and the user can’t move or resize them easily. Davinci Resolve is one notable example, but it’s not the only one.
What now? GNOME doesn’t support server-side decorations? It’s been years since I last used GNOME, so I may be out of touch; but if this is true, what happens if you do run something on GNOME that simply doesn’t have any code that draws its own titlebars? Or am I misunderstanding how any of this works?
You get nothing.
Why would they not supply some default decorations when none are available?
Jesus, Gnome is such a shitshow.
Their go-to solution is libdecor, which is just a library that implements a titlebar, still putting the burden on apps (Or rather, whatever windowing library they use) to be responsible for it.
Worst thing is, I kinda get their argument against supporting it, they’re just really inflexible about it which just makes the whole issue too heated.
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.
From the article: