[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