[gstreamer-bugs] [Bug 396774] Make GstElementDetails extensible

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=396774
  GStreamer | gstreamer (core) | git

--- Comment #31 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-08-16 06:39:42 UTC ---
The setters indeed have the disadvantage of becoming somewhat domain specific.
That was solved in the GstTaglist by having more tag defines elsewhere.
Although sometimes those are not so easy to discover. People probably only find
then as they share the namespace. In the same way we could introduce such
defines/methods in audio/video libs as well. We'd just call them
gst_element_class_set_audio_xxx() (or having a define
GST_ELEMENT_METADATA_AUDIO_XXX) I'd use a 'namespace' for the actual key
internaly (e.g. "audio::xxx");
If that is okay, we could still use methods instead of macros (to make it
easier for bindings). Still having member spread across the packages would
probably still confuse bindings.

A plan B would be to only add generic metadata in core and expose the
GstStructure.:
- apps could iterate it (the only way for gst-inspect to show all of them if we
start to define more in e.g. gst-plugin-base and unless we register known
keys). 
- wrapper plugins can add own keys and just document them in the plugin

Just as an example, it has help the camera development a lot, that we can just
use arbitrary strings in a taglist for r&d phase.

So, unless new arguments show up, my preference would be #defines for the key
(for no only in core) and setters/getters as in #comment 28. The naming of the
defines is still ugly though (GST_ELEMENT_METADATA_XXX,
GST_DELEMENT_DETAIL_XXX).

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