Skip to content
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

Port to GNOME 47 #1863

Closed
antrmn opened this issue Sep 16, 2024 · 13 comments · Fixed by #1866
Closed

Port to GNOME 47 #1863

antrmn opened this issue Sep 16, 2024 · 13 comments · Fixed by #1866
Labels
enhancement A request for a feature or additional functionality needs info An issue that needs more information needs testing A contribution that needs testing

Comments

@antrmn
Copy link

antrmn commented Sep 16, 2024

Describe your request

GNOME 47.rc has been released, with the stable release set for September 18. Please update for GNOME 47 compatibility. The upgrade guide can be found here: Port Extensions to GNOME Shell 47

Thanks!

Proposed solution

No response

Alternatives

No response

GSConnect version

57

Installed from

GNOME Extensions website

GNOME Shell version

46

Linux distribution/release

OpenSUSE Tumbleweed

Additional context

No response

@antrmn antrmn added the enhancement A request for a feature or additional functionality label Sep 16, 2024
@github-actions github-actions bot added the triage An issue that needs confirmation and labeling label Sep 16, 2024
@ferdnyc ferdnyc added needs info An issue that needs more information needs testing A contribution that needs testing and removed triage An issue that needs confirmation and labeling labels Sep 16, 2024
@ferdnyc
Copy link
Member

ferdnyc commented Sep 16, 2024

@antrmn From a quick read over the changes, it doesn't appear that anything needs to be done in GSConnect to support GNOME 47. (For once!) I'm hopeful things will Just Work™.

@wjlonien
Copy link

wjlonien commented Sep 19, 2024

@ferdnyc Just got Gnome 47 in Arch Linux, and it does not work. Please see my screenshot on https://wolfgang.lonien.de/wp-content/uploads/2024/09/Screenshot-From-2024-09-19-10-56-01.png - and the remark "Outdated" on the Gnome extensions site: https://extensions.gnome.org/extension/1319/gsconnect/
Thanks.

@Jai-JAP
Copy link

Jai-JAP commented Sep 19, 2024

Looks like the current version works fine after disabling extension version validation with
gsettings set org.gnome.shell disable-extension-version-validation true.

Didn't test it extensively though.

@ferdnyc
Copy link
Member

ferdnyc commented Sep 19, 2024

@wjlonien Yeah, sorry, with version checking enabled we just need to bump the version in the manifest. #1866 will do that.

In the meantime, if you'd like you can download the build artifact from that job at https://github.com/GSConnect/gnome-shell-extension-gsconnect/actions/runs/10944970767/artifacts/1954164179 and install it using the wiki Install from Zip instructions.

@Attacktive
Copy link

I just tested it with an Android device.
Working fine.

@Theluga
Copy link

Theluga commented Sep 26, 2024

Works perfectly fine with extension validation off.

@NiffirgkcaJ
Copy link

There's an issue in GNOME 47 with the extension not auto-starting at boot. I have a hard time reconnecting the extension to my mobile device automatically when on the same network; now, I need to unpair and pair the both of them to work properly.

@ferdnyc
Copy link
Member

ferdnyc commented Sep 30, 2024

@NiffirgkcaJ

There's an issue in GNOME 47 with the extension not auto-starting at boot. I have a hard time reconnecting the extension to my mobile device automatically when on the same network; now, I need to unpair and pair the both of them to work properly.

Hmm. Well, it wouldn't start at boot, it would start at login (subtle difference). But if it's not, for you, what form does that take?

  1. Is the GNOME Shell extension not activated at all, meaning you have to open Extensions and switch it on each time?
  2. If the Extension is loaded, is the daemon process running right after login, before you do anything? (You can check in a terminal session with ps -ef |grep daemon.js; you should see an entry like this:)
    ferd     1027634    3986  0 Sep23 ?        00:03:32 gjs -m 
    /home/ferd/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js
    

If the daemon isn't running, and you're running from the build artifact in PR #1866, can you check whether it's made itself executable? GitHub removes the execute bit from files in built artifacts automatically, but there's code in GSConnect to check for that and automatically fix it at first launch. Again from a terminal, if you run these commands:

cd $HOME/.local/share/gnome-shell/extensions/[email protected]
ls -l gsconnect-preferences
ls -l service/daemon.js
ls -l service/nativeMessagingHost.js

...all three should have permissions like -rwxr-xr-x.

Whether or not the daemon is running, if you can launch the preferences, "Generate Support Log" now works again (assuming, you're running the build artifact, and not v57 with edited metadata), so activating "Generate Support Log" and then hitting the Refresh button in the preferences might produce some useful logging.

@derkrasseleo
Copy link

I am also running the extension on GNOME 47 with arch and I don't have this problem, it works (connects automatically to my android device) as soon as I log in.

@swsnr
Copy link

swsnr commented Sep 30, 2024

I'd also like to report that I'm running this extension under GNOME 47 without any issues.

@NiffirgkcaJ
Copy link

Hmm. Well, it wouldn't start at boot, it would start at login (subtle difference). But if it's not, for you, what form does that take?

My bad, I misused the word. Yes, it doesn't pair automatically at login.

  1. Is the GNOME Shell extension not activated at all, meaning you have to open Extensions and switch it on each time?

No, it is activated, but like I said, it doesn't pair automatically at login and I need to unpair and pair the devices every time when I go out of session.

  1. If the Extension is loaded, is the daemon process running right after login, before you do anything? (You can check in a terminal session with ps -ef |grep daemon.js; you should see an entry like this:)
ferd     1027634    3986  0 Sep23 ?        00:03:32 gjs -m 
/home/ferd/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js

Here's my output:

petpfne     2594    1493  0 09:04 ?        00:00:00 gjs -m /home/petpfne/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js
petpfne     4830    4796  0 09:11 pts/0    00:00:00 grep --color=auto daemon.js

If the daemon isn't running, and you're running from the build artifact in PR #1866, can you check whether it's made itself executable? GitHub removes the execute bit from files in built artifacts automatically, but there's code in GSConnect to check for that and automatically fix it at first launch. Again from a terminal, if you run these commands:

cd $HOME/.local/share/gnome-shell/extensions/[email protected]
ls -l gsconnect-preferences
ls -l service/daemon.js
ls -l service/nativeMessagingHost.js

...all three should have permissions like -rwxr-xr-x.

Yes, the three of them has the aforementioned permissions correctly set.

Whether or not the daemon is running, if you can launch the preferences, "Generate Support Log" now works again (assuming, you're running the build artifact, and not v57 with edited metadata), so activating "Generate Support Log" and then hitting the Refresh button in the preferences might produce some useful logging.

I edited the metadata.json, so I'm not sure if this will work, but I'll try reinstalling or updating.

@Saqr-Sayed
Copy link

It works fine with Fedora 41 beta. Just move to the next version.

@RZHSSNZDH
Copy link

@wjlonien Yeah, sorry, with version checking enabled we just need to bump the version in the manifest. #1866 will do that.

In the meantime, if you'd like you can download the build artifact from that job at https://github.com/GSConnect/gnome-shell-extension-gsconnect/actions/runs/10944970767/artifacts/1954164179 and install it using the wiki Install from Zip instructions.

If I do this, will I get updates in the future when the extension updates as I get when I install an extension from EOG?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A request for a feature or additional functionality needs info An issue that needs more information needs testing A contribution that needs testing
Projects
None yet
Development

Successfully merging a pull request may close this issue.