guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to handle required plugins and dbus services for GNOME Programs?


From: Mark H Weaver
Subject: Re: How to handle required plugins and dbus services for GNOME Programs?
Date: Thu, 25 Jun 2015 00:07:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

宋文武 <address@hidden> writes:
>> Actually, it turns out that 'grilo' doesn't need to be in the profile,
>> although if you don't have it you won't get the search path
>> recommendation which is crucial for Totem to work properly.
> According to ArchLinux, grilo-plugins is used for media discovery.
> Which is optional. I'm ok to add it though.

Without the grl-bookmarks grilo plugin, attempts to add local video
files to the playlist via the GUI interface silently fail.  See:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768515

I ran into this problem before I packaged 'gom'.  So, although it is
still possible to play local videos by running "totem <filename>", I
would say that Totem malfunctions quite badly even for basic usage
without grilo-plugins.

>> 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
>> need to explicitly install it and I'm not sure what would happen if it
>> were removed.
> It's safe to remove 'gstreamer' from inputs.

I don't understand.  Do you mean that it's safe to remove 'gstreamer'
from the inputs of some package?  Which package?

>> 'dconf' apparently needs to be in the profile for both GNOME Terminal
>> and Totem because of the session dbus service(s) it provides.  Without
>> it, modern GNOME programs behave quite badly.  They have no way to
>> access or change their own configuration settings, e.g. if you go into
>> their preferences, you see checkboxes that do not change their state
>> when clicked.
> Yes, dconf must in profile to be known to dbus-daemon (user sesssion).
> It's loaded by dbus-daemon when needed.
>
> https://developer.gnome.org/dconf/unstable/dconf-service.html
>>
>> I'm not sure how best to deal with issues like this, and also with
>> things like grilo-plugins and gst-plugins-* that are needed for the
>> proper functioning of Totem.  Should we make them propagated-inputs?
>>
>> Or perhaps they should be normal inputs and we should use a wrapper to
>> add those directories as suffixes to GRL_PLUGIN_PATH and
>> GST_PLUGIN_SYSTEM_PATH automatically?
> Given that plugins only needed at runtime, how about make a 'raw' totem
> package without wrapper and propagation, and a public one wrap it with
> envs?  Thus avoid the rebuild of the raw totem package if plugins was
> changed.

I'm not sure it would be worth it.  Totem itself doesn't take very long
to build.

     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]