Re: Development of gstmm

[José Alburquerque <jaalburquerque cox net>]

Milosz Derezynski wrote:
> Hey Jos�>
> So first of all, help/involvement with the project would be really
> greatly appreciated at any time; the "bad news" is that gmmproc is
> only partially documented, and is (I dare to say in agreement i
> suppose? :) a rather obscure system which consists of many parts, and
> is written in a number of languages; there is in fact no "single"
> gmmproc.
>
> The best way to currently understand it in practice is to get involved
> with the system; feel free to ask further (about gmmproc or other
> things), and if you want to join in at some point, please simply say
> so, you can then get SVN access if you want to (which i guess you
> would).
>
> To answer your gmmproc questions:
>
> The .defs files are generated with a tool called h2def, which comes
> with (yes...) the pygtk+-2.0 source. So, you need to download
> pygtk+-2.0 from http://ftp.gnome.org/pub/GNOME/sources/pygtk/2.10/ ,
> run configure for the source, and then go into 'codegen' and from
> there you can use h2def.py, the syntax is "h2def.py <headerfile> >
> /path/to/output" (it ouputs to stdout so you need to redirect).
>
> It will output the declarations into a single file, in gstmm we split
> them into _enums, _methods, _properties and _signals (you don't really
> need to do this at first but finally the split should be made).
>
> For processing a .hg file you should add it to
> gst/src/Makefile_list_of_hg.am_fragment ; please make sure you never
> add a .hg file that doesn't actually exist, it leads to obscure build
> errors.
>
> If you want to start wrapping something, you need to generate a .hg
> file (.ccg files are often not even really needed, in case the entire
> class is 'gmmproc'-wrapped, so that the body will simply be generated
> entirely by it (gmmproc)), and then use _WRAP_METHOD, _WRAP_SIGNAL,
> etc.
>
> The 'gmmproc' system knows how to convert C++ types to C types and
> vice versa; the information for that is in various tools/m4/*.m4
> macros; one example is:
>
> _CONVERSION(`const Glib::RefPtr<Gst::Clock>&',`GstClock*',__CONVERT_REFPTR_TO_P)
>
> With this,it knows how to get a GstClock* from a
> Glib::RefPtr<Gst::Clock>, using the somewhere deeply hidden macro
> __CONVERT_REFPTR_TO_P (which is probably in RefPtrs<>'s case
> ->gobj()).
>
> The reverse conversion is:
> _CONVERSION(`GstClock*',`Glib::RefPtr<Gst::Clock>',`Gst::wrap($3)')
>
> That way it knows how to do the reverse, which it needs for wrapping C
> functions which return a GstClock*, to create a C++ equivalent of the
> function returning the wrapped C++ type.
>
> If more conversions are needed (and they will be) they should be added
> to convert_gst.m4, or to other .m4 files to split it all up, and then
> the various .m4 files need to be added to convert.m4, which includes
> all the other m4 files.
>
> Milosz
>
>   

Great information.  I'm sure this will get me started.  Just one more 
question:  The *.hg files are written by hand, right?  Thanks.

-Jose