Open ferdnyc opened 1 month ago
cc: @nebulosa2007, @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.
@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/gsconnect@andyholmes.github.io/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.
$ cd /tmp
$ ln -fs \
~/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/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/gsconnect@andyholmes.github.io/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
Ah, I see the problem. After removing the previous installation directory. The symbolic links are indeed broken.
@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.
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.
@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?
Please revert the change concerning runAsync
. There are two reasons
log(service.hasOwnProperty('runAsync'), service.runAsync, typeof service.runAsync)
outputs false [ Function: ] function
runAsync
, we cannot accept paired devices. Actually, service/device.js
cannot send packets after backends/lan.js
accept the devices.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.
log(service.hasOwnProperty('runAsync'), service.runAsync, typeof service.runAsync)
outputsfalse [ 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.
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.
@nebulosa2007
For me, issue #1787 is absolutely closed, I never use launching
gsconnect
orgcsonnect-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.)
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.
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.
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.
@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
andgsconnect-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.)
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
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.
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
andgsconnect-preferences.sh
into/usr/local/bin/
or$HOME/.local/bin/
(as either their original names, or asgsconnect
andgsconnect-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:
gsconnect-preferences
topreferences-app.js
and remove its shebang line.gsconnect-preferences.sh
shell script that will launchpreferences-app.js
ingjs
correctly, even if symlinked.gsconnect.sh
that will do the same forservice/daemon.js
.gsconnect-preferences.sh
to launchpreferences-app.js
fromprefs.js
.Make tools launchable withoutrunAsync
, for environments without latest Gtk.Fixes #1787