search

p-e-w / argos

Create GNOME Shell extensions in seconds
https://extensions.gnome.org/extension/1176/argos/
1.67k stars 112 forks source link

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

Open ElijahLynn opened 4 years ago

ElijahLynn commented 4 years ago

Per https://github.com/p-e-w/argos/pull/106#issuecomment-573278743:

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 https://github.com/p-e-w/argos/pull/106#issuecomment-573304389 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:

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

p-e-w commented 4 years ago

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.

LaurentOngaro commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 https://github.com/p-e-w/argos/issues/75#issuecomment-475844513)

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

real-or-random commented 4 years ago

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: https://github.com/JasonLG1979/gnome-shell-extension-mpris-indicator-button/issues/30 (Then we don't really need branches for older versions unless we have a critical issue, but also they won't hurt.)

JasonLG1979 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

LaurentOngaro commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

LaurentOngaro commented 4 years ago

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.jsanymore.
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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

LaurentOngaro commented 4 years ago

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 commented 4 years ago

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

real-or-random commented 4 years ago

@mwilck Can you PR https://github.com/mwilck/argos/pull/1 here? I believe this could be merged here because it's strictly more compatible than the existing code.

That's a step at least. @mwilck Then with that contribution, can you imagine becoming a co-maintainer here?

Personally I still stick to what I said:

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.

mwilck commented 4 years ago

@mwilck Can you PR mwilck#1 here? I believe this could be merged here because it's strictly more compatible than the existing code.

OK, will do. @rammie has had 3 months to respond to my comment. Give me a few more days, I'm currently busy with other stuff.

@mwilck Then with that contribution, can you imagine becoming a co-maintainer here?

Not sure. AFAICS it would be sufficient if any active maintainer was willing and able to review and merge PRs once in a while. Is there anyone with respective rights to the repo except @p-e-w himself?

real-or-random commented 4 years ago

OK, will do. @rammie has had 3 months to respond to my comment. Give me a few more days, I'm currently busy with other stuff.

Ok, sounds good!

By the way:

because I don't want it to look as if I wanted to take anything of @rammie's merits.

What I usually do in this cases is to acknowledge co-authors in the commits. GitHub will then display authorship correctly: https://docs.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors

@mwilck Then with that contribution, can you imagine becoming a co-maintainer here?

Not sure. AFAICS it would be sufficient if any active maintainer was willing and able to review and merge PRs once in a while. Is there anyone with respective rights to the repo except @p-e-w himself?

As far as I understand https://github.com/p-e-w/argos/issues/108#issuecomment-597519734, he's the only one with the permissions now and that's one of the issues but he's open to adding more maintainers.

teoulas commented 3 years ago

I just wanted to post this blog post about Gnome extensions: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/

I'm hopeful something good will come out of it and help with maintaining Argos.

ElijahLynn commented 3 years ago

I just wanted to post this blog post about Gnome extensions: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/

I'm hopeful something good will come out of it and help with maintaining Argos.

Thanks for that article! Been reading through it and am watching this Gnome Extension BoF "A better extensions experience: extensions rebooted - Sriram Ramkrishna" > https://www.youtube.com/watch?v=pC5im1QDNKI.

ElijahLynn commented 3 years ago

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.

K, so just watched the video of the the brand new effort called "The GNOME Extensions Rebooted Initiative". This effort is aiming to solve most of these issues you mentioned that make it difficult to maintain Argos.

I am inspired enough to get involved with the local dev process effort and see where that leads.

Links:

raspbeguy commented 3 years ago

I am inspired enough to get involved with the local dev process effort and see where that leads.

So, @ElijahLynn, are you saying that you'll be forking argos soon and maintain it? That would be great news!

ElijahLynn commented 3 years ago

I am inspired enough to get involved with the local dev process effort and see where that leads.

So, @ElijahLynn, are you saying that you'll be forking argos soon and maintain it? That would be great news!

Not anytime soon. But eventually I could see that if I carve out enough time for this.

real-or-random commented 3 years ago

@mwilck Can you PR mwilck#1 here? I believe this could be merged here because it's strictly more compatible than the existing code.

OK, will do. @rammie has had 3 months to respond to my comment. Give me a few more days, I'm currently busy with other stuff.

Pinging @mwilck . I think this PR would be very helpful.

token47 commented 3 years ago

Just bumping the discussion. We are already in April 2021 and I still had to download a forked version to get it to work in Ubuntu 20.04. It seems to work well and per the discussion above could indeed be merged.

rwalli commented 3 years ago

Is there a "forked version" which works with current gnome version (40)?

teoulas commented 3 years ago
mwilck commented 3 years ago

I have now created #127. @teoulas, the fixes you mentioned are integrated, plus a fix for determining the GNOME shell version with both the old and new versioning scheme.

Thanks to everyone who tested my stuff and provided feedback, and thanks for your patience.

jubalfh commented 2 years ago

@p-e-w are you still interested in maintaining/co-maintaining argos? and if not, wouldn't it be more fair to state that explicitly and allow people to fork the project with clear conscience? (and if there is a communication going on via backchannels, can we please have some updates on where the things stand?)

p-e-w commented 2 years ago

Apologies for being slow to respond. The past few months have been a very difficult time in my personal life, and admittedly Argos (a project I don't use myself anymore) has been quite low on my list of priorities.

I just merged #127, the culmination of a combined effort by @mwilck, @jefferyto, @michel-slm, and @rammie. Since those four individuals clearly care about keeping Argos working, I would like to hereby offer each of them co-maintainership and write access to the Argos repository.

So, if you are either one of the individuals named above, or have otherwise contributed to Argos in the past, or have a proven track record maintaining other GNOME Shell extensions, and want to help ensure Argos has a future, please clearly state in this thread that you would like to be a maintainer. I intend to add 2-3 people as collaborators on this repo so the community can move Argos forward without relying on me. I will also look into how access to the extension listing on extensions.gnome.org can be shared, so co-maintainers can publish new releases through the channel that most people install Argos from.

arnested commented 2 years ago

The past few months have been a very difficult time in my personal life

:hugs:

mwilck commented 2 years ago

@p-e-w, thanks a lot. I wish your personal life will get better / back to normal soon.

Everyone please note:

  1. My interest is to keep argos working the way it used to, e.g. adapt to GNOME shell API changes, and not feature development or other larger endeavors,
  2. I'm not a seasoned JS developer by any metrics,
  3. I can't guarantee response times below (say) a month,
  4. I have a very limited set of working environments in which I'm able and willing to do testing, basically only openSUSE (Tumbleweed and latest Leap).

My contributions as a "maintainer" will be contrained by the above points. If that's understood and accepted, and if there's at least one more person who accepts co-maintainership, I'm in the team.

mwilck commented 2 years ago

They did it again :angry:

The highly-appraised GNOME 42 release again requires changes to the argos extension to make it work. I have created #134, which seems to work for me so far. But this time we can't keep compatibility with GNOME shell versions that don't understand ES6 class syntax (GNOME 32 and older).

Tests of #134 with other GNOME versions would be appreciated.

sthesing commented 2 years ago

Tests of #134 with other GNOME versions would be appreciated.

  • worked fine on Arch with gnome-shell 41.5
  • also fine on Arch with 42

Thanks!

real-or-random commented 2 years ago

Thanks @mwilck for your work.

If that's understood and accepted, and if there's at least one more person who accepts co-maintainership, I'm in the team.

Just pinging here in the hope somewhat steps up. (I know I said I'm happy to help but this was two years ago and I'm too much overwhelmed with other open-source work already, sorry.)

sthesing commented 2 years ago

My contributions as a "maintainer" will be contrained by the above points. If that's understood and accepted, and if there's at least one more person who accepts co-maintainership, I'm in the team.

I'd be willing to co-maintain this with you under the exact same points.

mwilck commented 2 years ago

How important is it that we keep compatibility to GNOME Shell <= 3.32 in the main branch? Even the pretty ancient openSUSE Leap 15.3 has GNOME 3.34 already.

Given that the current package on extensions.gnome.org supports 3.14-3.32, it might be ok to just submit a new version supporting 3.34-42. @p-e-w, I suppose you would need to do that after merging #134, or we need to figure out a way how other people could submit updates to e.g.o.

sthesing commented 2 years ago

How important is it that we keep compatibility to GNOME Shell <= 3.32 in the main branch?

If I understand it correctly, there's no need for it, at all. The web interface on e.g.o lets you install older versions anyway. For example, the oldest gnome-shell version supported in the current master is 3.26, but users can install argos for 3.14: screenshot-argos

mwilck commented 2 years ago

Right. If we could upload the patch set from #134 just for GNOME 3.34 and newer, users would be fine. This has has always been the case.

However, previous discussion here (https://github.com/p-e-w/argos/issues/108#issuecomment-597519734 and follow-ups) showed that people strongly dislike the idea to have to maintain different branches for different Shell versions. That was my main motivation to try to come up with source code changes that would allow supporting 3.36 without breaking compatibility with older Shell versions, which was fixed by others and eventually merged. With the changes that became necessary for GNOME 42 support, this won't be possible any more (at least I can't see how).

Luckily, the code that supports GNOME 42 works all the way down to 3.34, which was released in September 2019. So the situation is different than in the past. In April 2020, support for GNOME 3.32 could hardly be dropped, but dropping it now (from master) doesn't seem unreasonable.

jefferyto commented 2 years ago

Since most of the maintenance effort now is adapting the extension to each new version of GNOME Shell, I think having version branches is scalable (and preferable). If there was still new feature development (and new bugs) this would be different, but once the extension is "stable" for the current version, it's basically done.

Furthermore, in order to minimize the maintenance effort and be somewhat close to upstream's velocity, I think only the current version of Shell and the latest LTS versions for each major distro should/can be supported (again, preferably in different branches).

(Apologies for not chiming in sooner - I would be happy to help when I can but I don't think I can commit to co-maintainership at this time :pray:)

p-e-w commented 2 years ago

More bad news I'm afraid: The updated version of Argos with #127 merged was rejected by the extensions.gnome.org reviewers because of code that

I had a discussion with some reviewers on their Matrix channel, and additionally they voiced general security concerns about Argos' ability to run arbitrary code upon executable files being placed in its config directory (the core function provided by Argos). I debated this for a while but the conversation didn't really go anywhere, and I have no idea what changes are "required" to get the working version into the EGO store.

This is all just so very disappointing. It's bad enough that almost every GNOME Shell release breaks everything, but now it seems I have to deal with Apple/Google style gatekeeping on top of that. Argos is the 5th most popular GNOME Shell extension on GitHub. If this was Apple or Google, making sure such a high-profile app continues to work would be a priority for them. But the GNOME maintainers not only couldn't care less about the entire ecosystem being forced to chase an ever-changing API, they see no problem in rejecting an update because they suddenly realized that code that passed their review process on 3 previous occasions and has been on their platform for more than 5 years might run afoul of one of their vaguely-specified rules.

I really don't know how to move forward here anymore. I create open source software to provide value for others. The amount of disregard I have received from the GNOME platform in return for my efforts is absolutely disheartening (they have broken Plotinus as well, with no meaningful recourse).