[gst-devel] gst-player CVS

[Thomas Vander Stichele]

Hi,

> On Thu, Sep 26, 2002 at 10:37:05AM +0200, Thomas Vander Stichele wrote:
> > > How about this patch?
> > 
> > I was about to commit, then realized that this should be done in the app, 
> > not in the library.  Meaning, gst-player should try to render, and if it 
> > fails, use it's default settings instead of having it crash.
> > 
> > What do you think ?
> 
> Well .. i agree in principle but gst-gconf API is trying to make
> things automatic.

What it currently does is allow for any "partial pipeline" to be parsed 
into one element.  Nothing more than that.  So it doesn't really know 
that you're asking for an "audio-type" sink or source, so it doesn't have 
or should have the knowledge to fall back to a reasonable default.

> If the error recover should be done in the
> app then some of the code should come out of the plugin and
> into the app since the fallback case needs that code anyway.

For me, the dividing line was "give an app a one line function call to get 
the default desktop output method for this type".  There are apps who 
might, from that point, just error out (because they're lazy ;)) or there 
are apps who try to work around it.  Of course ideally the gconf key 
should be set right anyway, but that's another matter.

What I basically wanted to avoid when I created this gconf helper lib is
a) some apps that only try to do an element_factory_make from the gconf 
key, which would cause them to fail if the gconf key setting was for 
example osssink sync=false
b) each app having it's own copy of code that does proper parsing. 

> What do u suggest?  Only developers are likely to hit this case anyway ...

What I'm doing right now is adding some code to gst-player that throws up 
a warning to ask you to inspect the key.  I'll see what that brings out
as a problem in the gconf helper lib.

I'm all for adding some more stuff to the helper lib (probably starting 
with GError stuff so that it's more descriptive), but I prefer to not 
anything that tries to second-guess the user or administrator, like 
choosing xvideosink as a default if the key could not be parsed.

Of course I might be totally wrong on this so I'm still taking 
suggestions, but having thought about this a lot this week this is how I 
feel about it currently ;)

I'll put up another prerelease when I have all the warnings working so you 
can see how it works.

Thomas

 -- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
morgen wordt het beter beter voor iedereen
dan krijg ik de strop
en jij wat je verdiende
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/