From Buzztard

Currently the plugins have no docs. The only reasonable path must be one that is as automated as possible.

[edit] content

Which informations do we want there?

• normal gtk-doc stuff
  • short desc (like the plugin description)
  • see also: which elements are related (oggdemux <-> vorbisdec)
  • long desc: what the element can do, a gst-lauch example
  • class hierarchy
  • extra methods and sinals
• image in the top right: gtk has images of their widges there. we could render images for elements and show them there. Can we generate an SVG and render it uzsing librsvg?
  • color show, wheter its a sink, source or transformer
  • sink pads on the left, source pads on the right
  • show pad types (normal, request, sometimes)
  • show media types for pads (audio, images, video, any)

[edit] using gtk-doc

The idea here is to

1. generate the types and section files from the registry
2. generate section docs from gst-inspect output
3. collect generated docs of several machines to build a master document

1) and 2) could be achived by having a custom gst-scanobj file that queries the registry and thus not needs a section file.