On Thu, 2010-04-22 at 22:37 +0200, Fons Adriaensen wrote: > On Thu, Apr 22, 2010 at 06:22:24AM +0800, Ng Oon-Ee wrote: > > > On Wed, 2010-04-21 at 22:04 +0200, fons@xxxxxxxxxxxxxxx wrote: > > > > "GStreamer is a library for constructing graphs of media-handling > > > components. The applications it supports range from simple Ogg/Vorbis > > > playback, audio/video streaming to complex audio (mixing) and video > > > (non-linear editing) processing." > > > > > > Fine. Potentially very interesting and useful. > > > > > > But if it depends on things that have *nothing at all* > > > to do with the claimed application domain - security > > > subsystems (keyrings) and configuration programs for > > > a specific desktop (gconf) that, at least in my world, > > > is a sign of *crappy design*. Which seems to invade > > > almost everything Gnome. One is almost tempted to believe > > > that introducing irrelevant dependencies is the essence > > > of the game. > > > > > > Ciao, > > > > > Would you prefer the developer reimplement security-authorization and a > > configuration parser, then? Its not even as if gconf and its editor > > aren't separated into different packages. > > No. An application using gstreamer could depend on security > subsystems and desktop configuration parsing, and use libraries > for that. The audio/video code itself shouldn't. Unfortunately gstreamer is partly application in that it handles the authorization as well as reads configuration options. On my system ~/.gconf/system/gstreamer/0.10/default/%gconf.xml has the default settings for gstreamer (default audiosink and videosink). Perhaps those should be part of the gnome-media package instead (which depends on gstreamer and provides the gstreamer-properties binary), but what happens when gnome-media is not installed, what defaults would gstreamer fall back on when there ARE no defaults? Perhaps an upstream bug-report?
