Future of argos discussion (co-maintainer, maintenance-only)

[ElijahLynn]

Per #106 (comment):

I don't use GNOME Shell anymore. I switched to Sway a while ago and have not looked back since. Therefore, Argos is in maintenance mode as far as I'm concerned.

And #106 (comment) by @real-or-random:

Do you think it makes sense to add a big "maintenance mode" notice to the README? Maybe it's possible to find a maintainer.

Let's discuss the future of argos here, some possible options:

• Add a new co-maintainer, solicit candidates
• Do nothing - Would lead the community to choose a fork to be new upstream and possibly have to change the name for license compatibility (would require package manager updates)

@p-e-w Do you have any opinions on what you would like to happen to the future of argos?

[p-e-w]

Thank you for starting this discussion. The question is not only who will maintain Argos in the future, but whether it can be maintained at all in the long term. The GNOME developers have made it crystal clear through their actions over the past years that they

• are unwilling to provide any stability guarantees for the GNOME Shell API, even between minor releases.
• consider it acceptable to break every single GNOME Shell extension on every single GNOME Shell release (this was in fact the default for the first few years of GNOME 3's existence, and has in practice continued because of massive API breaks in almost every release).
• consider less than two months from an initial pull request that introduces such an ecosystem break to its public release in GNOME Shell to be sufficient, with no outreach or deprecation period whatsoever.
• are willing to make not only breaking API changes, but changes that break the API so completely that it is not possible to write code that works both before and after (ES6 classes).
• might occasionally let multiple months pass before approving extension updates submitted to the official extension repository (happened to Argos in 2018).

For all practical purposes, GNOME Shell development operates as if extensions, and the people who make them, do not exist. Argos calls itself a "GNOME Shell extension", but in reality there is no such thing. There are only "GNOME Shell 3.30 extensions", "GNOME Shell 3.32 extensions" and so on. An extension that works with one Shell version may or may not work with another, and there is no way to tell without trying to run it on the other version. I estimate that at least 80% of extensions in the official repository do not work with the current GNOME Shell release.

GNOME is probably the most polished desktop environment ever created, and the only one with a singular, coherent vision. Unfortunately, it has been obvious for a while now that extensions are no longer part of that vision, if indeed they ever were. After nearly a decade of GNOME Shell, you still can't even update an extension without using a crappy browser plugin. Shell extensions are dead, they just haven't noticed it yet. I sincerely wish it were different, but the facts permit no other conclusion.

That being said, if someone else believes that Argos would be a worthwhile experiment to continue, I am willing to lend them my (limited) support towards that endeavor. In particular, I am willing to add (one or preferably multiple) collaborators to the Argos repository. If you are interested, please announce yourself in this thread.

On a somewhat unrelated note, it appears that BitBar, the macOS application Argos was inspired by and is compatible with, is also unmaintained, with just 4 code commits since 2016. Of course, Apple understands that if you want people to develop for your platform, you can't break everything every six months, so BitBar nevertheless still works with the latest macOS version.

[LaurentOngaro]

@p-e-w ,thanks for your answer and your work.
I agree with all the points you write in your comment. After having used KDE for a while I really appreciate the polish and the coherency of Gnome.
But the management of its extensions is really disappointing, because they are indispensable to have a full featured desktop but also nearly unmaintainable due to the lack of consistency in the API.
I think that's confirm , in some points, the creator's of the cinnamon desktop and their vision

[aggsol]

Is there maybe another approach like being compatible with BitBar and Argos but provide the same functionality for GTK(?) but outside of the GNOME Shell. That would of course require a new implementation but could achieve two things:

1. Get rid of the GNOME Shell problems
2. Create an actively maintained project

Is there something like this already? Would it be feasable?

[real-or-random]

I think we should at least maintain a repository where compatibility fixes such as #106 and #111 are merged. As long as there are incoming PRs for those issues, that makes sense and works for some people. Maybe it makes sense to have separate branches for the few last major versions.

I think the question is if @p-e-w's statement is still true:

I will continue to review and merge pull requests, and occasionally release a new version on extensions.gnome.org.
(see #75 (comment))

If he can confirm this, then it's possible to do this in this repo, which would be the cleanest. Then we should do some testing on older versions to help him make sure that these PRs can be merged or simply merge them only in specific branches.

[p-e-w]

The statement quoted by @real-or-random is still true, but I'm simply at a loss for what to do right now. GNOME Shell 3.36 isn't even released yet, but people are already expecting Argos to support it. But the fix (#111) most likely breaks Argos on all previous versions of GNOME Shell! It's a complete disaster, once again.

What I will emphatically not do is turn this repository into a mess of Shell version-specific branches. That would be the definition of "unmaintainable" for me. Then fix "W" is supposed to go into branches "X" and "Y", but not into branch "Z". That's kernel-level maintenance complexity, which is simply ridiculous for a damn desktop plugin.

But as stated before, I am open to adding additional collaborators to this repository. If they feel up to the task of keeping Argos working across multiple Shell versions, they are welcome to try. By myself, my informal policy is to merge a fix when I believe that the majority of GNOME Shell users require it. For GNOME Shell 3.36, that is not yet the case.

[raspbeguy]

Hoping this fits in this thread :
AFAIC I was using GNOME only for Argos. Making menus that easily was so convenient. Before that I was using i3 with py3status to make my own widgets but they were not full menus and it was way harder to design. Now that Argos is broken I just don't have any reason to use GNOME anymore and I switched to Sway. Now I am looking for a menubar for sway which can handle GNOME-like menus (and not simple widgets) and as simple as Argos (and if possible, Argos syntax compatible to be able to use my scripts).

[LaurentOngaro]

@raspbeguy
Argos is STILL running !!!
You can use the master version for gnome < 3.36 and the patched one for gnome 3.36. The only boring issue, is the log flooding by Js warnings.
It occurs on every refresh of the scripts you use.
For me, as I'm mainly using Argos as a fast customizable menu, I changed the refresh rate to 24 h and there is no more flooding.

For sure it's a rather "unstable" solution... but it works as it for me

[raspbeguy]

Not sure I want to bother using a non-master version of it.

[real-or-random]

But as stated before, I am open to adding additional collaborators to this repository. If they feel up to the task of keeping Argos working across multiple Shell versions, they are welcome to try. By myself, my informal policy is to merge a fix when I believe that the majority of GNOME Shell users require it. For GNOME Shell 3.36, that is not yet the case.

I'm willing to help by managing and testing PRs. The issue is that I don't want to do this alone, my JS experience is pretty limited. Is there somebody else willing to help? Then we can split the work better and it's less effort.

We will see if I think different branches are a good idea. I think we should try at least something in this direction. It fits the model on extensions.gnome.org. I think we could restrict ourselves to fix only critical issues on older versions (that should basically never happen), no backport of improvements or normal bug fixes but tell people to wait for their GNOME update. This model seems to to work for other extensions: JasonLG1979/gnome-shell-extension-mpris-indicator-button#30 (Then we don't really need branches for older versions unless we have a critical issue, but also they won't hurt.)

[JasonLG1979]

Supporting a bunch of different versions will make you go crazy. Over the past few years that I have been an extension dev I've found what works for me is to basically do a rolling release on top of the most current version of GNOME Shell. I don't do releases other than what gets pushed to the extensions site. I only support the most recent version from the extension site and git master. (which are never ever far off each other) As far as git goes, I only have a master branch.

As far as dealing with breakages between versions. GNOME Shell releases shortly before Ubuntu and Fedora, so generally I'll fire up an alpha or beta of both of those in a VM and fix whatever is broken.

I try to be zen about it. I can't really remember a release that didn't break something. I just accept it. The lack of an API can be frustrating but I like to think that it means that there are no rules. It's a double edged sword.

[mwilck]

@p-e-w, being one of the co-maintainers of the hamster shell extension, I feel your pain.

What I will emphatically not do is turn this repository into a mess of Shell version-specific branches. That would be the definition of "unmaintainable" for me. Then fix "W" is supposed to go into branches "X" and "Y", but not into branch "Z".

For the hamster extension, we came to the opposite conclusion. Creating a branch in git is a trivial and quick operation. The "mess of branches" isn't so bad after all, if development work focuses almost entirely on adaptations for new GNOME releases (which means that "fixes" basically only go into the master branch). Thus, for hamster, we basically follow @JasonLG1979's approach, keeping the option for branching open if it might become necessary in the future (e.g. for an urgent security fix).

Maintaining a single code base that works across all GNOME releases is impossible, AFAICS. An even if I'm wrong, compatibility code would be messy and hard to read. At any point in time, there are active Linux distributions shipping at least 4 different GNOME versions. If you don't take compatibility patches for the newer versions, "branches" will emerge in the form of forks, which is worse. It gets really bad if other people start uploading forks to extensions.gnome.org. It has happened to hamster, and we're still working to clean up the confusion.