[bug#70282] [PATCH v2] gnu: gnome-shell: Wrap screencast service.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Samstag, dem 20.04.2024 um 10:11 +0000 schrieb Dariqq:
> 
> 
> On 19.04.24 20:51, Liliana Marie Prikler wrote:
> > Am Freitag, dem 12.04.2024 um 17:26 +0000 schrieb Dariqq:
> > > The screencast service can now find typelibs and gstreamer
> > > plugins.
> > > 
> > > * gnu/packages/linux.scm (gnome-shell)
> > > [inputs]: Add gst-plugins-good and pipewire.
> > > [#:phases]<'wrap-programs>: Create a wrapper for screencast
> > > service
> > > and use it.
> > > 
> > > Change-Id: I2c31bf1bd92e281b86c57b06988c6a3793a58d40
> > > ---
> > > 
> > > Hi,
> > > 
> > > Here is v2 of the patch. The wrapper is now created manually as I
> > > was unable to find a way to manipulate the gstreamer plugin load
> > > path from within javascript. Importantly this leaves the original
> > > javascript file untouched and therefore circumvents the argv[0]
> > > problem in v1.
> > > All the required gstreamer plugins (pipewire and gst-plugins-
> > > good) are now inputs and are in the wrapper via
> > > GST_PLUGIN_SYSTEM_PATH.
> > I'm not sure this fix is sounds.  It looks like it misses manual
> > invocation from the command line, does it not?  (Well, it's gnome-
> > shell, so if you have to invoke it from the command line, things
> > are broken, but still…)
> 
> If only the typelib path is set the dbus service now longer greets
> you with an error but still fails to start without the gstreamer
> plugins.  That's why in v1 I was propagating pipewire through
> gnome-essential-extras.
> 
> I am not sure what you mean by manual invocation. The screencast
> service  should get started via dbus. Nothing manual should be
> required (other than enabling the pipewire home service).
Just what it says on the tin, manually running the "binary" through the
command line.  It's not super useful with GNOME, but I think we should
make sure our services work whichever way they could be invoked.

>    What keeps you from wrapping the environment
> > variable in Javascript?
> 
> I was unable to find a way to manipulate the GST_PLUGIN_PATH or
> specify the gst search path from within javascript. There is 
> Gst.Registry().scan_path but this creates a new registry and I don't 
> think is what we want here. (but I don't know anything about
> gstreamer and javascript so I could be wrong here).
Instead of creating a new Gst.Registry – as per the () here – you could
use gst_registry_get() or whatever the according JS method is to access
the Registry singleton.

The Registry constructor ought to be protected, but idk how GJS handles
that.

> I guess the most simple patch for the typelibs would be something
> like
> 
> 
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index fa6c566c75..28c4e540a6 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -9404,13 +9404,15 @@ (define-public gnome-shell
>                        (wrap-program (string-append #$output "/bin/"
> prog)
>                          `("GI_TYPELIB_PATH" ":" prefix 
> (,gi-typelib-path))))
>                      '("gnome-shell" "gnome-extensions-app"))
> -                  (substitute* (string-append #$output 
> "/share/gnome-shell/"
> -                                             
> "org.gnome.Shell.Extensions")
> -                    (("imports\\.package\\.start" all)
> -                     (string-append "'" gi-typelib-path 
> "'.split(':').forEach("
> -                                    "path => 
> imports.gi.GIRepository.Repository."
> -                                    "prepend_search_path(path));\n"
> -                                    all)))
> +                  (for-each
> +                   (lambda (prog)
> +                     (substitute* (string-append #$output 
> "/share/gnome-shell/" prog)
> +                       (("imports\\.package\\.start" all)
> +                        (string-append "'" gi-typelib-path 
> "'.split(':').forEach("
> +                                       "path => 
> imports.gi.GIRepository.Repository."
> +                                      
> "prepend_search_path(path));\n"
> +                                       all))))
> +                   '("org.gnome.Shell.Extensions" 
> "org.gnome.Shell.Screencast"))
>                     (for-each
>                      (lambda (prog)
>                        (wrap-program (string-append #$output "/bin/"
> prog)
> 
> 
> and dealing with the gstreamer plugins in another way.
Hmm, could you add --gst-plugin-path on the command line?

> > > I've also left a comment for the required home-pipewire-service.
> > > In gnome-shell 45+ the invocation has changed to 'gjs -m
> > > service'.
> > > Should this also be a comment somewhere?
> > Gnome-shell 45+ is currently irrelevant, but we might have to adapt
> > things once we get there on gnome-team.  We do need a better gjs-
> > patching strategy.
> > 
> 
> It would be nice if something like wrap-script would work. But the 
> problem is that the dbus services specify somehting like "Exec= gjs 
> service" rather than executing a gjs-script directly. (which is the
> main purpose of the patch from nixos). And also gjs not being a valid
> interpreter for wrap-script (Changing that will rebuild everything)
You can redo the needed logic locally and add a "XXX: Use wrap-script
once it can handle gjs" for example.  That's no hard blocker, but it's
not the nicest option either, I admit.  Let's try our other options
first.

> 
Cheers