Cli support for general wayland environment

[JingMatrix]

This commit use wl-clipboard and ydotool to support general wayland environment, such as sway.

[JingMatrix]

Please tell me if you have intention to extend this plugin to non-gnome environment, @ferdnyc @andyholmes .
If so, I can add a page to the project wiki to show how it actually works.

[andyholmes]

I don't have much of an opinion on this. GSConnect was intended to be specifically for GNOME Shell, but if another maintainer wants to give it a 👍 I won't stand in the way 🙂

[daniellandau]

I have limited time for maintenance, so if making it more generic comes with associated maintenance effort on an ongoing basis I'm all for it. I'll read through the code hopefully soon.

[andyholmes]

Sorry this sat around for so long. I don't see any reason not to merge at this point, so a few fixups and I will accept this.

[andyholmes]

Oh, just one more thing: add the SPDX comments to ydotool.js and wl_clipboard.js like so:

// SPDX-FileCopyrightText: GSConnect Developers https://github.com/GSConnect
//
// SPDX-License-Identifier: GPL-2.0-or-later

[JingMatrix]

Thanks for reviewing.
Unfortunately, I have forgotten most of the logic of gsconnect, though I am using this pull request for the whole year.
It seems after merging the main branch, remote mousepad isn't working. I need some time to debug it.
Also, I should add a wiki page to explain the usage.

[andyholmes]

Okay, no problem. I don't expect many folks will start using this for a little while, at least.

If you can get it working for you, we can merge and you can be "codeowner" for that module, if you like.

[JingMatrix]

I test it on my machine with both sway and gnome-shell sessions, and there is no problem. (It turned out that I forgot to start ydotoold in sway.)
I would be happy to maintain this module.

Notes for users

When gsconnect is not running as a Gnome extension, for example, running under sway,

1. You might still need to install the gnome-shell package to provide the Gvc-1.0.typelib file of the gnome module libgnome-volume-control.
2. Install ydotool and start the service: systemctl status --user ydotool.service
3. Install wl-clipboard and wl-type

[JingMatrix]

I found that the env GNOME_SETUP_DISPLAY is specially set by gnome, which can thus be used to detect gnome.

Now this pull request should pass all tests without problems, you can merge it.

P.S. it might be interesting to write a test for non-gnome envirment, maybe in the future.

[andyholmes]

P.S. it might be interesting to write a test for non-gnome envirment, maybe in the future.

Definitely, I saw somewhere I think Google Chrome or Chromium had a Wayland version of xvfb built with python or something. I never had time to really get into it though.

[JingMatrix]

As a note, I add the wiki page of its usage: CLI usage without Gnome.

It will be helpful to put some instructions described there into the meson build process.

[andyholmes]

That's great, thanks for writing all that up!

[pobrn]

This PR introduces a check that uses imports to determine, as far as I understand, if it's running inside gnome shell. What was the problem with that? And when it was replaced, why was it replaced with a check for the GNOME_SETUP_DISPLAY environmental variable? Why wasn't something like GLib.getenv('XDG_CURRENT_DESKTOP') === 'GNOME' || GLib.getenv('XDG_SESSION_DESKTOP') === 'gnome' enough? The only clue I could find is in 9739f97 that states

Relying on environment variables for the determination of gnome-shell is not stable when run as a d-bus service.

So I'm guessing the concern is that checks like the above will break gsconnect if it's run inside a gnome session but not as a gnome shell extension? Because if so, then I believe the current check has the same weakness.

As I mentioned in #1706 (comment) now that gsconnect checks GNOME_SETUP_DISPLAY, some features are broken on all configurations that have no ydotool, and running x11 or running wayland without xwayland.

[JingMatrix]

Given what said by @pobrn , it is better not to use environment variable for detecting the 'Gnome'.
I was for using imports to detect Gnome, @andyholmes changed it out of the reason of simplicity (I guess).
Hence, it is favorable to revert the changes regarding the environment variable.
I will do it soon to fix #1706.

[andyholmes]

FWIW, this was my suggestion:

This won't work in the service, because it's runs outside of the gnome-shell process (meaning it will always throw an error). However, I think this would work:

const HAVE_GNOME = GLib.getenv('XDG_SESSION_TYPE') === 'gnome'

You can put this in src/service/__init__.js as globalThis.HAVE_GNOME if you want, or leave it here.

[JingMatrix]

@andyholmes Thanks for mentioning it, I totally forgot it. So I guess we may use the existence of the directory /usr/share/cinnamon/js/ui/* as a detector.

Or, alternatively, is there a way to communicate bewteen the extention.js and daemon.js?
If so, we can set HAVE_GNOME in extension.js.

[JingMatrix]

I propose to use imports.gi.Shell as a heuristic for setting HAVE_GNOME.
See my pull-request for details: #1715 (comment)