GNOME accomplishes what seems to be impossible: it’s the most limited and bloated desktop environment for Linux. But that’s not accidental. It’s the result of the arrogance and amateurism of its main developers, making the design decisions of GNOME a masterpiece of chaos. To better understand what’s happening, let’s analyze some examples on top of what we have already discussed [1] in the previous articles [2]. Even if none of the following directly affects you, it’s worth understanding the modus operandi behind GNOME projects and how they offend the Linux community.
Showing a static text on the screen is one of the simplest things we can do when programming [3], but because the code in GNOME is usually more complicated than it should, some things may behave unpredictably. For instance, Settings application may fail to show the GNOME version. This issue was reported more than one year ago and still hasn’t been fixed [4]:
GNOME is case study in poor performance. Settings not only takes a long time to open, but also requires a long wait to preview a few background images when loading for the first time (Fedora 39) [footnote 1]:
Simply opening a folder with 40 images in Files (nautilus) takes 4.6 seconds to load all thumbnails, while in thunar (Xfce 4.18) the same thumbnails load in 2.6 seconds. This is a local file browsing experience on a real machine (not VM):
Another example of poor performance is mutter (GNOME compositor). When running in X11, every time a key is pressed from a different device, mutter freezes for around 100ms, causing stutter, especially noticeable in performance-sensitive applications such as games. An issue was raised 5 years ago [5], and a merge request was accepted but then reverted due to undesirable side effects [6], so the issue is still open [footnote 2 and 3].
If OpenGL 3.0 is not available on the system, then GNOME runs in software rendering and mutter completely disables all window animations, which can be problematic as GNOME’s usability heavily relies on its animations. Now, why can’t mutter fallback to OpenGL 2.0 or even CPU mode to handle these simple animations? It’s hard to believe that their animations are more complex than those of Quake 2 or Unreal Tournament, games that used to run in software rendering on CPUs from the late ‘90s.
In Text Editor, available since GNOME 42, if the user types a keyword in the search popover, the application will immediately scroll down to the keyword in the text, but if the user then presses Escape, the application will scroll back to the top for no good reason. By opening the search popover again, the keyword will be there but this time it’s required to press Enter to find the keyword in the text, and by pressing Escape now Text Editor will just close the search popover and won’t scroll up. Doesn’t matter if no text editor with GUI behaves like this because GNOME always knows better.
The language screen might not show any language, even when the system is able to switch between English and many other languages. I know that because recently I made for my distro a really simple PyGTK application that shows all the system languages available, allowing the user to select which one they want. It just works. KDE Plasma also provides a user-friendly screen to do that and it works perfectly. But on the exact same system, the language screen in GNOME might show this mess:
Let’s say you open Rhythmbox (GNOME audio player) and want to change the volume. Simple, right? Well, after seeing a slider with a speaker icon beside it you assume that’s what you want, but no. That slider is to go backward/forward in the song, not for setting the volume.
GNOME Software, its app store, is also a collection of gems. When first opening it, most of the UI components will be missing. And when trying to search for anything, no result will be returned. It will take more than a minute to have a usable UI, even on a 50 Mbps internet connection.
This kind of amateurism is all over the place:
- there is a hot corner on the top-left to access the Dash on the bottom
- GNOME session starts in Overview mode by default because they decided that’s how the Dash would be visible
- in the desktop view, if the user presses Super + A shortcut, then Applications Overview will open but by pressing Escape it won’t go back to the desktop view
- the user can’t really tell what’s minimized or closed unless they switch to Overview mode, and even then, if the application is set to go to the tray area it won’t appear anymore because GNOME has no tray area for third-party applications
- after opening mpv video player and right-clicking on the Dash the user will see Quit 2 windows, but there’s only one
- Files won’t update any file size information if an operation is made by an external application. This basic feature works perfectly in dolphin (KDE Plasma) and even in thunar (Xfce), which is a much smaller project
- because GNOME doesn’t support xdg-decoration protocol when running in Wayland [7], some applications will not have a title bar, like mpv video player. In KDE there is no such issue
- when running in Wayland, some applications fail to render simple things, like for example Audacious audio player, which can’t render its embedded 2D spectrum analyzer. Again, in KDE it just works
- Applications Overview is hard-coded to show up to 24 applications per page, regardless of the resolution/scaling
Applications Overview is actually a complete mess even in the latest GNOME 45.2. As mentioned in the previous articles, the application items get mysteriously ‘sorted’ even if the machine is idle with no application running in the background, and you can’t set anything sane like alphabetic order or most used.
Ungrouping applications in this screen is one of the most tedious tasks the user can perform. But feeling bored would be nice in GNOME because the usual is to feel annoyed: after ungrouping some applications an arrow will appear so the user can navigate to the next page, however no arrow will be visible to go back to the previous page. Of course it can get seriously worse: after ungrouping the last item, the whole GNOME shell crashes and becomes unusable:
Console was released as the official terminal application, replacing Terminal in GNOME 42, but many popular distros haven’t adopt it because it doesn’t bring any real advantage. Performance is still poor and many features were removed. But recently a GNOME developer decided to optimize VTE, the library behind these terminal applications, and instead of updating one of the existing terminals to benefit from these changes, he decided to create a third one called Prompt [8]. No doubt the rendering performance is great now, finally, but only after many years and at the cost of a third terminal application.
Similar but more dramatic thing happened to Eye Of GNOME, which in GNOME 45 was replaced by a new application called Image Viewer (Loupe). Again, instead of improving the existing application they decided to create a new one with dubious improvements and many regressions, including worse compatibility, buggy window resizing, much bigger binaries, more than twice the RAM consumption (exceeding 800 MB to open a 5 MB static PNG) and many other issues, showing that the application was clearly in beta stage. After GNOME 45 release, the main developer announced that due to some friction with the team she was leaving the project [9]. She eventually changed her mind and is now back on the project.
Releasing projects that are still not mature in each final release is something that many times GNOME team doesn’t even try to hide. For example, in GNOME 45 the following applications were shipped in beta stage: Console, Contacts, Logs [10]. In GNOME 43, there were also 3 applications in beta stage: adwaita-icon-theme, Logs, Orca. And, believe it or not, Cheese was released in alpha stage [11]. These are not rare examples. All GNOME major releases have some explicit alpha/beta stage software.
The third-party developer perspective is another chapter of horror in the GNOME ecosystem. For instance, it’s required that extension developers set the GNOME shell version target in their metadata.json, otherwise the extension won’t be loaded, even if the code itself doesn’t have to change after a new GNOME release. And because extensions are not integrated into the package managers, every time GNOME is updated, all extensions will stop working, requiring manual update from the user side. At least this insanity is somehow backward-compatible, meaning extensions updated to work in GNOME 44 may also work in GNOME 43 or older. But to no surprise things got worse this year: GNOME developers decided to make a change in version 45 forcing every single extension to have the code updated, regardless, and this time there was no backward compatibility [12]. To make matters worse, they announced this less than one month before releasing GNOME 45.
Similar examples could continue indefinitely:
- for years Document Viewer (evince) would fail to build if adwaita-icon-theme was not present, although it would build and run perfectly if the meson build file was changed to remove this dependency
- GNOME refuses to run in Wayland if it doesn’t find the folder /tmp/.X11-unix
- Files and VTE are hard-coded dependent on the folder /usr/local/include otherwise they won’t build, no matter if your distro uses another folder structure and everything else builds normally
- xdg-deskop-portal-gnome is required since GNOME 45 otherwise the dark theme won’t work, although no error or warning will be shown
- GNOME developers keep pushing most of the dependencies to be in their latest versions otherwise GNOME projects won’t build, although usually this is not really necessary
- if there is any critical library missing (e.g. mozjs) or schema that hasn’t been compiled, GNOME shell will lock the user in this useless screen with a button to logout that doesn’t work
- if GNOME’s side project xdg-desktop-portal-gtk doesn’t start at boot time, applications may not work properly [footnote 4]
One might wonder: instead of just complaining about these issues, why don’t you report them to the developers? Well, because most of the time they simply don’t care and can be very aggressive towards any sort of criticism.
Felipe Contreras wrote an article this year about the arrogance of GNOME developers [13]. He mentions the story of a user who reported a regression in Terminal [14], and then a GNOME developer replied with just ‘No’, as incredible as it seems. Contreras also mentions something that happened to him in 2011, when he reported an issue regarding Alt + Tab behavior just to hear from GNOME developers that there was no bug, and only after almost 10 years they decide to finally fix the issue.
In another article, also published this year, Contreras tells an even worse story regarding one particular VTE issue that sums up pretty much the GNOME way of handling code and human interaction: not only this issue should have never existed, but the subsequent attempts to fix it involved terrible code practice that didn’t properly fix anything, culminating in the rejection of a working solution provided by Contreras, and the issue report being locked [15]. By the end of his article, he compares the attitude of GNOME developers with the Linux kernel ones, showing that although the kernel team is much larger and relevant, they are much more concerned about the impacts of their work and humble enough to revert any code that has negative side effects on third-party projects.
I experienced a similar story myself. When xdg-desktop-portal 1.7.1 was released, it introduced a bug where the dark theme in GNOME 45+ was not working when running any application as root. I reported the issue [16], but the developers were more interested in dismissing the use case I described than recognizing the bug regression. As usual, they closed the issue without fixing it, and when I talked about their peculiar behavior, they marked my comment as abuse in a clear attempt to shutdown the conversation, so now it’s required to sign in to read it [footnote 5]:
In GNOME 45, Files was released in such a way that when in root/admin mode the file/folder properties dialog wouldn’t open and, instead, would consistently crash the whole application. The issue eventually got fixed in GNOME 45.1, but when I reported it [17], the first reactions were the usual GNOME bullshit:
In GNOME 42 the project adwaita-icon-theme had all third-party application icons removed, providing icons strictly to GNOME applications. When a user reported the side effects, the developer’s reaction couldn’t have been more predictable [18]:
Apps should bundle their own icons.
Not just that: the developer immediately closed the issue and his message received likes from other developers. These guys seem to have forgotten that on Linux there is no way to set more than one icon theme at the same time, and since countless applications rely on an icon theme to provide their icons, the result, again, was a complete mess [19].
A 20-year-old bug in Archive Manager (file-roller) let it keep storing temporary files in ~/.cache folder indefinitely [20]. Some users reported that the total storage can go beyond 100 GB. The issue was reported 11 months ago, and it still hasn’t been fixed. Brodie Robertson talked about it, and it’s worth watching and reading some of the comments [21]:
Example after example, it becomes clear that GNOME lacks proper automated tests, and its developers are too arrogant to care about testing the basics before shipping a new release. Actually, when reading all GNOME 45.x changelogs combined [22], the word ‘crash’ appears 32 times so far, and that’s only what they bothered to fix. But the tentacles of GNOME can reach further lands.
When they released libxml 2.12.2, it was broken in such a way that anything that depends on it would fail to build due to missing headers. This included over 400 applications with zero connection to the GNOME desktop environment, such as Chromium, FFmpeg, VLC, Wayland, Xfce [23]. One week later a new version was released fixing the bug [24].
Five years ago an issue was raised regarding mutter in Wayland not allowing applications to inhibit the screensaver, making tasks like watching a movie something unbearable [25]. The fix would involve implementing support to a well-established Wayland protocol that at that time was already implemented in KDE and Sway. Only four months ago GNOME finally addressed the issue, but not without embarrassing discussions, including GNOME developers trying to bend logic:
Most people either don’t seem to watch long movies on their desktop or just don’t seem to be bothered by the bug.
In one of the discussions about this issue on Reddit, Drew DeVault, the developer behind Sway and many of the Wayland protocols, posted strong words against GNOME [26]:
In March of this year, GNOME released Glib 2.76, introducing an issue that affected numerous third-party applications that, again, don’t even expect to run in GNOME [27]. The consequences were so severe that they had to revert the offending code in Glib 2.76.1, released two weeks later [28]. However, there was a catch: they promised this change would come back in Glib 2.78, and indeed it happened six months later.
The issue causes potentially endless log entries due to a new GFileInfo runtime warning. As a result, GTK+3 had to be patched and also many third-party applications that rely on GFileInfo, such as thunar (Xfce). GTK+2 also got affected, but the GNOME team, responsible for it, stated they wouldn’t invest 2 minutes to fix it because GTK+2 reached end-of-life support.
I decided to write the patches myself, making them available on their Gitlab issue page [29], but they didn’t bother to merge them into the repository, showing once again GNOME team’s indifference to anything outside their use cases. They think they know better, except this time they screwed one of their most popular applications, GIMP, which is still using GTK+2. I offerred my patches to GIMP developers with no credits needed, and fortunately they accepted them [30].
There are countless examples of that: user reports that GTK 4 has blurrier fonts compared to GTK+3, providing screenshots that clearly demonstrate the problem, then the developer closes the issue saying it’s not a regression, even when most people say the opposite [31]; user reports that Archive Manager doesn’t allow drag and drop to Files when running in Wayland, the developer locks the issue, which is still unfixed after 5 years [32]; user opens a request for type-ahead search to replace the insane recursive search in Files, and despite the vast majority of users agreeing with the request, it gets closed, and after 5 years it remains unaddressed [33]:
In the Linux realms GNOME is vast and its code is not primarily written by volunteers, as many believe, but by paid employees from other companies, especially Red Hat. GNOME Foundation is a company, it has an annual budget (recently it received 1 million euros), directors, managers, deadlines, etc [34]. There are big players behind it, such as Red Hat, Canonical, IBM and even Google.
It’s the default desktop environment in many major distros, and even if you don’t use it, most likely some GNOME projects are on your system anyway. And that’s the scariest aspect of GNOME: it’s not just a desktop environment, but a whole ecosystem with so many moving parts spread all over Linux distros.
I’m pretty sure there are good people working in GNOME, and we shouldn’t expect any person or project to be perfect. The problem here is the scale, the amount of power in the hands of a few arrogant and amateur developers who work for a broken institution that, overall, doesn’t encourage dialog but rather autocratic bad decisions that result in very deficient software.
It’s no accident that Linux Mint distro has its own fork of the GNOME desktop environment called Cinnamon. MATE is also a fork of GNOME. Not to mention Unity, another GNOME fork, created by Canonical. Years ago, LXDE desktop environment gave up on GTK and migrated to Qt, giving birth to LXQt. Pop!_OS distro is replacing GNOME with their COSMIC desktop environment. Budgie desktop environment announced that they are dropping GTK in favor of a yet-to-be-announced toolkit due to many disappointments with GNOME [35]. Even Valve decided to go with KDE Plasma instead of GNOME when they released SteamOS 3.0 for their Steam Deck portable gaming device.
Many signs indicate that the most sane option is to avoid GNOME projects as much as possible, especially the desktop environment. So don’t use it, don’t recommend it. Luckily, there are many better options, such as Xfce, LXQt and, if you are more keen to fancy stuff, KDE or even Cinnamon. And I mean better in basically every possible way.
Discussion:
Hacker News
Linux Questions
[1] It’s worth mentioning that until very recently, Settings would always open in the screen section where you left the last time, regardless, and just then would it switch to the requested one. This tells a lot about the quality of GNOME code.
[2] Wayland will certainly prevail over X11, but its overall performance is still not on par with X11, especially when using Nvidia cards, not to mention countless issues and annoyances, so the user shouldn’t be expected to run Wayland in all scenarios (https://www.phoronix.com/review/wayland-nv-amd-2023/).
[3] Performance in mutter and GNOME Shell can be so frustrating that Arch distro has build scripts to apply patches that haven’t been accepted upstream (https://aur.archlinux.org/packages/mutter-performance) (https://aur.archlinux.org/packages/gnome-shell-performance).
[4] For example, the user boots with no xdg-desktop-portal-gtk installed, opens any browser, installs xdg-desktop-portal-gtk and finally opens flatpak version of Boxes (GNOME virtual machine). If the user then tries to create a new virtual machine from an ISO, the file chooser dialog won’t show up, requiring the xdg-desktop-portal process (not the gtk one!) to be killed. That’s entropy in pure state.
[5] By looking at what I wrote it becomes clear that I was very respectful:
This is the third of three articles on GNOME:
https://medium.com/@fulalas/gnome-42-the-nonsense-continues-7d96c3287f7
https://medium.com/@fulalas/gnome-linux-a-complete-disaster-feb27b13a5c2
