[gst-devel] auto-detecting sinks

[Thomas Vander Stichele]

Hey Steve,

> > One thing I'd like to get some opinion on is adding GError to all the
> > public methods of libgstgconf. It breaks API, but I think the
> > higher-level code needs detailed errors rather than just null return
> > values.
> > 
> > Finally, there will eventually be new methods which would return a list
> > of viable sink pipelines ordered by preference. This could be used by an
> > Audio & Video capplet so users can change their sink.
> > 
> > I've started this work now so any suggestions are welcome.
> 
> Wicked, this is one of the major problems with Totem-gst (error
> reporting). I would actually prefer it if the library could return error
> codes rather than GErrors, because until gst makes the move to gnome
> cvs, it will have poor i18n compared to a component that is in there.

Yep, I've had the same worries at that time.  I didn't implement anything 
because I already had set that API without thinking about error handling 
and then I probably forgot about it when we had a chance to change it.

Here are my suggestions:

a) instead of breaking api, we could name the error-returning functions
*_error () and implement the non-error-returning functions based on this.
This would allow apps to be buildable against both 0.6 and 0.7 (since 0.6 
doesn't allow API breakage).  We could then mark the original ones as 
deprecated and to be removed for 0.8.
Alternatively, you can invent totally new names as well for these 
functions.  I just want to avoid not being able to compile against stable, 
so that these functions can be added in 0.6.x and used by apps that are 
"stable".
(I personally think it's unlikely we'll have a good 0.8.x series in time 
for gnome 2.4.x, btw, so this is why I'm making this point)

b) on returning GError vs numerical error (I suppose we're talking about a 
final argument pointer, right ?)
   I used to want to also have numerical errors for the same reason;
   OTOH, that would cause every one to invent their own message for the
   problem at hand and that would be a lot of duplication of effort and
   probably lead to bad error messages :)
   Also, I don't want libgstplay moved to gnome cvs because it should
   be kept generic and under gst's control.
 
   So the idea I had back then would be to i18n the lib, use GError's,
   and create a gnome-cvs module for libgstplay that would contain
   translations only, with a script in our gst cvs to sync from that and
   commit.
  
   I've been told that translators actually do not run all the software
   they translate, so this is not a problem.

What do you think ?

Thomas

 -- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
yes i am
a long way
from home
<-*- thomas  (at) apestaart (dot) org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/