宋文武 <iyzs...@gmail.com> 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
