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.