[gst-devel] GNOME & GStreamer: take two

[Bastien Nocera]

Christian Schaller wrote:

 > On 09 Aug 2001 09:35:38 +0100, Bastien Nocera wrote:
 >
 >> Hi,
 >>
 >> Christian Schaller wrote:
 >>
 >>> On 07 Aug 2001 22:53:11 +0100, Bastien Nocera wrote:
 >> <snip>
 >>> Actually, Sysadmins would want to be able to lock down such
 >>> things to
 >> avoid
 >>> having to support users who have messed up their configuration.
 >>> Also
 >>
 >> With preferences, they _can't_ mess up their configuration. I
 >> agree that  settings (which can mess up the computer) would need
 >> to be handled by  the sysadmin. I fail to see how you can mess up
 >>  a gstreamer  _configuration_ though.
 >>
 > Mess up is a wide term, but something as simple as users switching
 > from OSS  to ESD when no ESD is installed generates extra work for
 > the sysadmin when the users don't understand how to set it back
 > again themselves. Never underestimate the ability of users to mess
 > up their setup.



This is a setting... And like I said earlier, we don't need to ask the
user (or even the administrator) about it. If ESD is running, we use
ESD, if aRts is running we use aRts, if OSS is present we use OSS, etc.

If there is no way to change this, there is no need for this to be
configurable at all. Same thing goes for video output. If X isn't
running you're obviously not gonna be using the xvideosink...

What you want in the capplet are _preferences_ not settings (like, use X
or SDL for X video output).

What you actually want is a gstreamer helper function for applications
to use. Like, instead of hard-coding oss/esd/whatever you use:
GstElement *gst_audio_sink(void);

and have the gst_audio_sink implemented in libgst. Much of the things 
you want in the capplet are actually better not asked to the user or to 
anyone. How can the administrator know if the user has checked "Enable 
sound server at startup" or not in his Sound configuration capplet ?

Make an exhaustive list of what you think would need to be configurable, 
and we'll see if it's actually of any use to have a capplet. If it's to 
see only one "not so important" preference in the capplet, I think we'd 
rather not have one.

 >> from
 >>> a GNOME perspective one stop shopping for settings is
 >>> prefereable.
 >>>
 >>> If we use the Gconf interface and not bonobo-config I think we
 >>> will not need the Bonobo-activation (OAF) or Orbit dependency.
 >>>
 >>
 >> Here are the run-time dependencies for gconf: $ apt-cache show
 >> libgconf11 | grep Depends Depends: libc6 (>= 2.2.3-1), libdb3 (>=
 >>  3.2.9-1), libglib1.2 (>= 1.2.0), libgtk1.2 (>= 1.2.10-1),
 >> liboaf0 (>= 0.6.5), liborbit0 (>= 0.5.8), libxml1, oaf (>=
 >> 0.6.5), xlibs (>> 4.0.3), zlib1g (>= 1:1.1.3)
 >>
 >> OAF and Orbit in there...
 >>
 >> Guess you were wrong ;)
 >>
 > Guess so :)
 >
 > ...but even so I don't think adding dependency to GNOME libraries on
 >  a  GNOME control-center capplet should be a problem, especially if
 >  we supply a compile without GConf option. :)

How would the different GUIs share the same configuration, if they use 
different configuration backends ?

Cheers