The GNOME Project is one of the two projects that have traditionally held most power on the Linux desktop. However, despite it being a major player in what’s considered one of the largest collaborative projects ever (Linux and Linux-based operating systems), I’ll make the argument that GNOME is an example of running an open source project more like a cult, complete with denying reality and training your current members to go out for blood whenever someone leaves. Quite bold claims, but I can substantiate.
“But app developers don’t want CSDs!”
Okay, not an actual quote, but I’ll be damned if it’s not an accurate way to describe the gnome developers' rebuttals when a contributor brought up the issue of supporting XDG-Decoration. The thread is quite long, but here are some quotes that I think sum up each side (however, I encourage you to read the whole thread if you have the time).
Jonas Ådahl (a GNOME maintainer) immediately closes the issue as a WONTFIX stating
There are no plans to support server side decorations under Wayland, and it’d be a step backward from the path we are aiming for with Wayland. So given that, I’m going to close this one as a wont-fix.
If you’re wondering what “the path” is, then Andre Klapper answers that question immediately after, linking to a post on GNOME’s blog announcing their CSD Initiative. The tl;dr: of this blog post is “the GNOME project is declaring holy war on title bars”.
Further down, the same Jonas Ådahl makes another post which I’ll pick apart:
Client side decorations has since the beginning been the way to have window decorations, and clients are expected to support this.
The first part of the statement is quite simply misrepresenting facts. Some operating systems such as Windows do in fact technically draw the window decorations from the client’s side, but this is done by operating system code that the application pretty much has to link to anyway in order to display a window. As far as the application developer is concerned, this is no different from requesting the window manager to draw a window.
On X11 however, Jonas' statement is outright false. Due to the variety of window managers on X11, the traditional way to do things here is to state if you want a server-side decoration or not, and then the window manager will oblige, either drawing the decoration itself or not doing it.
The protocol extension you linked to does not change that, nor did the kwin extension that came before.
This refers to two extensions: KDE Server Decoration, and its successor, XDG Decoration, irrespectively. The former was KWin specific as Plasma and KDE applications rely rather heavily on server side decorations, however, after Sway picked it up as well, it got standardised and turned into the latter.
But why are they important? The two offer the same window decoration negotiation that was standard on X11. So in a way, yeah, this protocol doesn’t change anything, it keeps the thing that wasn’t broken to begin with.
And further down, Carlos Garnacho, another GNOME maintainer, states the following
If individual applications rely on non-standard behavior from compositors, those applications should get fixed. One thing is that those apps optimize for the SSD KDE protocol, but breaking the common and beyond settled case by the Wayland community is a very different thing.
As stated above, this wasn’t a KDE specific thing anymore, it was standardised and accepted into the XDG spec.
As for the case being settled by the Wayland community, as already stated, both Kwin and Sway (the two other major Wayland compositors) both support this specification, but just in case that wasn’t enough for you, scroll further down and you find:
- Ryan C. Gordon, a major contributor to the SDL project, stating
We need this with the SDL project, as we expect to target any desktop environment with a single build […]
We can add a simple title bar ourselves as a better-than-nothing fallback, but we would definitely prefer it look like (and, equally important: act like) the rest of the user’s running applications.
- Deve (can’t link this to any specific SuperTuxKart dev but the issue is still relevant) stating
We need it in Supertuxkart too. Sure, I can guess if user wants bright/dark theme, large/small buttons on left/right side and draw it myself, but it’s just idiotic.
I just use kwin-server-decoration (will be xdg-decoration in future) and I treat the missing decorations as not our bug, but bad Gnome design.
Allegro project, which is heading towards Wayland backend implementation right now, will also have to rely on xdg-decoration
GLFW, another similar library, already does. I can’t see any realistic way to give proper UX under GNOME on Wayland for these libraries without xdg-decoration support.
So now you have three major projects that rely on server-side decorations (SDL, Allegro, and GLFW), along with a quite popular Linux game, all in support of XDG Decorations, and going against GNOME’s assertion that the wider community doesn’t want or need this. What’s GNOME’s response?
Matthias Clasen, a GNOME developer source
Fix the applications and libraries that claim the support Wayland, but don’t do it properly.
This statement will become very ironic later in this post.
Of course, outside of this thread there have been many people complaining about inconsistent or completely missing window decorations in GNOME Wayland, and there have been other cases of users desperately asking for a feature (such as layer-shell support) and GNOME developers just dismissing it as “you don’t need this, others only do it because they’re lesser”, but I think I’ve made the point: when GNOME is concerned, it’s their way, or the high way.
System76, GNOME, and a very messy breakup
Unfortunately, much of the discourse around this is buried on Twitter (and we all know how well that’s working these days), so it’s not exactly easy to find most of the related posts about it. However, I was there when it happened, and here’s my recounting of events as best as I can remember them:
In late 2021, System76 confirmed they would start working on a new desktop environment to replace GNOME completely, as opposed to COSMIC which was still GNOME Shell under the hood.
Following the announcement, GNOME developers started accusing System76 of not working with upstream (so the GNOME project), and “spreading FUD” in a rather vitriolic blog post and some convos in GNOME’s Matrix rooms. This led to some GNOME users going the extra mile and starting holy crusade against System76. While you can’t blame one for the actions of other people, in GNOME’s case they fostered a community that was bound to act like this, especially when GNOME developers were as relentless as they were in criticising, or more often outright trashing System76 and their efforts.
While this was one of the biggest incidents, it’s not by any means isolated. GNOME users regularly trash other projects, KDE being a favourite target, and whenever a project that used to be aligned with GNOME has views that don’t align with GNOME’s, as was the case with System76, they become an enemy. Simply put, cult mentality.
A crusade against themes
Ever since the early releases of GTK3, GNOME hasn’t exactly been shy about breaking things, particularly related to theming. So when in 2019 the crusade against themes was made official, nobody was surprised.
Although the main site isn’t officially a GNOME one, GNOME developers pretty much kicked it off with some blog posts that came right before the site’s launch. Not really, the GTK stylesheet example shown on the site is the result of using a known incompatible stylesheets with yet to be released application versions after GNOME started some fairly significant changes in the look and layouts of their applications. The Icon Themes point also doesn’t have much to do with reality, they show some icons being mismatched in Nautilus' sidebar but no mention of what icon theme would even cause something like this, certainly not any icon theme used by anyone ever. The app icons point is the only one that holds any water at all, but it’s not to say it’s very much water.
This letter was initially aimed at theming in general before it was walked back as “only towards distros” after significant backlash from the community.
Minor things that add up
I opened this post with the XDG Decoration thread, but it’s not the only time when GNOME could care less about standards or what people want.
System Tray
In GNOME 3.26, the system tray was completely axed. Reason? “Nobody used it”. But was it replaced for all the applications that relied on a system tray? Nope. GNOME developers just told application developers to “move on from legacy features”.
Cursor Themes
This might seem like a small point, and I wouldn’t blame you for it. How many of you think about how cursor themes are set? Well, if ever you’ve had to deal with setting cursors manually, you might know that GTK alone doesn’t use the standard ways of setting it.
The XDG
spec defines
one way to set the default cursor. In Sway, this is what is picked up when no
cursor theme is defined in Sway’s config file. Should that be set, however,
Sway’s components, as well as Qt applications and some misc applications like
Dosbox, and Kitty all properly pick up that. The only exception to this is GTK.
In GTK2’s gtkrc there’s a gtk-cursor-theme-name entry. GTK3 has the same
entry but it goes completely ignored. So where does gtk pick up its theme? From
the dconf entry org.gnome.desktop.interface.cursor-theme. Should you unset
that option in hopes it causes GTK to fall back to one of the two options from
earlier, gtk will just fall back to Adwaita specifically. Yes, I’m aware,
technically not a big deal, but it’s an issue specifically because it’s so
small. It’s really not hard to just grab the cursor from an existing place, if
nothing else it’s more work to specifically set the cursor to something pulled
from dconf, but it’s what GNOME decided to do.
Conclusion
I haven’t gone into everything, there’s far too much to go into in a single blog post, but I highlighted the events I thought were either illustrative of GNOME’s general behaviour, or which got to me in particular.
But the bottom line is this: GNOME runs their project as if they’re the only ones that matter. If you highlight any issues, you’re just spreading FUD in their eyes. There’s no room for the needs of other projects, there’s no room for collaboration. With GNOME, it’s their way or the high way, and with GNOME’s userbase, most often you run into a cult, where using another DE, Plasma in particular, is a sin that should get you crucified.