gtk marshallers

[Karl Nelson <kenelson ece ucdavis edu>]

I am in the process of adding at least some minor form of
return type marshallers to gtk-- to solve a number of problems
relating the lose of return values in that wrapper.  However,
I don't want to completely reinvent the wheel or if I do I want
my wheel to closely match the wheel in gtk.

To do this, I am reading through the gtk source regarding signal
emittion and marshalling.  Thus far I have made very little sense
of it.  To be honest it looks kind of like to type of code that
occurs when my friends go out the pizza place, get drunk,
decide to write some piece of code, go home, code for 16 hours, 
wake up in the afternoon, and discover that we have written code.  Then
upon testing it we found it to work, but could make no sense of it
what-so-ever, so we left it entirely undocumented.  (This isn't
meant to be insulting; some of my friends do their best work while 
inebriated.)

Thus far I have deduced (probably incorrectly) that some signal emits are
delayed based on the RUN type of the signal.  That although most signals
use default marshaller, much of the stuff in GtkWidget doesn't.  Some
how marshallers take into account when multiple slots are on a signal, but
this involves function pointers, variable arguments, and an undocumented
structure that has a union of all possible data types as members.  And
that only God and the people who typed the code have any idea how this 
whole thing is organized.

Could someone please provide we with at least some basic theory about
the underlying signal emit process, some basic definitions of the enums
that control the behavior, a clue what the arg[?] definiton are,
and some general opinions on what if any of this is needed to implement 
new widgets at the C++ wrapper level (Ie.  does any one actually use this 
stuff).

Long rambling letters, pointers to long lost email discussing marshallers,
or brain transplants from coders lost in the wilderness greatly appreciated.
 
Thanks.

--Karl