[gst-devel] error handling in gstreamer

[Thomas Vander Stichele]

Hi,

Dolphy has just added error handling in gst-player, and it's great,
because it's necessary for further GNOME integration.

While testing this, it pointed out a very obvious problem.  I selected
"chart" from the menu of vis stuff, set to play, and got the error
"could not negotiate format".

Now, if a user sees that, I don't really know what he is supposed to do
:)

As Julien told me, this is because chart only does mono.  So chart needs
fixing.  But the bigger issue is, this error message is totally crap.
It's completely useless because it doesn't help neither the user nor us
as developers to figure out what goes wrong.

What the error message SHOULD say is something like "vorbisfile: could
not connect stereo to mono between vorbisfile and chart", or something
to that effect.  That would be a useful error message because it can be
reported back to us for fixing.

Now, what I want to ask/discuss is, how can we make this happen ? It
needs changes on a few levels.

The error message itself is generated in vorbisfile.
gst_vorbisfile_new_link is called when a new link is being set up.  It
calls gst_pad_try_set_caps, and then it returns FALSE when that fails.
The calling function (gst_vorbisfile_loop) then prints this very obtuse
error message because of that.

Now, the question is, how do we get the relevant data out of the core to
the UI ?

gst_pad_try_set_caps doesn't offer any clue on why it failed.  It should
somehow be able to tell us that it failed because it can't link stereo
to mono.  One possible way of doing this is have a new function (e.g.
gst_pad_try_set_caps_error (pad, caps, error)), where error offers some
indication of what went wrong (what error is exactly is to be
discussed).

Now, as for the format of this error, I think we have three possible
choices:
a) define a bunch of enums for GST_ERROR's, a la GST_ERROR_CAPS_FORMAT
in this case
b) create a GstError that is very gst-specific
c) use GError

The advantage of a) is that we do not have to i18n these messages at
all, and leave that up to the apps.  The disadvantage is that it doesn't
work well for our free-form core code; ie, there is no concept of
"format" or "width" because the caps can contain whatever they want.

b) or c) will take more work, but IMO is the right way to go.

The question then is, how do we handle i18n.  I see a few possible ways
of doing this :

a) gettextize plugins (and possibly core), keep .po files in our cvs
b) gettextize, put .po files in gnome cvs and sync them back regularly
c) don't gettextize, but provide helper functions to help an app i18nize
their own messages based on our english messages
d) gettextize, move to gnome cvs

I'm not sure what the best option is at this point (leaning towards b)
though), but we need to discuss it.

That's about what I wanted to get discussed; with gst-player becoming
this good, and totem-gst having a shot at making it in gnome 2.4, I
think it is very important we start attacking this problem very soon.
(For the record, I do percieve this as a reallly big problem :))

Thoughts, comments, ... ? :)

Thomas
 

Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
and it looks so pretty
all those tiny bright lights
calling my name
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/