GNOME 45 has reached the RC stage, but it has a change that will impact more users: it’s altering the way extensions work, which will impose strict versioning requirements.
The GNOME project has tagged the latest version as 45.rc, which means it’s nearly final. The NEWS document has a modest list of about 20 changes, but they are tweaks rather than big ones. We looked at the “Riga” beta a month ago, if you want to know what to expect.
What we suspect will have more wide-reaching impact isn’t mentioned in there at all, but is described in a blog post from GNOME developer Florian Müllner. He summarizes it himself on his Mastodon account:
There is a lot of technical detail in the blog post, and it somewhat hides the core point – which is that this stuff is going to matter to everyone using customized GNOME setups, such as all Ubuntu, Zorin OS and Pop!_OS users.
As of GNOME 45, the way that extensions work is changing. This will be interesting to Javascript developers, and important to people developing their own GNOME extensions. However, The Reg FOSS desk is neither, so all we can offer is an attempted summary.
As we described when the project turned 25, the desktop is implemented in Javascript. Since GNOME 3, GNOME Shell is a Javascript plug-in to the Mutter window manager. On its own, GNOME Shell isn’t very customizable: unlike GNOME 2, or most other desktops, which let you move panels around, add and remove or reposition things on those panels and so on, GNOME Shell is quite locked down, which helps the project develop and preserve its strong visual brand.
If you don’t like how things are arranged, the only way to change it without reprogramming it yourself is adding GNOME Extensions, which are effectively chunks of Javascript code that redefine how the shell works.
Previously, the GNOME Javascript runtime, GJS, which is based on Mozilla’s Spidermonkey, had its own system for importing external Javascript modules. Many frameworks have their own such systems, and Dev.to has a handy summary which compares several of them.
As Müllner puts it:
Mozilla itself has a helpful, richly illustrated “cartoon deep-dive” into how the new system works.
GNOME 45 switches to this new ECMAScript Modules system (ESM for short). The upshot is that extensions for GNOME 44 and earlier won’t work in GNOME 45, and extensions build using ESM won’t work in older versions. If you have an existing extension, you’ll have to port it to use ESM.
So what does this mean?
GNOME’s extensions ecosystem is large and rich: there are lots of them, and even if you’d never dream of reconfiguring your desktop, if you use one of the big-name distros then it’s already been done for you.
Ubuntu adds its own dock, which is a version of the existing Dash to Dock extension. Zorin has a whole suite, which transform GNOME into a choice of layouts similar to various versions of Windows and other OSes. A version of the Zorin code led to Dash to Panel.
If you want to do your own customization, it’s already quite complicated. Firstly, there are several ways to do it. You can simply visit extensions.gnome.org, but this requires both a browser extension and a connector you must install into your distro. However, that didn’t work with sandboxed browsers, such as Ubuntu’s Snap-packaged Firefox and Chromium, so there’s also the GNOME Extensions Manager app.
Müllner’s blog post says:
What this means for several distro vendors who offer customized GNOME experiences is that they now have a bunch of extra work to do. That, though, is their problem – it will be different for volunteer solo developers: it could take quite a while for their projects to catch up. We suspect that this may cause a small extinction event among GNOME extensions, with many never making the leap across this new divide.
If you use a heavily customized GNOME environment yourself, that means that you may well lose it with the next release.
However, we have to point out that this has always been an issue with GNOME extensions. Extensions can clash and conflict. You can make your Dash into a Dock or make it into a Panel, but if you try both at once, things will get strange.
Almost every available extension has a list of supported GNOME versions, and there’s usually a gap after a new release of GNOME comes out. This vulture has been using Ubuntu since its first release, and when the distro switched back to GNOME we invested significant time and effort into finding a set of extensions to make the new desktop more comfortable, aiming for Unity-like efficiency. We found Extend Panel Menu, Pixel Saver, TopIcons Plus, the Nemo file manager, and more.
If you check the lists of supported Shell versions for each of those, you’ll note that they all stopped working many years, and many GNOME Shell versions, ago. The authors stopped trying to keep up with the moving target of GNOME’s codebase. Extend Panel Menu was replaced by Panel Indicators, which was then replaced with Big Sur Status Area, then supplanted by a continuation with the same name… Then they gave up.
For years now, the result has been that if you customize your desktop with hand-installed extensions, then the next time you upgrade your OS, the desktop will inevitably fail because some of the extensions won’t work with the new Shell version – or worse still, they will fail to load correctly and prevent the shell from loading.
Two possible ways to look at this occur to us.
On the one hand, the negative interpretation: Increased homogeneity seems to be what the GNOME Foundation wants. It is keen to promote the GNOME Brand. Thus the enforced Adwaita theme and ensuing controversy. For instance, we thought it was a sad change that EndlessOS 5 lost the distinctive desktop from older versions. But then, Endless Foundation CEO Robert McQueen is also the GNOME Foundation president.
On the other hand, the positive interpretation: Adopting an upstream standard for handling modules should be a good thing. This could lead to proper versioning and alignment between GNOME and extensions. Once developers move to the new system, it could prove easier to keep extensions maintained and compatible from then on. Although doubtless many won’t make the transition – because many didn’t survive the move to GNOME 40 – this could result in a more robust extensions system and easier updates from GNOME 45 onwards.
Perhaps GNOME could even get more serious about properly supporting and integrating extension versioning and handling, for instance offering some kind of automated upgrades, automatically disabling extensions with obsolete versions. Maybe even a Safe Mode that disables all extensions but gives you a working desktop. We can dream, right? ®
