[gst-devel] gconf stuff

[Thomas Vander Stichele]

Answering to some mails all in once here ;)

* re: Steve's mail : yes, we need to provide a sensible default.
  I'm not sure if providing a meta-plugin that replaces itself would be
  the right way to do this however.  The code for detecting what is the 
  best one could go in one of the gstreamer parts, but not using the 
  plugin method - at least not by default.  I do not really like my system
  second-guessing my decisions, and I do not like the overhead of running 
  this autoplugging audio element every time.
  I'm not saying that this approach wouldn't work, and the caching would 
  eliminate the second counterpoint, but I like my plugins relatively
  dumb and system-agnostic ;)

> I have been thinking a lot on this too, since Seth Nickels (GNOME UI
> hacker) was very insistent that if we should do something to give people
> a working solution out of the box.

I agree with this in the long run.  In the short run I just want to start 
by making the situation better, and using GConf is a good way to make it 
better for both our player and rhythmbox and any app that will be made in 
the near future using GStreamer and Gnome.
A good start would be a small app that guides you through setting up 
GStreamer, allowing you to test a few output plugins as you go and select 
the ones that work best.
And I wouldn't mind if this app was gst-player ;)
I'm not familiar enough with capplets but it also sounds like the best way 
to go.
It would be nice, for example, if we could provide a shared configuration 
lib that is runnable from any app that uses GStreamer.  That, IMO, is the 
way to go.


> So while I agree that long term at least we should try to have a system
> that makes an intelligent guessimate on what the users want, due to
> situations like the one illustrated above I guess a capplet would be a
> good idea so that when people need/want to change it they don't have to
> start mucking with gconf-edit (which I think will be a rather high
> threshold for many).

Agreed, IMO this is step 2.

Step 1 is what I'm doing just now - getting the gconf thing rolling before 
every app out there uses it's own system and we get kicked for not having 
it done right ;)  We can't expect every app developer out there to really 
know about all the details that go into setting a good output, and it's up 
to us as the supporting library to provide a policy to do it right.

Of course, all of this is just MO.  Company for example arguest that this 
should go in a separate lib.
I disagree since I think there's no added value in doing that, just extra 
developer overhead.  But I'm sure points could be made either way.

Thomas

 -- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
Irene
niemand heeft ooit zo mooi
'neen' tegen mij gezegd
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/