GNOME Shell architecture feels fundamentally flawed (panel/extensions)

Desktop
,
1

I like the GNOME UI design philosophy and i use GNOME as my primary DE. In terms of UI/UX it works well for me, but from a technical perspective the shell/panel and extensions implementation seem to make the whole system really (and unnecessarily) complex and unstable.

It boils down to a few things:

1 - Stability

I have two window managers installed: Mutter (w/ GNOME Shell) and Hyprland (w/ Waybar), visually they look about the same.

In 6 months i have never been able to make Hyprland crash, not a single time. In the same period, Mutter (47 / 48) has been crashing on me multiple times daily. Crashes on Mutter are catastrophic, meaning that the whole desktop just vanishes and i’m back at the login screen, losing any open work.

This seems to be a result of the fact that everything in GNOME Shell is tied into Mutter as a runtime plugin. So any time that any extension or process does something stupid or unexpected, the whole desktop immediately comes down crashing. This is incredibly frustrating, but also feels really unnecessary.

In Hyprland/Waybar any extension or widget can misbehave and it won’t have any effect on the desktop as a whole. It’s a matter of killing the process from a terminal and restarting it.

2 - Development

I’m a webdev so i’m not completely unfamiliar with JS, CSS and shell scripts. Using Waybar it is extremely simple and fun for me to create a few widgets/extensions that make my life easier. I coded a small backlight/nightlight widget that sits in my panel and allows me to see the color temperature and adjust the display. It took me maybe 1 or 2 hours to script, reloading the widget a number of times to incorporate changes.

With GNOME Shell this process is really awful and not fun, extensions are loaded at runtime so there is no reasonable way to update them dynamically. The workaround approach described in the GJS docs to load a nested Wayland session doesn’t work well for me, because it only allows VESA resolutions for some reason, which are much too small on my High-DPI screen.

Apart from that the inherent instability of the extension system will make the whole session crash again whenever my extension code does something unexpected. Debugging is highly unintuitive and it’s almost impossible for me to find why or where things are going wrong.

It doesn’t help that coding anything in GJS is much more involving, it would probably take me a few days to code and debug the same backlight widget i coded for Waybar in a few hours, mostly because the GJS code is much less intuitive and i would need to read tons of docs first to know where to put what.

3 - Upsides?

There don’t seem to be any performance or stability upsides to the GNOME approach of integrating everything together into one big ball, so i’m struggling to find a good reason why it should work this way. It’s so impractical to develop for, it’s so inherently unstable, that it makes me not want to waste my time.

It doesn’t feel like a coincidence that the extensions.gnome.org site is riddled with un-updated and unsupported extensions. I don’t think anyone enjoys going through the tedious process of debugging and adapting extensions on every single major release. It’s boring but also the consequences are severe each time, since a not properly updated extension will just make the whole DE crash into oblivion.

One of the extensions i use “Draw on Gnome”, made GNOME 48 crash instantly on activation only because a single line of code called the deprecated cursor name POINTING_HAND instead of POINTER.

Is there any future thinkable for GNOME where these things will be separated from each other? Creating a stable desktop/window manager and a simple, separate panel/widget system that doesn’t tie into the base system like this? It would make everybody’s life so much better.

1 Like
2

What are you using that it’s crashing for you constantly? That is not normal.

3

I think part of the problem is some ongoing instability with the AMD gpu drivers over the last year. For some reason Mutter/GNOME Shell appears to trigger those instabilities more than other environments. It results in visual artifacts, freezes and full crashes of the desktop.

The other part is that GNOME Shell is really sensitive to JS code issues in extensions. If you use a number of extensions and carry them from one GNOME release to the next, there is a high chance of upstream code changes suddenly making one or more of them unstable. The extension layer doesn’t seem to be isolated from the core compositor process very much, so small issues like a deprecated cursor name can make the extension, and ‘by extension’ the shell and Mutter crash completely.

4

Neither Gnome nor GTK guarantee stable api between versions.

The onus is on extension developers to port to newer versions.

The user must ensure the extensions they choose are those that support the version of Gnome they are using.

5

That is a different issue. My arguments were that the system’s architecture is not well designed if a single/simple javascript call in a panel extension makes the entire desktop environment crash back to GDM, losing all open work. And that debugging and developing extensions is an unnecessarily complex and involving task, due to the runtime integration.

You can see this back in the amount of unsupported extensions for every new GNOME release, extensions.gnome.org is riddled with them. If the system was stable and forgiving, and if writing and debugging extensions were straightforward, it would be much easier to port extensions over, and/or fix them if needed. Now a lot of people often don’t even bother (again judging from the extensions.gnome site).

In a lot of other environments live-coding and debugging widgets and panel tools is simple, and the underlying system won’t be affected by misbehaving scripts. In GNOME Shell this is not the case, you need to spawn separate shell sessions to test any scripts and small syntactical issues may cause large crashes.

There seem to be no benefits to the GNOME Shell and extensions integration from my perspective as an end-user and code tinkerer, only downsides.

6

All Extensions are thoroughly tested. Did you disabled version checks?

And extensions work via monkey-patching GNOME Shell code. So yes, they are insanely powerful. If GNOME switched to something else, it would be yet another complex thing to maintain and everyone would hate it, coz it would be more limited.

And how many extensions are you using, if I can ask?

7

That would underscore my point, they shouldn’t have to be. The current approach requires an extensive testing process or it would be mayhem. Plenty of bugs still pop up now and then despite the testing/admission process ofcourse.

Instead, the shell and extensions could just live in their own process(es), communicate with an API and not mess with the compositor unless explicitly needed. Firefox doesn’t crash either on every bad line of Javascript. Extensions could run JIT or live, which JS is greatly suitable for, so that it’s easy to develop and test. Most extensions only do simple stuff like paint a widget and don’t need any low-level system access.

And how many extensions are you using, if I can ask?

I currently stopped using GNOME Shell and am running a different window manager w/ panel, so currently none. But i was using maybe 7 or 8, most of them popular ones like User Themes, Dash to Panel and Vitals.

8

Firefox extensions are also more limited compared to those in GNOME. With great power comes great responsibility and its on user to make sure they’re not using conflicting extensions. Sorry, but that’s the only thing that can be said.

9

I don’t feel that’s a good argument, an extension system can be powerful but still run separately in it’s own layer, be stable and relatively easy to develop for and debug. There is just no good reason why high level Javascript code should be directly embedded into a window manager process like this.

10

Feel free to work on it and showcase the world that it’s possible, then. Good luck.

11

I always encourage extension developers to test their code before sending it to the EGO, but if you see a crash after upgrading to a new GNOME Shell, that’s usually because they ported their extension on a beta version and left it as is when the stable version came out.

an extension system can be powerful but still run separately in it’s own layer

No. It won’t. An extension goes through the GNOME Shell source code and monkey-patches it. Nothing can beat that.

Some years ago, we had a discussion about creating a new set of APIs for GNOME Shell extensions, but after some discussion, we came to the conclusion that introducing an API would limit the extensions, and in the end, it would just be a button or switch to turn something off or on.

But extensions do so many different things. As someone who reviews extensions on a daily basis, I can tell you introducing a new set of APIs for extensions would just make some of them go away. Even after many years of reviewing extensions, I still see some extensions even going through more and more things that we didn’t expect them to touch.

Anyway, we give the developers the port guide with each release and even help them with the port by answering questions and sometimes even joining the porting process. The only thing I believe we can do better is to improve the testing and debugging process.

2 Likes
12

“It is not a surprise that most people are aware that a large number of extensions break after each release which causes a lot of friction in the community. Extensions Rebooted is a collaborative effort to address the issues around the GNOME Shell extension ecosystem.” The GNOME Extensions Rebooted Initiative – Sri Ramkrishna

Too bad the project died, last commit is from 2021.

13

It didn’t die. We moved to gj.guide and GNOME Extensions Matrix Channel.

1 Like
14

This doesn’t sound remotely normal, I wouldn’t be so quick on judging where the fault lies without proper investigation… It’s expected that you can run your GNOME Shell instance indefinitely without crashing. For example my instance was started at the beginning of the month after a distribution upgrade. Contradictive anecdotal evidences aside, it’s better to report such issues so the cause can be found.

GNOME Shell already consists of multiple processes - for example screen recording is its own process, calendar integration with the evolution data server is its own process. What currently is not outsourced to separate processes is GUI, and there are two main reasons for this.

One is that we still have the X11 backend making it possible to run on Xorg/Xvnc/… that makes it hard to outsource anything without significantly worsen what is possible to achieve without unacceptable glitches. With the removal of the Xorg backends it’ll open up a possibility to theoretically place whatever makes sense into helper processes.

The other reason is that having everything relatively monolithic opens up a completely different level of possibilities when it comes to extension development. Moving to a architecture where things are split up makes it much more difficult, and it would break any extension that manipulates any GUI element.

With all this in mind, there are already plans/ideas to only support “multip process GUI” in GNOME Shell for certain features, such as lock screen app integration (e.g. receiving a phone call via the lock screen). What else is feasible is up for debate and there is no clear answer.

2 Likes
15

I just want a system where a small JS deprecation in a panel widget doesn’t bring down the whole desktop.
Where it’s relatively straightforward to develop your own basic extensions in a live environment without having to spawn full precompiled compositor processes.
Where it’s easy to see any errors and get clear debug information to fix things.
And where you can use 3rd party extensions without worrying about them not working anymore in 6 months, since they have to go through an elaborate certification process each time to get approved by some committee.
None of those things are currently the case with GNOME shell. It’s just not fun to work with as a non-expert, and it feels unstable due to some of the low-level integrations.

The other reason is that having everything relatively monolithic opens up a completely different level of possibilities when it comes to extension development. Moving to a architecture where things are split up makes it much more difficult, and it would break any extension that manipulates any GUI element.

I just don’t know what kind of tangible benefits that gives me.

I should stop ranting since it obviously isn’t helping me make friends around these parts.