Re: Development of gstmm

["Milosz Derezynski" <internalerror gmail com>]

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

On 11/2/07, José Alburquerque <jaalburquerque cox net> wrote:
> José Alburquerque wrote:
> >> BTW, if you have any more questions, please feel free to ask, not only
> >> that it will help you, but it might also help us to understand what
> >> people expect from the GStreamer C++ bindings.
> >>
> >> -- Milosz
> >>
> >>
> > Thanks for answering.  I completely understand the development stage
> > now.  I thought that gstmm development might need some help, but it is
> > clear to me that it is going just fine. :-)  For now, I will try to use
> > C in my application.  I look forward to success with gstmm and if I have
> > any more questions, I'll ask.  Thanks again.
> >
>
> Before I let this go, trying to use some C code, I noticed that use of
> signaling will probably be necessary (which wont be pretty).  If I  can
> I'd rather wait to use C++ code (it doesn't matter if it's a few months
> because I'm in on hurry).  Maybe in the mean time, I can sort of
> familiarize myself with the wrapping process in case I can help in some
> way (if you might accept some possible contribution to the wrapping
> process).  Maybe a few questions will clear things up in my mind:
>
> In the gst/src directory, there are a few *.defs files (it looks like
> they're written in scheme), where do they come from?  Are they written
> out manually?  I also notice that there are *.hg and *.ccg files.  As I
> understand from reading the gtkmmproc docs these files will be processed
> in the first pass to later generate the *.cc and *.h files.  What
> determines the processing of the *.hg *.ccg files?  (What I'm asking, if
> possible, is:  How was gtkmmproc "written" and how does it work?)  I
> know these may be general questions, but I really want to get a sense of
> what's going on in case I may be able to add something to gstmm.  Thanks.
>
> -Jose
>