Update for convenience.js again

[DirkHoffmann]

Similar to #216.
In my quest to run the extension on gnome-shell 3.30 in a Fedora 29 box, I followed the instructions on README, but they do not seem to be up to date:

rm -fr build
mkdir -p build
cp -R extension/* build
cp -R data/* build
wget https://gitlab.gnome.org/GNOME/gnome-shell-extensions/raw/master/lib/convenience.js -O build/convenience.js
--2019-02-10 17:53:53--  https://gitlab.gnome.org/GNOME/gnome-shell-extensions/raw/master/lib/convenience.js
Resolving gitlab.gnome.org (gitlab.gnome.org)... 209.132.180.181
Connecting to gitlab.gnome.org (gitlab.gnome.org)|209.132.180.181|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-02-10 17:53:54 ERROR 404: Not Found.

I tried to find the file in gnome gitlab, but had no success, so I used the last known tag with it, and the compilation went fine.

However, as I am using it for the first time, and I don't see any text or icon appear in the gnome top panel. Can I help to debug this further? I installed hamster, and it works fine otherwise.

PS: I also noticed that the installation instructions need and update, but I will come back to that (make a pull request with updated #instructions) later, when working on 3.30 is confirmed. (Check my clone on gitlab, if you are impatient.)

[mwilck]

convenience.js has been removed in the master branch. You can get it from the 3.30 branch:

https://gitlab.gnome.org/GNOME/gnome-shell-extensions/blob/gnome-3-30/lib/convenience.js

Ah sorry you figured that out already.

[mwilck]

The background is this commit.

So more changes will be necessary to hamster in the future. The necessary changes
will look like this:

    +   Convenience.initTranslations();
    -   ExtensionUtils.initTranslations();

[matthijskooijman]

Note that apparently, convenience.js is no longer needed in recent shell versions (not sure if any such version is already released). Until we can actually (exclusively) use those newer shell versions, I wonder if we should just include the convenience.js in this repo instead of downloading it during compile? That would at least make things more predictable than using the master version, and if we're using a tagged versoin, might as well remove the external dependency and include the code directly?

[matthijskooijman]

See https://gitlab.gnome.org/GNOME/gnome-shell-extensions/commit/bab4be1a597226a5fe8a29dcf3848be47e16a5e5

[mwilck]

if we're using a tagged versoin, might as well remove the external dependency and include the code directly?

We could, but I fail to see the benefit. I'd recommend to use a branch rather than a tag (see my previous comment), because that way we'd even reveive bug fixes in the (admittedly unlikely) case that upstream adds any in the future.

[matthijskooijman]

We could, but I fail to see the benefit.

Stability and reproducibility of a build seems like a benefit to me. In addition to getting bugfixes, you might also get new bugs from a newer version (though using e.g. the 3.30 branch makes that less likely than e.g. the master branch, of course). Also, being able to build without an internet connection is somewhat of a feature (and both, reproducibility and building without internet are required for building e.g. Debian packages).

Having said that, I'm not really insisitent on this, and I'm not really familiar with this codebase, so it's certainly not my call. Just venting my opinion :-)

[mwilck]

True. For the openSUSE build (no network connectivity in the build service), I actually did just that - download the convenience.js file and add it to the distribution. That required also a Makefile change.

[benjaoming]

Recommend merging this as building is currently broken and this fixes it.

[DirkHoffmann]

One year later, the problem is still there. Some discussions in the past went on, but now it displays "Merging is blocked".
So what are the plans, @mwilck, @matthijskooijman?

[DirkHoffmann]

@matthijskooijman wrote above:

Note that apparently, convenience.js is no longer needed in recent shell versions (not sure if any such version is already released).

What exactly is "recent shell versions" for you?
Trusting your statement, I tried to install it for gnome-shell 3.32 without convenience.js, and it failed with this error message:

ImportError: No JS module 'convenience' found in search path

Stack trace:
  @/home/hoffmann/.local/share/gnome-shell/extensions/[email protected]/prefs.js:33:7
  _getExtensionPrefsModule@resource:///org/gnome/shell/extensionPrefs/main.js:59:13
  _selectExtension@resource:///org/gnome/shell/extensionPrefs/main.js:74:31
  _onCommandLine@resource:///org/gnome/shell/extensionPrefs/main.js:320:17
  main@resource:///org/gnome/shell/extensionPrefs/main.js:635:5
  @<main>:1:43

[benjaoming]

@DirkHoffmann

What exactly is "recent shell versions" for you?

The convenience module got removed a year ago in this merge request: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/51 -- I doubt it has any relevance to contemporary supported Linux distributions, i.e. Debian Buster, Ubuntu Bionic etc.

Is the decision left this?

A. Download convenience.js during build time?
B. Include convenience.js in the repo?

I guess B because the build system should preferably work offline as @mwilck said?

[DirkHoffmann]

Thank you for the explanations, @benjaoming. @mwilck has prepared a working version for gnome-shell 3.32 and 3.34, which does not need convenience.js any more.

[benjaoming]

Anyone knows if the alternatives prepared by @mwilck work for GNOME Shell 3.28.4 ?

[DirkHoffmann]

I got them working on 3.32.2 (would not know how to get 3.28.4) and Fedora 30 today.

For the sake of clarity, you should close your old PR and ask your question on #301 (or open another bug, but it would be a duplicate).
I am ready to help you with instructions or send you my tar/zip.

[matthijskooijman]

if we're using a tagged versoin, might as well remove the external dependency and include the code directly?

What exactly is "recent shell versions" for you?
Trusting your statement, I tried to install it for gnome-shell 3.32 without convenience.js, and it failed with this error message:

What I meant here is that as of gnome-shell 3.32, the functions that convenience.js used to provide are now included directly in the gnome-shell ExtensionUtils. This does require some (trivial) changes to the extension, e.g. such as https://gitlab.gnome.org/GNOME/gnome-shell-extensions/commit/bab4be1a597226a5fe8a29dcf3848be47e16a5e5

So if we drop support for 3.30 and below (in a specific branch), then we could also drop convenience.js completely if we update the function calls to it.

[mwilck]

@benjaoming, IIRC convenience.js is mandatory up to 3.30, but not usable any more in 3.32. I haven't had time to go through the hassles of wrapping this in conditional code, therefore I ditched convenience.js and marked previous shell versions as unsupported. So my tree is only for users of GNOME shell 3.32 and newer.

Past discussions with "real" maintainers of GNOME shell extensions have made me realize that a lot of people have given up trying to track the API changes in a single "common source" extension code. Instead, different versions are provided for download on extensions.gnome.org. Unfortunately we can't do this.

[benjaoming]

Sorry to hear that @mwilck - thanks for sharing the analysis. Sounds a bit like the challenges faced by extension ecosystem of Thunderbird/Firefox.. lots of projects dying out from API disruption fatigue :/ Great that Gnome developers keep a scope of what they can manage to support.

[matthijskooijman]

Instead, different versions are provided for download on extensions.gnome.org. Unfortunately we can't do this.

Why can we not do this? I guess we could track a few gnome versions in branches and then only add new features in the most recent branch (or maybe backport to a few older ones too)?

[DirkHoffmann]

Instead, different versions are provided for download on extensions.gnome.org. Unfortunately we can't do this.

Why can we not do this? I guess we could track a few gnome versions in branches and then only add new features in the most recent branch (or maybe backport to a few older ones too)?

I agree with @matthijskooijman. As every software, the versions can be properly tagged and released. Obviously the users of older versions have to live without backports of new features, then you do not need to branch anything. (And keep fingers crossed that the API towards hamster itself remains backward-compatible.)

[benjaoming]

I have tried writing emails to @elbenfreund a couple of times, and I was wondering if this repository is under control of any additional people? I suppose not, since nothing has been merged since April 2018.

Since there are other active people in the project-hamster organization owning the repository, would it be worth writing them as well in order to delegate ownership to a new group of maintainers?

[mwilck]

Why can we not do this? I guess we could track a few gnome versions in branches and then only add new features in the most recent branch (or maybe backport to a few older ones too)?

As long as we can't hijack the URI of the original extension ([email protected]), which is still owned by @elbenfreund, I don't think it makes a lot of sense to upload another version. Searching extensions.gnome.org for "hamster" gets 3 hits, which I find confusing for users already. I wouldn't want to add number 4 (but I wouldn't object if somone else did with my code base). Has anyone succeeded contacting Eric?

[mwilck]

Side note: I started shipping the hamster GNOME extension as RPM package for openSUSE to work around the awkward deadlock situation on e.g.o. I confess I may not have tried hard enough to fix e.g.o., it was just too far outside my scope.

[DirkHoffmann]

Has anyone succeeded contacting Eric?

Like you, he is easy to stalk on Internet. I did. Give me one week to see, if he is still alive (figuratively).

I started shipping the hamster GNOME extension as RPM

I think the big distros (SuSE, RedHat, Debian) presently prefer to decouple gnome-shell extensions from their repos and leave it to the user to pull them from GNOME directly. (One more reason to keep the interfaces backward-compatible.)
But it's a matter of taste (and time) for me. Certainly it takes less time to upload one ZIP to GNOME than to produce n packages in RPM, deb and the like for all possible distributions.

[mwilck]

I think the big distros (SuSE, RedHat, Debian) presently prefer to decouple gnome-shell extensions from their repos

True. But it doesn't always work. Actually, many extensions, like the hamster extension, are not actively developed; changes are almost exclusively made to adapt to shell API changes. From that perspective, integrating extensions matching the shipped GNOME shell makes a certain amount of sense for distro packagers (with the additional bonus that the update of the shell and the extension is "atomic", in the sense that users don't have to figure out why their extensions are broken and locate/download new versions matching the updated shell version manually). For me, packaging the extension with the distro was the lazy person's approach.