A unique thing that desktop environments on Linux get is extensions. And they aren’t limited to the latest AI product being shoved down your throat (hi Windows)! The most popular desktop environments like GNOME and KDE offer extensions, but not all is as okay in extension land as you might think.

I want to unpack some of the extensions that I really like and the situation involving desktop extensions is more precarious than most people know.

Polonium (KDE)

Have you ever wanted to do window tiling? You know, where your windows automatically arrange themselves, some would say dynamically? Well, there used to be this thing called Bismuth, which would automagically rearrange your windows just like a tiling window manager.

Except people are reporting bugs, especially on newer versions of Plasma and the developer is stepping down. I made video about this situation last year and quite a bit (hasn’t) changed since then. Bismuth is still up on GitHub, but despite development basically grinding to a halt. The long story short is Bismuth relies on the KWin’s APIs from Plasma 5.26 and is incompatible with Plasma 5.27 and the upcoming Plasma 6. The maintainer also had some personal issues and stepped away because he didn’t have enough time. Let this serve as a reminder that most developers are not on company time or payroll. They are normal people who have to commit their free time and talent, often for little to no gain.

The result was a fork of Bismuth called Polonium (you know, as in the radioactive metal, because Bismuth is a metal?). Polonium targets KWin’s new APIs and supports the same dynamic window tiling that Bismuth did. I encountered a few KWin crashes when I was using it, but I’m more willing to chalk that up to Nvidia being a pain since they can’t be replicated reliably. Polonium is pretty cool in that it’s Wayland-focused and building on the age old work of Bismuth.

However, this is where the plot thickens. Recently, the lead developer of Polonium, zeroxoneafour, has said the current codebase for Polonium is unsustainable. This is due in large part that the original KWin APIs from KDE 5.27’s early days and growing incompatible with the constant development of KDE.

Since Polonium is from mid-2023, it has since accrued technical debt as KWin begins to clear up and on the eve of Plasma 6. What needs to happen now is that development of KWin continues to refine and make sure the protocols that Polonium uses to work stabilize in Plasma 6. It’s a complicated situation, but the basic gist is Polonium is playing catch-up with the large, ongoing changes in the upcoming Plasma 6. zeroxoneafour has also said the only solution to fix Polonium’s technical debt is to completely rewrite it from the ground up, which the current beta version out now is a proof of concept. If you want to help them and you have experience with TypeScript, you can go visit their GitHub.

GNOME Extensions

Unfortunately, picking GNOME as a platform hasn’t been smooth sailing. The long story short is the GNOME developers have been making a lot of changes to their windowing compositor Mutter and its components. The most important change is moving away from GNOME JavaScript (or GJS). There’s a bit to unpack here.

  1. GJS is a variant of JavaScript similar to TypeScript. But for developers coming in to work with GTK, it’s not totally the same. The primary reason this was changed to make the toolkit easier to adopt or get into.
  2. GJS is different, but not too different. Someone could easily script or program a way to update older extensions to replace GJS with standard JavaScript.
  3. That means that extension makers need to maintain 2 versions of their extensions. Wait, what?

People online are complaining about the fact that GNOME’s extension developers have to maintain extensions in GJS from GNOME 44 and below, and extensions in standard JavaScript for GNOME 45 and above. You’ll hear complaints about how GNOME is an unstable platform that constantly breaks every yearly release and then some.

I want to highlight a problem that I think most people avoid or don’t think about: it’s most software projects don’t have a PR team. Most people didn’t see this in a fancy press statement or in a dazzling video by GNOME’s YouTube channel. They saw this in a blog post, written by an engineer, for contributors. In fact, most people probably heard about it from their favorite content creator reading the news, an online forum like Reddit or Lemmy, or one of the Linux content mill news websites.

The general feeling that people get is the lack of communication, because there is a genuine lack of communication–a communication team. But people continue to treat an open source product as they would a financed proprietary product. GNOME is not and while there are developers who are paid to work on it, it’s nowhere near the level of Windows or macOS. To be fair too, I’m not saying this excuses the poor communication. Even if unintentional, it doesn’t matter how you intended something to come off, what matters is how people perceive it.

The Teetering Tower

But we also need to be realistic about what extensions are. GNOME Extensions and extensions in KDE are not built with specific functionality in mind, nor are there convenient APIs for them to use. There’s no one framework or stable thing to build around and this sounds crazy, but it’s similar to extensions in your browser.

Chrome and Firefox have a stable framework for their extensions, but like KDE, the APIs are constantly being poked and probed by their developers and the W3 to see what people use and what isn’t. Browser extensions are rather constructed around a bunch of frameworks to do things in real time and limit the extent of what they can do for performance and security reasons.

The same is true with extensions in GNOME and KDE. Your extensions need the ability to specific things in real time. For example, I use Caffeine on GNOME, which prevents my computer from falling asleep when I do specific things like play full screen videos or games. But think about what goes into this: the extension needs to be able to read GNOME’s APIs to know that there is a full-screen window or specific application open on your device. All of this needs to be done in such a way that it doesn’t hinder the performance either because people will complain if an extension slows down their system!

GNOME Forge

But what does this look like? I have been bombarded with comments about how I got window tiling in GNOME. It’s an extension called [ you some manual tiling like you’d get in i3 or Sway. But like Bismuth and Polonium, Forge is not immune to this cycle.

Earlier last year, Jose Maranan, the lead maintainer of Forge announced he’s no longer able to keep working on the project. And this has affected the project because a lot of the Forge developers are trying to pick up the slack with Jose helping them and figuring out GNOME 45 porting and some annoying bugs like why the UI will suddenly become English for non-English GNOME users or the extension breaking on touchscreens.

In my observation on GNOME 45, the toggle menu is totally absent in the GUI, but can still be accessed through Matthew Jakeman’s Extension Manager. However, I’m not a power user of Forge. I just have 2 windows open at a time and mostly adhere to vanilla GNOME. If GNOME implements its tiling, I’d probably switch to that immediately.

Closing Thoughts

But while most of these problems are here, I feel it’s also important to acknowledge that GNOME and KDE have zero obligations to extension developers. They can’t just stop developing their desktop environments because a couple extensions aren’t just right. It’s the same reason Firefox and Chrome break extensions frequently because they constantly touch their APIs.

Here’s the part where I tell you I’m going to flip flop to another software, but not this time. I’m too much of a technological polyglot to settle anything properly anyway. I will solemnly accept it and will continue to advocate for the assistance of extension maintainers. It’s a thankless task and you’ll find that a lot of the people in these repos are just users like you and me. I don’t have the time to properly learn JavaScript and GNOME/KWin APIs, but I can use my platform to at least highlight where help is needed the most and why you should lend a helping hand to your extension maintainers.

My Favorite Desktop Extensions

  • Polonium for dynamic window tiling on KDE
  • Forge for tiling windows on GNOME. Given how I use GNOME, it says me the extra key presses of manually tiling windows.
  • Caffeine to disable sleep/lock for a set time or for specific applications.
  • Dash to Panel to add a clone of the vanilla GNOME panel to my other display purely so I can pretend to check the time.
  • AppIndicator and KStatusNotifierItem Support for legacy system tray icons. I prefer GNOME’s “background apps” menu, but it’s unfinished as of time of writing.

Referenced

9to5Linux is a content mill

I can’t say with definitive proof that the reference to plagiarism by 9to5Linux, but at most, it’s just cheap rewording of an official Asahi Linux blog post with little to add except the link to give them more clicks about Arch Linux ARM.

At a minimum, 9to5Linux is a worthless content mill and you should just learn how to use an RSS feed.