-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of argos discussion (co-maintainer, maintenance-only) #108
Comments
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
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. |
@p-e-w ,thanks for your answer and your work. |
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:
Is there something like this already? Would it be feasable? |
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:
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. |
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. |
Hoping this fits in this thread : |
@raspbeguy For sure it's a rather "unstable" solution... but it works as it for me |
Not sure I want to bother using a non-master version of it. |
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.) |
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. |
@p-e-w, being one of the co-maintainers of the hamster shell extension, I feel your pain.
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. |
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 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. |
That's a great news ! Many thanks |
I've tested it on 3.36.2 and it does nothing. Am I doing wrong ? |
Thanks @mwilck, glad you are trying to keep this awesome extension alive |
It was working for me on 3.36.1 version too, but not on the last 3.36.2 version. 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. |
Strange, |
@LaurentOngaro, have you tried simply copying the removed |
I know that's strange because it was running for me on version 3.36.1 Perhaps I make something wrong. And, whatever, the I've tried to make the smallest possible changes to the My knowledge of Gnome extension development was too light until now, but I'm currently trying to improve this skill |
Moreover, how was it possible that |
Maybe the |
I've pushed two more commits to my |
thanks Martin, I test it right now. |
IT WORKS again !!! Issue solved, many thanks |
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 |
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. |
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? |
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 |
Thankfully, no!
I think there are lots of use cases that are non-hacker, but easier than writing a full Gnome extension. My immediate cases:
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?
Agree here 100% |
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. |
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. |
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:
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. |
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.
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:
Best of luck! |
This comment was marked as abuse.
This comment was marked as abuse.
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. |
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. |
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. |
Hi all, Regards, Bas. |
Unfortunately, this won't happen. See @p-e-w's #108 (comment) above. |
Tnx for the update. Didn't read all the comments... |
GNOME 45 will require another round of backward-incompatible changes to extensions. If anyone feels like working on this, go ahead. |
GNOME 45 follow-up in #149. Any help would be appreciated. |
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. |
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. |
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. |
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". |
I am not talking about branches. Releases don't need their own branches. |
@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. |
Sounds good, but absence of complaints, I agree that we should merge it into master. |
Per #106 (comment):
And #106 (comment) by @real-or-random:
Let's discuss the future of argos here, some possible options:
@p-e-w Do you have any opinions on what you would like to happen to the future of argos?
The text was updated successfully, but these errors were encountered: