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.

[mwilck]

I've come up with an argos version that supports GNOME 3.26-3.36. It can be inspected here. I believe GNOME < 3.26 is supported as well (or could be with minor fixes), but I haven't tested anything below 3.26 so far. Note that the code linked contains some other, unrelated fixes as well; details in the commit list.

It turns out that, for argos at least, making these backward-compatible changes is not that difficult after all. To achieve my goal, I had to sacrifice the clean object-oriented structure in menuitem.js (the constructor function is defined outside the class body). The main problem is the different object initialization between GObject classes and plain ES6 classes. I personally believe that that's worth the broader GNOME shell support that my changes provide. The overall function and readability of the code is not affected.

I've deliberately not created a PR for the p-e-w/argos repo, because I don't want it to look as if I wanted to take anything of @rammie's merits (#111).

Comments and suggestions for improvement are highly welcome.

[LaurentOngaro]

That's a great news !
I've posted an issue yesterday because the version I was using was definitively not compatible with Gnome 3.36.2 (updated a few days ago)
I'll test it right now.

Many thanks

[LaurentOngaro]

I've tested it on 3.36.2 and it does nothing.
I've no icon in the top panel
more details on the following post

Am I doing wrong ?
What Gnome version do you use ?

[demystifier]

Thanks @mwilck, glad you are trying to keep this awesome extension alive
it worked well for me on 3.36.1

[LaurentOngaro]

It was working for me on 3.36.1 version too, but not on the last 3.36.2 version.
The code can't be simply patched because the removal of the AltSwitcher object in the latest gnome extension API has a deep impact on the implementation used by p.e.w.

I'll try to do my best to code a new version as fast as possible, but I've plenty of things to do and gnome extension development lacks of support and documentation for a beginner in that domain.

[mwilck]

Strange, AltSwitcher seems to have been removed in 3.35.2 already - 147a743d8d79 ("system: Replace action icons with regular menu items"). How is it possible that this was regression in 3.36.2 for you?

[mwilck]

@LaurentOngaro, have you tried simply copying the removed AltSwitcher code to the argos code base?

[LaurentOngaro]

I know that's strange because it was running for me on version 3.36.1

Perhaps I make something wrong.
But I've tested nearly all the version mentioned in this thread without success.

And, whatever, the AltSwitcher method is not in system.js anymore.
Perhaps the gnome shell was using a kind of binding or kept this code alive until now.

I've tried to make the smallest possible changes to the argos code and even to add the missing method, but the system.js file has heavily been changed, so I failed.

My knowledge of Gnome extension development was too light until now, but I'm currently trying to improve this skill

[LaurentOngaro]

Strange, AltSwitcher seems to have been removed in 3.35.2 already - 147a743d8d79 ("system: Replace action icons with regular menu items"). How is it possible that this was regression in 3.36.2 for you?

Moreover, how was it possible that argos worked for me with this removal if it occurred in 3.35.2 ?

[mwilck]

Strange, AltSwitcher seems to have been removed in 3.35.2 already - 147a743d8d79 ("system: Replace action icons with regular menu items"). How is it possible that this was regression in 3.36.2 for you?

Moreover, how was it possible that argos worked for me with this removal if it occurred in 3.35.2 ?

Maybe the AltSwitcher issue was a Red Herring. I had no argos scripts using alternate=true. I added one now, and it did not cause argos to crash or not run at all. Just the "alternate" functionality (i.e. the Alt key) didn't work.

[mwilck]

I've pushed two more commits to my GNOME-3.36-compat branch to fix the AltSwitcher issue mentioned above.

[LaurentOngaro]

thanks Martin, I test it right now.
I did not use alternate too, But I see no other issue in the log that can explain why argos does not work on 3.62.2 version

[LaurentOngaro]

IT WORKS again !!!
the log is clean, no longer warnings
I've made a deeper test
The strange point is that I'm used to use a symlink for the script loaded in Argos in ~/.config/argos since months, and now it's not longer working with this method
When I replace the symlink by the script is was linked to, Argos works again.

Issue solved, many thanks

[jefferyto]

I think having users install this extension outside of the "normal" extension installation process would lead to an even worse user experience than having a confirmation window. Users would have to repeat the (manual) process for every update.

I don't think a confirmation dialog is necessarily a bad thing. People rarely read documentation or READMEs. dconf Editor has one:

Firefox has something similar for about:config as well.

[jvonhoff]

I agree with both of the posts above -- I think that a short-term github release "this fixes Argos for Gnome 42" would be fine for most Argos users, but I also tend to think that Gnome devs are pushing toward a larger vision (a Gnome eco-system?) and having Argos on the extensions.gnome.org website is pretty important for usability, security, etc. For instance, I use APKs I get from F-Droid, but I'd never expect my parents to use F-Droid, so the Google Play Store is more appropriate for them. I see github as F-Droid, and e.g.o as the Play Store. For mass adoption, I think Argos should try to stay on e.g.o.

If a simple "here be dragons" warning pops up when you enable Argos, I think that's a pretty small price to pay for continued adoption. But, if more involved fixes are required (manually select the scripts from Argos options?) then obviously, that'd be a case-by-case basis.

[nafg]

But your parents are probably not hacking together scripts they want argos to run ;)

For instance I just put together my own Zoho Books timer. What sort of non-hacker needs argos?

[nafg]

In any case it's certainly ideal to get it uploaded but my point is the alternative is not complete death. To your point, there are lots of things on fdroid

[jvonhoff]

your parents are probably not hacking together scripts they want argos to run ;)

Thankfully, no!

What sort of non-hacker needs argos?

I think there are lots of use cases that are non-hacker, but easier than writing a full Gnome extension. My immediate cases:

• a system monitor that shows exactly what I want, like backup status on a remote server (kinda hacker)
• a stock ticker (not too hacker)
• a microphone kill-switch (I could 100% see non-hackers wanting this, especially these days)

So, I'm not disagreeing too fervently, I'm just saying that if Argos can stay on the e.g.o site by making a few concessions, then I think it would be advantageous. Plus, automatic updates are nice, even for hackers like us, right?

In any case it's certainly ideal to get it uploaded but my point is the alternative is not complete death. To your point, there are lots of things on fdroid

Agree here 100%

[nafg]

I don't think we're disagreeing at all then. If someone has energy to figure out how to make gnome devs happy and implement it, power to them, but if not, or at least until then, having manual install instructions is totally fine, and providing a packed extension file is nice, and that could be done by CI.

[p-e-w]

There will be no user-visible changes to Argos for the sole purpose of getting the extension into EGO. No confirmation dialog, no removal of the welcome script, absolutely no departure from how Argos looks and feels today. This is non-negotiable.

It's cool that EGO exists, and if they want Argos in their repository, I'm happy to have it there. If they have certain technical requirements (manifest files, usage of certain APIs etc.), I'm happy to make the changes necessary to fulfill them. But under no circumstances am I willing to change what Argos does for the privilege of having it listed in someone else's software store.

If I was OK with an unaccountable cabal deciding what my software may and may not do, I would write for the iOS and Android app stores instead, where there is a vastly larger audience and even realistic monetization opportunities. Free Software isn't a "nice to have" for me, it's the reason I write software in the first place. I'll be damned before I let anyone else tell me what my software is "allowed" to do. If they want to be gatekeepers, I'll stay outside of the gate. Anyone who has a problem with that should simply fork and rename Argos.

[jubalfh]

so i think that hard fork is now not only years overdue, but also required; rationale below:

@p-e-w, the primary issue – as i see it – is that you don't have a problem with gate-keeping per se, the problem you seem to have is that you want to be the sole gate-keeper for the application.

…and being a gate-keeper is the only role you're recently fulfill:

• you can't be bothered with providing a governance structure for argos, despite seeing the need of it,
• you can't be bothered with providing code updates,
• you can't be bothered with timely responses to pull requests

ultimately, the effect of your gate-keeping is to deny any user experience to people who are not you, while you don't even use the extension yourself.

[p-e-w]

@jubalfh

the primary issue – as i see it – is that you don't have a problem with gate-keeping per se, the problem you seem to have is that you want to be the sole gate-keeper for the application.

You mean I want to prevent low-quality code and functionality that I oppose for ideological reasons from entering an application that has my name attached to it?

You better believe it.

so i think that hard fork is now not only years overdue

Oh, go right ahead! As long as you make it clear that your repository is indeed a fork and I am not responsible for that particular version of the code, I have no problem with that whatsoever. Maybe you will actually succeed in reviving Argos. But from my own experience, I consider it more likely that you will find that:

• Maintaining this extension is a far more complicated and subtle task than it appears.
• Your issue tracker will be flooded with spam-like questions that have nothing to do with the extension at all.
• Code contributions you receive (if any) range in quality from OK-ish to abysmal (no offense intended to those who have contributed to Argos in the past). The review process to fix those problems takes almost as much effort as it would have taken you to write the code yourself. If you take the shortcut of ignoring quality issues and just merging whatever you get, the codebase will become unmaintainable very quickly.
• Even if you succeed in appeasing the GNOME overlords and get your fork of Argos published on EGO, there is no guarantee that your next update won't be rejected for reasons that sound like the reviewer just made them up. EGO doesn't have any objective rules for what is and isn't acceptable. You can then chase down decision makers on their Matrix channel and hope they actually make a decision, which they may or may not do.
• If you fail in any of those efforts, random people who never contributed anything to Argos will feel entitled to tell you and the community what "needs to happen"... just like you did in this thread.

Best of luck!

[mwilck]

Can we please stop being cynical and personal? This isn't going to help anyone's case.

If someone (@jubalfh?) steps up with a fork, let's see how it goes.

[jubalfh]

if i was sure that i have enough time and resources to manage a project, i would do that gladly.

personal themes aside, i would still think that a single person owning the project (be it the original one or the fork) would be an unnecessary risk: burnout is a thing, communication with gnome maintainers is rarely frictionless and requires plenty of patience (on both sides), and a single person doing everything in a project is a recipe for disaster.

you will notice that most succesful gnome extensions outside the gnome repositories are either managed by a team, or have corporate backing; both allow to work around the burnout / tiredness issue.

[p-e-w]

@jubalfh

were you really interested in having the project survive your ego trips [...]

[...] so that your precious name don't get sullied

I have zero tolerance for personal attacks. I am blocking you from all my repositories, and marking your hostile comment as abuse. Go away and stay away.

To everyone else, you are welcome to discuss this project's direction in a civil manner. If I see any more remarks like the above I will lock this thread.

[markonius]

Hope no one minds the fluff, I just wanna say thank you to @mwilck, @oyale, @daitj and whoever else is keeping this thing going 🙏

[basmevissen]

Hi all,
Hope this is the right discussion to jump into. The version of this gnome extension at the gnome extension page is outdated. Could it be updated to the current master to have gnome 44 supported?
Would be great!

Regards,

Bas.

[mwilck]

Unfortunately, this won't happen. See @p-e-w's #108 (comment) above.

[basmevissen]

Tnx for the update. Didn't read all the comments...
Sad to hear, but I understand the issue. Maybe it is better than to make this more clear on the extension page and here.

[mwilck]

GNOME 45 will require another round of backward-incompatible changes to extensions. If anyone feels like working on this, go ahead.

[mwilck]

GNOME 45 follow-up in #149. Any help would be appreciated.

[mwilck]

I have pushed a working GNOME 45 code base to the branch WIP-gnome-45. Please provide feedback. See #149 for some screen shots.

Note that GNOME 45 support is exclusive with all prior versions of GNOME shell, so we'll re-iterate the previous discussion of how to keep argos compatible with different shell versions. But this time it's really not possible to create a compatibility layer like we did before. Therefore in the GNOME 45 I threw out most of the backward compatibility code, as we can't maintain backward compatibility in that branch anyway.

[mwilck]

On #149, people are asking to merge the GNOME 45 changes. As noted above, it will break compatibility with all prior GNOME releases. Opinions please.

[raspbeguy]

As no feature is added, I think it's sane to let people using older version of GNOME rely on older releases of Argos. Makes sense to me.

[mwilck]

Recalling here that @p-e-w said above that he doesn't want to "turn this repository into a mess of Shell version-specific branches".

[raspbeguy]

I am not talking about branches. Releases don't need their own branches.

[mwilck]

@raspbeguy, I wasn't opposing what you said. My question was whether we want to merge the GNOME 45 changes into the master branch, and my last comment was meant to indicate a "yes". I'd still propose to wait some more to give users of older GNOME versions some time to protest.

[real-or-random]

I'd still propose to wait some more to give users of older GNOME versions some time to protest.

Sounds good, but absence of complaints, I agree that we should merge it into master.