Installation broken on multiple OS with gnome shell 3.30.2

[dschier-wtd]

In the comments on extensions.gnome.org and reproducable on my system, the extension is not working and even not installable. (Error).

[rosencreuz]

Here's the error message from syslog:

Mar 25 10:37:29 machine gnome-software[4395]: State change on user/*/*/shell-extension/appindicatorsupport_rgcjonas.gmail.com/* from available to installed is not OK
Mar 25 10:37:29 machine gnome-software[4395]: appindicatorsupport_rgcjonas.gmail.com has error: TypeError: GObject.registerClass() used with invalid base class (is PanelMenuButton)

I have GNOME Shell 3.28.3 and Ubuntu 18.04.2 LTS

[davidbannon]

Looking at the source, 29 days ago, 3.30.2 was removed from list of supported versions.

(Mind you, daniel, U18.04 has a working libappindicator3 anyway, why do you need this plugin ?)

Davo

[maxolasersquad]

@davidbannon How would one leverage the libappindicator3-1 package to replace this extension? I have it installed but still certain application's indicators do not show up without a working version of this extension.

Also, if this is maintained as part of an Ubuntu project, as the namespace in Github would indicate, is the intention of the maintainers to only support the latest STS versions, but not necessarily the LTS versions?

[maxolasersquad]

Answering my own question here a little bit. It looks like support for Gnome < 3.30 was broken in commit f7d9118 which specifically states:

As per upstream changes [1], Lang.Class'es aren't supported anymore to extend
GNOME Shell objects, making dash-to-dock not to work anymore.

Keeping compatibility with older versions isn't feasible with a reasonable
quantiy of work, so better to move everything to the new syntax (supported
since GNOME Shell 3.30)

I guess the real pain point for users here is that the process that updates Gnome Shell extensions isn't doing the proper checking. This new version explicitly states it won't support the version of Gnome that ships with Ubuntu 18.04, however the Gnome extensions updater will update you to the new version anyways. The last tagged version of this extension that will work is v22 at 87db22d which is from back in October 23, 2017. I believe da4c63b is the last version that should work, but haven't tested that theory yet.

[dschier-wtd]

@davidbannon I am not on Ubuntu and afaik, the kstatusnotify application from extensions.gnome.org does not indicate, that I need one ;)

EDIT: If this extension is meant to exclusively work under Ubuntu $VERSION, this should be mentioned on any maintained download page. Furthermore, if ubuntu $VERSION is the only supported OS, you can close this report from my side.

[davidbannon]

Ah, sorry Daniel, confusing you with maxolasersquad (that is, using Ubuntu).
I got the impression from comments on the TopIcons site that they considered this app a general replacement, not just for Ubuntu. I have not been able to get it working on Fedora29. I suspect thats because the Gnome Developers go out of their way to make sure things like this don't work !

maxolasersquad - I use Ubuntu Mate 18.04, it does have libappindicator and it works perfectly. I have assumed that Ubuntu Gnome would too. Looks like I'd better test.

Debian 9.8 Gnome (3.22), for example only needs libappindicator3 installed and it works. But its that incredibly silly tray that slides out when you put mouse near lower left of screen.
(My interest is because I make an app, tomboy-ng, that uses and needs SystemTray Icons.)

I confess I don't understand the purpose of this application if it supports earlier and later versions of Gnome but not the one being shipped with (at least) the two biggest Linux Distros ?

Davo

[rosencreuz]

I couldn't make it work with neither libappindicator nor topicons. This is the only working solution for me (with the previous version now).

[davidbannon]

maxolasersquad - I just tested U18.04 Gnome and found it still works perfectly with my System Tray requiring app (by virtue of it having libappindicator3 built in). So, I still "think" you don't need to install this if you are using the LTS Ubuntu 18.04.2 you mention in your signature. A win for you anyway !

EDIT: No, actually I might be wrong. U18.04 uses libappindicator3 (originally from Unity), its possible that the app you want to use uses the older libappindicator and does not know how to use libappindicator3. Sorry, my mistake, my app tomboy-ng can use either.

Davo

[freiheitsnetz]

We should make clear, that many here are talking about Ubuntu 18.04 which uses Gnome Shell 3.28.3 although the issue title is different.

I have tested the last commit states as suggested by @maxolasersquad on Ubuntu 18.04 and the extension is NOT working anymore with da4c63b

The last working state is 9fe53c4

[dschier-wtd]

Same can be replicated on Fedora 29 and Fedora 30.

[jafd]

1. It's several months until Fedora 30 is released which should have GNOME 3.32. The latest released version of Fedora is 29, and that won't be end-of-lived anytime soon.
2. extensions.gnome.org cannot into version management very well. But that's the only thing we have.
3. all of this happened not because a key interface has changed, which, with GNOME Shell, is not an unusual sight. It happened because of arrow functions! Just a little bit of syntactic sugar.

Given those facts, it would only be responsible and professional to revert that commit. Correct me if I'm wrong, but arrow functions are not essential. Compatibility and user experience, on the other hand, is.

[anarchodin]

There seems to be overlap between this and #162.

[davidbannon]

Interesting. So its the intention of developers to track the Gnome Releases, not the distro releases ?
I am not sure thats a good idea but if its the case, then a table needs to be put together that shows the relationship between distro releases (which is all users know about) and revisions. The github release model could also be made to work and would be even better with little extra work.
I don't use eg Fedora myself (who wants a desktop that prevents you from leaving a file on it ?) but I make an application that uses, and needs a Tray Icon. Right now, my instructions on how to use my app on Fedora29 is quite intimidating. It uses the TopIcons model rather than this extension because I just cannot guess the right way to make this work.
Davo

[3v1n0]

So... Some updates.

As someone mentioned the upgraded version wasn't supposed to support gnome-shell 3.28 and 3.30, and so I think the problem is inside gnome-shell updater itself that should have not considered v23 for such versions, as clearly not supported by the metadata (thanks for mentioning it @maxolasersquad).

That said, as you can see above, I've uploaded a version with only es5 features, that will work in both gnome 3.28 and 3.30, but not in 3.32 for which for this version matrix should not use v24 and stick at v23.

I assume that the reason that caused this problem is the fact that extension v22 wasn't explicitly supporting gnom-shell 3.28 and 3.30, causing the updater to go for the latest version. And in fact there was no other extension version supporting those.

So I expect that when I'll push the version v25 with, again, only 3.32+ support, this won't be a problem anymore.

[3v1n0]

@freiheitsnetz

We should make clear, that many here are talking about Ubuntu 18.04 which uses Gnome Shell 3.28.3 although the issue title is different.

Just curious, are you running this on pure GNOME session in Ubuntu, or using the ubuntu session?

Because in case you are in ubuntu this update should not affect you, and in any case you should have not installed this extension at all, since Ubuntu supports this by default via the package gnome-shell-extension-appindicator.

[3v1n0]

@jafd

all of this happened not because a key interface has changed, which, with GNOME Shell, is not an unusual sight. It happened because of arrow functions! Just a little bit of syntactic sugar.

Given those facts, it would only be responsible and professional to revert that commit. Correct me if I'm wrong, but arrow functions are not essential. Compatibility and user experience, on the other hand, is.

Please save the sarcasm for occasions where you read the full change that is mentioned in commit f7d9118 (a part the fact that I wrote dash-to-dock instead of appindicator).

Anyways, while I love arrow functions, the main reason is that gnome-shell 3.32 doesn't use and properly support Lang.Class anymore that this extension was also using for extend a gnome-shell class that has now moved to use ES6 classes (as per this, and see f7d9118#diff-7f87449ec014b9701560ff99a131c465R34) and mixing these two kinds of classes doesn't work properly. And indeed it doesn't if you subclass (while it silently might work, there are problems).

So, this extension has to change like many others with 3.32 (which is an effective API break). I hope the explication above (#166 (comment)) is valid and thus that the new upgrades won't break users with old shells.

[3v1n0]

Interesting. So its the intention of developers to track the Gnome Releases, not the distro releases ?

master branch code should always stay in sync with gnome-shell upstream code, and I'll try to make it possible in between the various things.

Releases then should be done independently, but this has to assume that the tool for distributing the extensions won't break the users when a version should not reach users with unsupported versions.

[3v1n0]

Fixed with commit 0d7e6d5

[jafd]

Please save the sarcasm for occasions where you read the full change that is mentioned in commit f7d9118 (a part the fact that I wrote dash-to-dock instead of appindicator).

The breakage happened a commit before that one, which only introduced the arrow functions. And my gripe was that a generally available GNOME Shell version was broken in favor of one that didn't even make it to the downstream distributions.

Anyway, thanks for finding a way to handle it properly (I was just about to sarcastically suggest that Babel is a thing... ;) ).

[3v1n0]

@jafd arrow function commit was just a split for better reviewing of the whole change, but the main reason for the change has already been explained.

And yes, babel could be a thing if it wasn't that we're using gjs, and thus things like the usage of GObject.registerClass instead of Lang.Class could not used easily until we don't create proper wrappers around them that abstract those depending on gjs version.

So... Not something we can use, also because not having many other features coming around there there's no much point. At least for now.

[3v1n0]

Just an headsup though, such issues won't happen anymore anyways, as upstream extensions-website issue has been fixed.

So thanks who reported this, as it was a good trigger for upstream too.

[dschier-wtd]

@3v1n0 Thank you a ton to fixing it. The extension works like a charm again!

[freiheitsnetz]

Just curious, are you running this on pure GNOME session in Ubuntu, or using the ubuntu session?

Because in case you are in ubuntu this update should not affect you, and in any case you should have not installed this extension at all, since Ubuntu supports this by default via the package gnome-shell-extension-appindicator.

Just as a follow up to answer this question, as this was directed to me.

I am using Ubuntu in the "Ubuntu" session.
Nevertheless, I was using this extension from the extensions.gnome.org website as I was coming from Fedora and had other extensions installed from extensions.gnome.org, so I stayed with that way of installing extensions, instead of installing the extensions from the distro's repositories. Maybe a good indication for me to stick to the distro maintained packages instead of going bleeding edge ;-)