So, why *should* GNOME support server side decorations?
85 points by calvin
85 points by calvin
For those of us in environments that have the .zip TLD blocked for security reasons: http://archive.today/2026.01.21-153030/https://blister.zip/posts/gnome-ssd/
But yes, I agree they should. UI consistency is an accessibility issue at the very least for people with cognitive problems, the neurodiverse, older users, etc. There's never going to be native DE support for every app a reasonable user might want to use, but letting the DE compositor/window manager at least manage the window decorations if the user requests is at least one thing that can help.
I support two baby boomers with their IT, and for at least one I have to stick to X11 and a DE that doesn't force CSD everywhere for them to be able to use it at all. The other currently prefers Ubuntu-flavoured GNOME, but even so they get confused by GNOME's modern-style titlebars etc.
UI consistency is an accessibility issue at the very least for people with cognitive problems, the neurodiverse, older users, etc.
100%. Or even just reduced cognitive load for those of us who want their computers to be tools for solving problems, rather than some UX designer's art project!
I haven't written a native GUI program in a long time, but if I was, as a programmer, I would be very happy to not have to write a bunch of boilerplate to actively manage things like titlebars, scrollbars, file pickers, etc.
It feels like the proponents of CSD care more about "my app feels nice" than making life easier for everyone.
I haven't written a native GUI program in a long time, but if I was, as a programmer, I would be very happy to not have to write a bunch of boilerplate to actively manage things like titlebars, scrollbars, file pickers, etc.
To be fair, you probably wouldn't do it, some library (wine or gtk or qt or whatever) would handle it, so it wouldn't feel that much different than SSD. Like on Windows, your application gets the message to draw the "non-client area", which includes the title bar and stuff, and if you let it do the default, the system handles it. It is a bit different in X in that the system doesn't even ask you, the window manager wraps you in a frame by default, but you can proactively tell it you don't want to be wrapped, then you can do it yourself. (What's interesting about the X way is that the frame and the application inside that frame are controlled by two separate processes, possibly running on two separate computers! You can run an X server on one computer, a window manager on another, then the application is on a third and they all work together. So it isn't even technically "server-side" lol)
Anyway, the toolkit would draw the frame one way or another so you're not the one programming it..... but the bigger question is what if you mix toolkits? On Windows, everybody agrees on the win32 api to at least some extent. The operating system provides theme info etc. The X way of having a separate process take control of some of the job also provides consistency in a way, it is all managed by the window manager. But if the toolkit does it... what if your program is on version 4 and they change it in version 5? Will the programs look out of place? So emulated SSD is a kinda hard problem to solve on the implementation side, even if it is abstracted from the app dev....
Regardless, yeah, I just don't get most the thinking behind gtk and gnome's designers.
I'm not sure how this changes with Wayland, but the biggest reason for supporting this with X11 (window-manager-drawn borders and title bar) was that it let you move / resize / minimise the window even when the application was not responding. With CSD, the X server would send a message to the application when you dragged the border or clicked on the minimise button and then the application had to respond by sending messages back to the X server to modify the window. With the window manager drawing these things, the app owned a window inside the window, so the WM could modify or minimise (hide) the window entirely without the app being involved.
This was even more of an issue with remote X11, where the WM was typically running on the same machine as the X server, but some apps would be remote. The added latency for the round trips while drag-resizing the app was annoying if apps decided that they wanted to do this themselves, so most WMs didn't let them. I'm not sure if this is still a problem with remote apps via PipeWire in Wayland.
CSD is a total mess. Clients do all kinds of shenanigans and each window behaves however it pleases. For example, some clients don't put the close (X) button all the way in the corner, so if you flick your mouse to the top right of the screen to click it, the button doesn't respond (classic ignorance of Fitts's law). I often have to force server-side decorations because of such foolishness.
Developing for Windows has become a nightmare in GTK4 because you literally need to re-implement the Windows titlebar in your application. Good luck matching the user's theme and Windows version! Windows server-side decorations just worked in GTK3.
With their crusade against server-side decorations, GNOME cements their reputation as a user-hostile project, led by people who put dogma over functionality, correctness and user satisfaction. CSD is a terrible idea. You gain a few pixels of space and you lose on every other aspect.
With their crusade against server-side decorations, GNOME cements their reputation as a user-hostile project [...]
And the worst part is that it's taking GTK along the ride.
Developing for Windows has become a nightmare in GTK4 because you literally need to re-implement the Windows titlebar in your application
I'm somewhat confused here. I thought Windows fully moved to CSD 15 years ago or so? Am I misinformed?
Windows very definitely didn't move to CSD. You might be misremembering Windows 8 requiring the compositor? Or how the decorations are technically drawn partially in-process?
I was assuming this is done by the app now considering you have so much flexibility in adjusting it with DwmSetWindowAttribute. But apparently that is composed into after the app finished drawing?
Hmm. It was a problem I ran into when I ported my application from GTK3 to GTK4. But apparently it's still possible to force GTK4 into using SSD on Windows?
https://discourse.gnome.org/t/is-there-any-way-to-render-a-native-windows-window-appearance/19345/2
I haven't tried it since I've abandoned Windows in the meantime. Also, this question was answered after my last try of getting my GTK4 application to work with a proper Windows title bar.
Good luck matching the user's theme and Windows version!
or you can just...not? like if you use a specific branding and don't mind CSD, then this is a non-issue? Is it not broadly fine for different projects to have different target UX visions?
Is it not broadly fine for different projects to have different target UX visions?
There are two camps: "hell yeah" and "hell no".
The hell yeah camp sees branding as a "right" of the app developer and puts forward the uniqueness of the look and feel of the app over a homogeneous appearance of the OS.
The hell no camp sees the user as the one in charge of choosing the graphical appearance of the apps, and prefers adherence to the user-chosen style over the desires of the app developers.
In the first camp you will find GNOME (https://stopthemingmy.app/) and most mobile developers, especially on Android. In the second camp you will find pretty much all usability and accessibility experts.
Wow, that site is eye opening! I knew that GTK has become increasingly difficult to theme but I guess I assumed that it was at least half as much about available resources as it was about open hostility to user choice.
To be fair, "Stop Theming My App" was always addressed to distributions, not to users. If a distribution rethemes an application and it breaks the layout, the user blames the app developer, not the distro maintainers. If the user rethemes an application and it breaks, they blame the theme author. They really should have been clearer about this, though.
Wow, this is an accessibility nightmare
The extraordinary thing about that whole website is that the Gnome community comes so close to understanding the problem, and yet so far:
Though we could disable theming directly in our apps, we do not want to resort to this. We believe that a technical solution would likely not be effective, because this is not a technical problem.
The Gnome project could work with the community to provide a framework in which to solve all the problems that custom themes are solving: improved visual cues and information density vs. stock Adwaita, different color palettes for people on whose monitors the default Adwaita palette doesn't work for whatever reason (monitor hardware, lighting conditions), better differentiation among icons and so on.
I don't like the dank ricing club either, and that's not why grown-ups want to be able to change widget shapes, colors and icons. I'm sure some distributions do it to "stand out", and a lot of designers are doing it for resume padding. But lots of people want to be able to do it just because the Adwaita design doesn't work for them. I get it, Adwaita's design vision, like any design vision, makes tradeoffs, so (contrary to what the Gnome homepage is saying but we all know how these things work) it's not a desktop environment for literally everyone. That's how any design vision works. Theming is just one way in which the community is trying to expand its appeal and usefulness to a wider user base, and you'd think there would be a way to encourage that kind of effort.
Instead, the Gnome design community is showing everyone the middle finger -- but hey, they're doing it respectfully, it says so right in the text, so no hard feelings, heart emoji.
Gee, I wonder what the non-technical problem here is.
IMO it is prudent to design a desktop in such a way that it allows moving and minimizing windows even if its application is unresponsive. Hoping that all applications are sufficiently bug-free to never lock up (and to never be slow to respond) is, IMO, naive, or is arrogant towards the users of such applications.
That is a pleasant side effect but the real reason is that the window manager is the natural place to draw window decorations. You get consisted controls regardless of the toolkit used (or even if no toolkit is used at all) and you respect the user's desire to control the window management experience.
"Create mechanism, not policy"
While I absolutely agree with you, I would like to mention my favourite Linux shortcut, which is surprisingly consistent on various DEs and WMs on Linux yet missing on Windows and MacOS -- <super>+left/right click-and-drag. The former is a move and the latter a resize. The key being you can click anywhere on the window.
I haven't experimented to check, but I suspect in Wayland the fact that windows have far less control over their own placement means that an application's window can always be moved or resized even if the application isn't responding. I don't know if you even get any message at all if you just get moved around without resizing.
Yeah, which to me makes CSD as a default make even less sense. Preeeeeetty sure an application doesn't get any messages on move unless part of it's been exposed or hidden or such. I'll try it sometime when it's not bedtime.
Insisting on CSD not just in Gnome but in GTK is absolutely ridiculous and doesn't acknowledge that GTK is used outside of Gnome. Why on earth would I want a giant useless CSD bar on my Emacs window when I use a tiling compositor?
emacs-gtk doesn't have a CSD titlebar on tiling compositors that support the xdg-decoration protocol. At least, this is my experience with niri, and I believe it was the same when I was using Sway.
The thread is old now but here is what I've learned since. Apparently GTK (and hence pgtk Emacs) does not support xdg-decoration, it only supports the older and now deprecated KDE specific KDE server decoration protocol. wlroots has support for this but it has to be wired up and not all wlroots compositors do that. This River issue is a good starting point to learn more about this mess.
A well-argued article that I strongly agree with.
As a user, my main reason is: some apps don't have a close button or draggable toolbar because they expect the desktop environment to do its job.
As a developer, my main reason is: my application fits in to every other environment because the desktop environment draws appropriate decorations, but it looks out of place in GNOME Wayland because it's using GLFW's or SDL's fallback CSD implementation.
There is a far more fundamental argument.
If folks wrote the CSD library in Javascript and demanded that everybody who writes C or C++ has to suck it up and figure out how to compile/link it in your project, everybody would be furious. Suddenly, the problem becomes quite obvious.
The CSD library forces the use of an external compiler/linker toolchain and ecosystem that you didn't need before. It infests every development environment with a gigantic dependency chain that is completely unnecessary.
All this solely to save the GNOME developers from having to do the work that they have to do anyhow? It's not like GNOME doesn't need to write the decorator library for their own stuff. So, you can either make everybody deal with figuring out how to link your garbage CSD which will piss everybody off and they will eventually generate a zillion shitty native CSDs just to avoid the compiler/linker issues. Or you can move the window decorators up a level and give people a protocol to do the actions consistently, just like X11 did with the Window Manager section of the ICCCM.
And then the GNOME developers wonder why everybody hates them.
I basically agree with the article, but I wish it had gone into a few more things:
Hey! Author of the article here, I actually had most of those things in an earlier draft, but they were cut for brevity, so:
xdg-decoration basically lets an application ask the compositor for a titlebar, said titlebar will be drawn on top of the application by the compositor. KDE apps use this, but a better example might be vscode(ium), since you can choose between CSD and SSD (xdg-decoration) in the settings. Put another way, it's the protocol that allows SSD to exist.
It would have no titlebar whatesoever (needless to say, it would look broken) and you would not be able to move the window or resize it without keyboard shortcuts.
Basically yeah, however the toolkit could hide the - [] x buttons and window title without extra work on the app dev's part. Of course these apps are not designed to have a system titlebar, which is why I only suggested it be an (opt-in) option.
Why is xdg-decoration still unstable, anyways? Per the wayland-protocols README, "unstable" is not a stage of development protocols would undergo anymore, so I don't know what the criteria are for a protocol to leave it. Still I'd presume, if anything, a protocol introduced in 2018, widely implemented and used in the real world, and having only had one minor change (addition of a specific error for 'invalid input') in the last seven years could be promoted to at least "staging" at this point.
xdg-decoration is also not implemented by Weston, the reference composer. Maybe this is what makes the protocol unstable.
It would definitely be nice, but I am curious why they wont do it. I cant see mentioning any technical reasonings against them in the post.
This is only tangentially related, but this article got me thinking about GNOME's chunky titlebars. I believe part of the reason for their size is that they tend to have additional buttons on them (thus the CSD stuff) - but I wonder how that compares to your classic Windows titlebar+menubar setup.
I wanted to try and do a direct comparison, but I couldn't really come up with a pair of modern GNOME and classic Windows programs that would make it fair.
They grew chunky with GNOME 3, before they started moving toolbar buttons into the window bar. I don’t know but I speculate it was due to their efforts to make it all work better on tablets: larger area to hit with imprecise fingers.
It was that crazy early 2010s age when everything grew chunky. It was a very fun period to watch -- I was in the same open-space area as the UI team at $work at the time so the UI folks and I shared a lot of "couldn't I have just done something else with my life" cigarettes at the time.
The titlebar-to-headerbar saga was the same everywhere and was a very fun rollercoaster to ride. First, the titlebar (along with every other widget) grew in size. It was kind of pointless -- no one really dragged windows on tiny touch screens, but all other widgets grew bigger, so they looked odd with the old, thin titlebars. But everyone knew PCs were a thing of the past and sales would collapse, if not next year, then surely the year after. Most people doing the designs didn't really believed this -- but the higher-ups were so in love with their iPads (which, in all fairness, made for excellent email forwarding machines) that they couldn't conceive of a world in which anyone would use anything else for work.
Unsurprisingly, people started running out of space -- if you're not writing apps to show cat videos, you have more than three or four widgets to show, so you run out of space pretty quickly. So the titlebar area started swallowing widgets as a space-saving measure.
At that point, on some platforms there was no longer a way to differentiate active from inactive windows via the titlebar (the widgets being swallowed in the titlebar just didn't lend themselves to colouring), so the only thing left to do was to fade application window contents.