With the advent of the new release of GNOME 3.38 – we want to start focusing next cycle on improving the GNOME Extensions experience.
I’m using my blog for now – but we will have a extensions blog where we can start chatting about what’s going on in this important space.
What Extensions Rebooted Initiative is about
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. We want to start addressing this by making a number of policy changes and technological improvements while building a sustainable community.
Here are some highlights on how we plan to creating a better experience for GNOME extensions:
- Proper documentation of how extensions work, reasonable expectations to be an extensions developer, participating in the GNOME extensions community.
- Build CI pipeline (a virtual machine) for extension writers to test their extensions prior to GNOME releases.
- Centralizing extensions for break testing on the GNOME gitlab space
- Creating a forum for extension developers and extension writers to work together for the GNOME release cycle
To appreciate and expand on the details of this project, you should check out the Extensions Rebooted Bof on the last GUADEC and my GUADEC talk.
The Extensions Rebooted initiative’s ultimate goal is to get the extensions community to work with each other, have closer ties with GNOME shell developers and provide documentation and tools.
Extension writers are encouraged to get involved and build this better experience. Consumers of extensions are requested to help spread the word and encourage extensions developers to participate so we can all benefit.
To get involved:
GNOME Discourse:
- Use the “extensions” tag when submitting questions about extensions.
Chat:
- There is an extensions matrix/irc channel (matrix preferred) located at: https://gnome.element.io/#/room/#extensions:gnome.org
Gitlab:
- If you’re interested in helping develop tools, tests, and most importantly documentation then please visit https://gitlab.gnome.org/World/ShellExtensions/extensions-rebooted
The success of GNOME extensions cannot happen without participation and contributions from the community and so I hope that all of us who write extensions, who are interested in providing technical documentation, and have experience in CI pipelines/devops can come together and make extensions a sustainable part of the GNOME ecosystem.
The next post will talk about using a pre-built VM image that extension developers can use to test their extensions and have them ready to be used prior to GNOME 3.38 appearing on distributions.
Glad to see this — extensions are a vital part of user happiness with GNOME. There are some very popular ones which probably should be integrated natively (Caffeine, I’m lookin’ at you!), but overall one thing I’ve learned is that a lot of people have one or two they can’t live without — but never the same one or two.
Also, you can use a Fedora 33 pre-release image from https://www.happyassassin.net/nightlies.html to test too. 🙂
Thanks! Yes, it was time to get some leadership around it and start pushing to make sure that we give extension writers the information and tools they need while at the same time hold them accountable in supporting their extensions. We take a lot of heat as an organization because of extensions and I know that we can come up with a better experience with a little effort.
Yes, we don’t really have a process where we evaluate extensions as possible features that should be part of the core experience. For that we need to start collecting data and make data driven decisions. We’ll get there eventually 🙂
Thanks for the initiative. Hope it’s not too late.
The #1 pain point for extension developers is that the APIs change from release to release, breaking extensions so badly on a regular basis that not a few have simply given up trying to fix them. CI might be helpful, but the main problem seems to me that the core developers simply haven’t cared about not breaking extensions.
It’s kind of frustrating how second-class GNOME Shell extensions are. One of the reasons I do not use GNOME is that for the experience to be palatable to me, I need half a dozen of them. And because nobody cares to make the experience of maintaining extensions mostly painless (i.e. don’t break them on every GNOME Shell release, forcing extension authors to have to try to figure out how to fix them every time), I can’t trust to use GNOME for my day to day experience.
I hope this is something you’ll tackle and try to fix…
It is nice that you want to give extension developers better testing infrastructure, but what I was expecting when I read of this initiative was an effort to create some sort of reliable stable API that works across GNOME releases.
I suspect that the issue is that extensions typically depend on a single maintainer, who is probably not interested in rewriting their extension every half year or so. So I guess the most sustainable solution would be to introduce a stable interface that keeps backward compatibility across releases.
The goal is to make the experience of writing extensions better and to give resources to extension developers so they have ample opportunity to fix any issues with extensions when new versions of gnome shell comes out. That way when the new release of GNOME becomes available for your distro it isn’t broken or there is a process to make it unbroken. The other is to know how many extensions are broken and have some metrics around it.
We’ve had discussions around a stable api – but any stable api we create must come from the community and must be community supported. There isn’t enough resources for shell developers to do this – they are focused on shell. To have them also shoulder the burden of extensions is not realistic. Instead, we will work on solutions that are sustainable and that means active participation from community people to build such a thing.
Also keep in mind the technology around extensions is monkey patching – and so there can never be a concept of stable api because we can’t advertise a stable api nor can we force extension writers to use it given the nature of monkey patching.
Should I be worried about making a stable extension API not being mentioned in this article? Isn’t that the core issue?
While I’m a daily GNOME user, I admit I have little understanding of the technical details underneath. But: I remember reading a discussion about a possible “GNOME 4” a year or two back. This document claimed that GNOME’s extensions model was a millstone around the neck of GNOME performance, a permanent impediment. The problem was that all rendering had to be done in one thread, and this thread jumped back and forth between native code and Javascript. This didn’t sound great to me; I like extensions, but I’d rather have a speedy, performant window manager.
My question: is that true? and, if so, will Extensions Rebooted do anything to address this?
Are you talking about extensions that not only break with every GNOME update, but also fail to update for 3-5 years?
Maybe first it is worth solving the problem with unreasonable consumption of resources? GNOME has almost no customization compared to KDE, but it requires 2.5 times more CPU, RAM, i / o disk.
By the way, GNOME has almost no customization options without manually editing the config files. A huge, simply gigantic number of parameters are hidden from the user. Maybe you should give the opportunity to fine-tune?
Or solve the problem of normal compatibility with QT applications?
Or solve the huge problem with an ugly and patchy interface?
Maybe you should not delete messages in the notification history on click? And give the user a choice, for example to copy them.
Maybe you should kick the designers out of the team, and hire programmers to replace them? Maybe these programmers will stop making a failed MacOS clone.
An adequate person after installing GNOME – immediately starts using Arc Menu and Dash to Panel. Because it is impossible to use the dock, the standard application menu, the top bar. Maybe you should finally remove them and make their installation optional?
Note that I didn’t say a word about real bugs. I can talk about them almost endlessly. I was just talking about GNOME’s hostility towards the user. And I can definitely talk about this endlessly.
And remember always, the share of linux on the desktop OS market is low – not only because of the lack of software analogues (win, mac). But above all because of the standard DE that comes with all linux distributions. And 90% of the time, that DE will be GNOME.
I recently tried to report bugs and could not find any convenient method for this.
to report bugs, you should create an account on gitlab.gnome.org and report it there. I’ve ignored the rest of your screed as they are not pertinent to my blog post.
Extensions that fail to update every 3-5 years is on the shoulders of extension writers. We don’t have control over what extension writers do. Part of the initiative is to build a community and that’s what we are doing so that we can share best known practices.
I am not aware of any effort to replace GNOME Shell with something else – which is what would have to happen based on what you’re talking about. Large changes like GNOME 3 is not going to happen – instead it will be incrementalism. GNOME performance has been addressed and is continuing to be addressed. I think the last 3 or 4 releases have shown a lot of changes. I’m not going to get into this whole thread model. As far as I know it has been addressed in other places.
There is no way to make gnome shell api stable because of how gnome shell extensions are implemented. There are some other methods that could be used but it requires a community to maintain stable bindings to gnome shell to do that.. think of a library that will provide apis that traps into the gnome shell.. every release we deal with the breakage and fix the library so that extensions don’t break. But that can only happen with a large community that is willing to support that model.
Please, please, do something like recommended extension on Firefox. It will be so much better for security.
Heya,
Will it be possible to write GNOME shell extensions in anything but (the brittle) JavaScript?
Srid
Unfortunately no, extensions extend gnome-shell which is written in javascript. I think your question was fully answered on the extensions matrix channel I believe.