Gnome-shell-extension-gsconnect: GNOME 3.36 Support

Created on 10 Jan 2020 · 19Comments · Source: GSConnect/gnome-shell-extension-gsconnect

Describe the bug

gnome-shell-extension-gsconnect fails to load under gnome 3.35.x

Steps To Reproduce:

install extension.
enable
See extension not work

Expected behavior

Extension to load and work

Screenshots

If applicable, add screenshots to help explain your problem. You can drag-and-drop or cut-and-paste images directly into this edit window, to include them in your report.

Support Log

Please generate a support log (Instructions) and paste any messages related to this issue between the two ``` lines below.

Jan 09 10:24:03 taim.scrye.com gnome-shell[2644]: JS ERROR: Extension [email protected]: Erro
r: Tried to construct an object without a GType; are you using GObject.registerClass() when inheriting fro
m a GObject type?
                                                  ServiceIndicator@/home/kevin/.local/share/gnome-shell/ex
tensions/[email protected]/extension.js:63:9
                                                  enable@/home/kevin/.local/share/gnome-shell/extensions/g
[email protected]/extension.js:451:24
                                                  _callExtensionEnable@resource:///org/gnome/shell/ui/exte
nsionSystem.js:148:13
                                                  loadExtension@resource:///org/gnome/shell/ui/extensionSy
stem.js:277:21
                                                  _loadExtensions/<@resource:///org/gnome/shell/ui/extensi
onSystem.js:487:13
                                                  collectFromDatadirs@resource:///org/gnome/shell/misc/fil
eUtils.js:27:17
                                                  _loadExtensions@resource:///org/gnome/shell/ui/extension
System.js:466:9
                                                  _enableAllExtensions@resource:///org/gnome/shell/ui/exte
nsionSystem.js:496:13
                                                  _sessionUpdated@resource:///org/gnome/shell/ui/extension
System.js:527:13
                                                  init@resource:///org/gnome/shell/ui/extensionSystem.js:4
8:9
                                                  _initializeUI@resource:///org/gnome/shell/ui/main.js:242:5
                                                  start@resource:///org/gnome/shell/ui/main.js:138:5
                                                  @<main>:1:31

System Details (please complete the following information):

GSConnect version: [e.g. 20, 24, ... (displayed in the GSConnect "About" window)] 28
- Installed from: [e.g. GNOME Extensions Website, GitHub, Package Manager, ...] github
GNOME/Shell version: [e.g. 3.30, 3.28, ...] 3.35.3
Distro/Release: [e.g. Ubuntu 18.04, Fedora 29, Arch, ...] Fedora Rawhide

GSConnect environment (if applicable):

Paired Device(s): [e.g. Galaxy Note 8, Pixel 2, Honor 9, ...] Oneplus 3T
KDE Connect app version: [e.g. 1.12.7]
Plugin(s): [if the issue only occurs when using certain plugin(s)]

Additional Notes:

Add any addtional information about the problem or your system.

shell-extension

Source

nirik

👍4 👀1

Most helpful comment

There is a preliminary branch up at gnome-3-36 for early adopters.

Please note, we're not ready to accept bug reports for this version yet.

andyholmes on 4 Mar 2020

❤6

All 19 comments

Thanks for reporting. I haven't actually checked, but this seems reasonable.

This is likely another case of a native JS class being ported to GObject, so it's an easy fix but I'm not sure when this will get into master. Since we're only going to be supporting the latest stable release I may have to start branches for GNOME releases so we can keep these fixes out of current releases.

andyholmes on 14 Jan 2020

👍2

If they're making breaking changes that can't (easily) be supported in the code without breaking OLDER releases, then branches to target different versions sounds reasonable.

The other option would be to create GitHub project milestones for each GNOME release, and tag PRs (and issues) into those. Then they could be merged when the release lands.

ferdnyc on 14 Jan 2020

(Advantage to the latter, you don't have to keep a branch from getting stale against master.)

ferdnyc on 14 Jan 2020

If they're making breaking changes that can't (easily) be supported in the code without breaking OLDER releases, then branches to target different versions sounds reasonable.

Well, the changes in gnome-shell are really easy to work around, it's more that I don't want to add a bunch of if-then's I can't easily test that get removed in a few months. It's also pretty common for those to end up in hot paths where they get called frequently.

The other option would be to create GitHub project milestones for each GNOME release, and tag PRs (and issues) into those. Then they could be merged when the release lands.

That might be an option. In the context of your second note above, keeping a second branch up to date doesn't sound like a lot of fun, but it would mean people can match GNOME master -> GSconnect master if they are running a development environment.

I've never used projects on github before, have you? Do you know if that sort of thing would be possible for users to do if they wanted to do such a thing?

andyholmes on 14 Jan 2020

That might be an option. In the context of your second note above, keeping a second branch up to date doesn't sound like a lot of fun, but it would mean people can match GNOME master -> GSconnect master if they are running a development environment.

I've never used projects on github before, have you? Do you know if that sort of thing would be possible for users to do if they wanted to do such a thing?

Only very superficially. I don't know of any way to do that, there doesn't appear to be any sort of "project branch" feature or anything like that. It's much more about organizing Issues/PRs and tracking them as a group — more akin to Bugzilla et al's tracking tickets, I guess.

The PRs _themselves_ are branches, of course, but once there are multiple PRs open under some umbrella, I don't know of any way to consolidate them except by merging them all into _some_ branch. So, yeah, from that perspective a branch probably makes more sense.

ferdnyc on 14 Jan 2020

In my GNOME extension, I had if statement for different GNOME versions:

    shell: function () {
        var parts = imports.misc.config.PACKAGE_VERSION.split('.')
        return parseFloat(parts[0] + '.' + parts[1]);
    },
    update: function () {
        if ( this.shell() >= 3.12 ) {
            this.getBattery(function (proxy) {
                var batteryPowered = UPower.DeviceKind.BATTERY,
                    fullyCharged = UPower.DeviceState.FULLY_CHARGED;

                if (proxy.State ==  fullyCharged && proxy.Type == batteryPowered) {
                    this.hide();
                } else {
                    this.show();
                }
            });
        } else {
            this.getDevice(function (device) {
                if ( device.state == UPower.DeviceState.FULLY_CHARGED ) {
                    this.hide();
                } else {
                    this.show();
                }
            });
        }

        return this;
    },

GNOME 3.36 will be released next week.

ai on 3 Mar 2020

Yes, we don't support multiple versions of GNOME Shell by design. Most of GSConnect is not a Shell extension, so supporting multiple versions means supporting varying versions GJS and almost a dozen other libraries.

This results in significant technical debt and a huge maintenance burden.

andyholmes on 3 Mar 2020

@andyholmes do you have policy what GNOME versions are supported?

For instance, you can support the latest GNOME in the latest version of the extension.

ai on 3 Mar 2020

Correct, the policy is to only support the current stable release of GNOME, currently 3.34.

andyholmes on 4 Mar 2020

Am I right that in a week the current stable GNOME will be changed to 3.36 (since GNOME does not have LTS releases)?

ai on 4 Mar 2020

When it's released, yep it will be then be the latest stable release of GNOME. The next version of GSConnect after that point will then only support GNOME 3.36.

andyholmes on 4 Mar 2020

There is a preliminary branch up at gnome-3-36 for early adopters.

Please note, we're not ready to accept bug reports for this version yet.

andyholmes on 4 Mar 2020

❤6

There is a preliminary branch up at gnome-3-36 for early adopters.

Please note, we're not ready to accept bug reports for this version yet.

I haven't tested thoroughly but I was able to install and use this version without any issues. I'm on Ubuntu 20.04 with GNOME 3.35.91.

esa1975 on 5 Mar 2020

I don't want to be annoying about this.
Given that you have a policy where you support only the latest version of gnome. Have you ever thought about going upstream with gsconnect, make it an official extension?