[gstreamer-bugs] [Bug 638663] RFC: track bus (error, warning, info) messages in discoverer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=638663
  GStreamer | gst-plugins-base | unspecified

--- Comment #4 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2011-02-08 10:54:52 UTC ---
> So we agree that the elements should use something that uses a GError (which
> includes a domain, code and message)

I'm not sure of that. I think just a code + message doesn't provide enough
detail and leaves no room for expansion (also, I don't think we want to expose
loots of these codes in core header files). I think we'd want such things to be
machine-processable and more structured, not just free-form string messages to
the user. e.g. if we're not reading some Qt Atom because it's broken or we
can't handle it we might want to  say which atom it is (just a random example
why I don't think just a code is enough).

I have no specific ideas about how to do this exactly though. Someone would
need to go through the code and get the various
GST_WARNING/GST_ERROR/GST_ELEMENT_WARNING to make a list of possibilities.
(Also, the scope isn't quite clear yet, e.g. is it only brokenness or would
such an API also be used to signal whether an index is present, for example?)


> GST_ELEMENT_{ERROR,WARNING,INFO}
> macros? Would it be okay to use GST_MESSAGE_{ERROR,WARNING,INFO}? That's
> basically the part I need. If not, I would suggest that someone clarifies the
> purpose of GST_MESSAGE_[WARNING,INFO} in the API docs.

It's not about the macros, but the messages for me. I don't know what the
original intention was when they were added, but they are clearly for alerting
the user of things. But most of the stuff we're talking about here "the user"
does not really need to know.


> The benefit of getting this info to the app over the bus (instead of just
> having it in the log) would be that apps can indicate to the user that one
> media file might not work perfectly (e.g. it contains inconsistent info and the
> implementation made the wrong decision).

I agree that there would be benefits in exposing such info to the application
(via the bus), it's just that I don't think GST_MESSAGE_{ERROR,WARNING,INFO}
isn't the right vehicle for that.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.