Add linkable shell script launchers

[ferdnyc]

This PR adds or replaces shell scripts as launchers for the runnable JS modules. Unlike the modules (which break if executed from a path outside the extension), the shell launchers can be executed from any directory, even when symlinked.

So, a user interested in operating GSConnect in CLI mode can symlink gsconnect.sh and gsconnect-preferences.sh into /usr/local/bin/ or $HOME/.local/bin/ (as either their original names, or as gsconnect and gsconnect-preferences), and use them from the command line.

This is functionality that was formerly available, but broke in the migration to ES modules.

Specific changes:

• Rename gsconnect-preferences to preferences-app.js and remove its shebang line.
• Add a gsconnect-preferences.sh shell script that will launch preferences-app.js in gjs correctly, even if symlinked.
• Add a new gsconnect.sh that will do the same for service/daemon.js.
• Use gsconnect-preferences.sh to launch preferences-app.js from prefs.js.
• Make tools launchable without runAsync, for environments without latest Gtk.

Fixes #1787

[ferdnyc]

cc: @nebulosa2007, @JingMatrix

[JingMatrix]

This is functionality that was formerly available, but broke in the migration to ES modules.

Why so? They are currently working fine on my devices, not broken at all.

[ferdnyc]

@JingMatrix

Why so? They are currently working fine on my devices, not broken at all.

With GSConnect 57, if you symlink $HOME/.local/share/gnome-shell/extensions/[email protected]/gsconnect-preferences into e.g. $HOME/.local/bin/ and attempt to run it as gsconnect-preferences from some random path, my experience is that it doesn't work at all. Ditto if you symlink .../service/daemon.js as gsconnect. GJS gets the paths all wrong and fails to load modules.

That's why @nebulosa2007 updated the CLI-usage wiki page to that effect, and it was true in my testing as well.

[ferdnyc]

$ cd /tmp
$ ln -fs \
  ~/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js \
  ~/.local/bin/gsconnect  
$ gsconnect --help

(gjs:452568): Gjs-WARNING **: 11:49:26.833: JS ERROR: ImportError: Unable to load file from: file:///home/ferd/.local/bin/init.js (Error opening file /home/ferd/.local/bin/init.js: No such file or directory)


(gjs:452568): Gjs-CRITICAL **: 11:49:26.834: Failed to resolve imports for module: 'file:///home/ferd/.local/bin/gsconnect'

$ ln -fs \
  ~/.local/share/gnome-shell/extensions/[email protected]/gsconnect.sh \
  ~/.local/bin/gsconnect  
$ gsconnect --help
Usage:
  gsconnect [OPTION…]

Help Options:
  -h, --help                          Show help options
  --help-all                          Show all help options
  --help-gapplication                 Show GApplication options
  --help-gtk                          Show GTK+ Options

Application Options:
  -l, --list-devices                  List available devices
  -a, --list-all                      List all devices
  -d, --device=<device-id>            Target Device
  --pair                              Pair
  --unpair                            Unpair
  --message=<phone-number>            Send SMS
  --message-body=<text>               Message Body
  --notification=<title>              Send Notification
  --notification-appname=<name>       Notification App Name
  --notification-body=<text>          Notification Body
  --notification-icon=<icon-name>     Notification Icon
  --notification-id=<id>              Notification ID
  --ping                              Ping
  --ring                              Ring
  --share-file=<filepath|URI>         Share File
  --share-link=<URL>                  Share Link
  --share-text=<text>                 Share Text
  -v, --version                       Show release version
  --display=DISPLAY                   X display to use

[JingMatrix]

Ah, I see the problem. After removing the previous installation directory. The symbolic links are indeed broken.

[ferdnyc]

@JingMatrix

Can you check whether that (old installation directory) affects your PR #1813? It was trying to test that change that led me to this issue.

I'm willing to merge #1813 if you say it's necessary and the fix works for you. But I never was able to successfully test it, since my only non-GNOME device is a VM with no paired devices.

[JingMatrix]

I applied your pull-requst, and it unfortunately broke gsconnect. It was stuck at the accepting paired devices step.
By contrast, #1813 still works if I start gsconnect with full path.
I will try to figure out the issue in your pull-request.
Please don't merge this pull-request too soon.

[ferdnyc]

@JingMatrix Don't worry, this is definitely one I don't plan to rush in.

There may be places I've missed where GSConnect launches/re-launches itself, that'd be my first guess as to the problem.

Anything useful in the journal?

[JingMatrix]

Please revert the change concerning runAsync. There are two reasons

1. log(service.hasOwnProperty('runAsync'), service.runAsync, typeof service.runAsync) outputs false [ Function: ] function
2. if we don't use runAsync, we cannot accept paired devices. Actually, service/device.js cannot send packets after backends/lan.js accept the devices.

[JingMatrix]

But I never was able to successfully test it, since my only non-GNOME device is a VM with no paired devices.

You can test it in GNOME environment using GSCONNECT_MODE=cli gsconnect, which should work fine.

[ferdnyc]

log(service.hasOwnProperty('runAsync'), service.runAsync, typeof service.runAsync) outputs false [ Function: ] function

Ah, makes sense that runAsync would be inherited. Reverted.

It's unfortunate that this means a fairly recent Gtk is still required, though. My tests on Ubuntu 22.04 failed due to lack of runAsync() in Gtk 4 version... 41? 43? Whatever it uses.

The CLI mode (at least in theory) shouldn't really need Gtk at all.

[nebulosa2007]

For me, issue #1787 is absolutely closed, I never use launching gsconnect or gcsonnect-preferences from terminal. Now, even if you fix this behaviour, only the wiki article needs to be updated, without reopening the issue.

[ferdnyc]

@nebulosa2007

For me, issue #1787 is absolutely closed, I never use launching gsconnect or gcsonnect-preferences from terminal. Now, even if you fix this behaviour, only the wiki article needs to be updated, without reopening the issue.

That's fine, but project Issues aren't there to track your personal needs, they're meant to track issues with the extension. and #1787 is definitely still an unsolved issue, which this PR is intended to solve.

(Is there any chance you'd be able to test whether the shell launchers work for you, even if you don't ever plan to use them? I'd definitely welcome another pair of eyes on this. You're one of relatively few CLI-mode users of the extension, so there isn't a big pool of available testers here.)

[nebulosa2007]

Is there any chance you'd be able to test whether the shell launchers work for you

Sure! Built a git version with this commit only, put gsconnect.sh and gsconnect-preferences.sh into /usr/bin and got the errors:

$ gsconnect
Error opening file /usr/bin/service/daemon.js: No such file or directory

$ gsconnect-preferences 
Error opening file /usr/bin/preferences-app.js: No such file or directory

I suppose that EXTENSION_DIR variable should be defined with another way.

By the way, @JingMatrix do you have any plans to switch pydbus dependence to dbus-python? It not related to this issue, but still.

[JingMatrix]

By the way, @JingMatrix do you have any plans to switch pydbus dependence to dbus-python? It not related to this issue, but still.

Hi! Did pybus cause some trouble for you so far? The code involving pybus is super simple, if there is some inconvience with it, then I am willing to switch.

[nebulosa2007]

Did pybus cause some trouble for you so far?

Not yet, just afraid this package will become obsolete after a while. Just asking about the possibility of switching.

[ferdnyc]

@nebulosa2007

Is there any chance you'd be able to test whether the shell launchers work for you

Sure! Built a git version with this commit only, put gsconnect.sh and gsconnect-preferences.sh into /usr/bin and got the errors:

You can't copy them, you have to symlink them to use them from any other path. The scripts discover the path to the modules based on their real location on disk, relative to the JS files.

(The .js files had to be symlinked to use them as commands, so it's really no different than before.)

[nebulosa2007]

You can't copy them, you have to symlink them to use them from any other path.

I see. I made symlinks and now everything works with patch above

[ferdnyc]

I just updated both scripts with a comment detailing how they should be used, and a file-existence check that displays an error message if the JS file they need to access isn't found in the expected location.