[gst-devel] various 0.9 questions

Thomas Vander Stichele thomas at apestaart.org
Sun Aug 14 14:32:13 CEST 2005


> 1.) Why is GST_PADDING in gst/gstconfig.h.in ?

Why not ? What would moving it help ?

> I'd like to move this out (e.g. gst/gst.h) and either
> 1a) document it or
> 1b) tell gtk-doc that it is private

marking it private seems the correct thing to do.

> While we're at it, whats about all the GST_DISABLE_XXX defines. Are they
> of any interest for the developer (apart core). Should they get an
> onliner doc comment or be made private?

Aren't these adequately documented in configure --help ? Why do they
need more ?

> 2.) gst-plugins-base/gst/sine/gstsinesrc.c
> static GstFlowReturn
> gst_sinesrc_create (GstBaseSrc * basesrc, guint64 offset,
>     guint length, GstBuffer ** buffer)
> Shouldn't it be GstClockTime offset ?

Don't think so - IIRC this is byteoffset.

> 3.) GstMiniObject needs docs.
> Some quick pointers in PWGs Porting sectionb of what to check if one was
> using GstData before would be nice.

Yes; I think Ronald was writing a porting guide - Ronald ?

> 4.) marking new or changed stuff
> Speaking of docs. New or changed API should have:
> * Since: 0.9
> as part of the docs. This will result in an extra index of these symbols.

I'm not sure it does us much good at this point.  I completely see the
value in this for projects like GLib, that are API-compatible across
minor version increments, but we're not.  For 0.9 a lot of functions
would be marked this way.  Maybe a good start would be to check first
how many new methods there are.

I do completely see the value in this between micro versions, and I
think I've done this a few times in the 0.8 series.  What do you think ?

As for the amount of undocumented stuff - totally, this needs to be
fixed.  It was our hope people that were reading and following up on
Wim's design notes sent to the list would result in some people adding
gtk-doc strings.  I have done so a few times as I was going through a
subsystem and learning about the changes.  I also added a few unit tests
when I did this.  It's an excellent way for someone new to GStreamer's
internals to get familiar with the code.


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
God how I hate myself for
still wanting her
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/

More information about the gstreamer-devel mailing list