GObject bindings continued...

[Havoc Pennington]

On Fri, 2004-03-19 at 23:05, Mike Kestner wrote:
> FWIW, I've already written this tool for Gtk# using perl and the
> perl-libXML bindings.  It parses C headers and source to produce an XML
> representation of the Fields, Signals, Properties, Methods and Virtual
> Class Methods for GObjects in addition to all the other struct and enum
> types in the headers.  If it's not exactly what you want, it's certainly
> closer than starting from scratch, if you don't mind hacking on a set of
> perl scripts.  

And there's gtk-doc and whatever pygtk uses and so forth. This wheel has
been reinvented a few times ;-)

> This would take some significantly more stringent coding standards than
> seem to exist today.  See below:
> 
> > For example, if a method takes a struct argument then the tool will
> > complain and bail out. If it takes "const char*" then that's "in string"
> > and if it takes "char **" then that's "out string"
> 
> Or it might be string[].  Similar problems exist around things like:
> 
> void foo (gint *bar);
> 
> Is bar an out int, ref int, or an array of ints?  We're still wrestling
> with all of this for Gtk#.  The approach we've taken is to default to
> the out param and alter the xml using another file of rules which we
> hand-code as we discover via audit/use any params that are really arrays
> or refs. So we have a fair amount of knowledge accumulated already that
> might be reusable here as well. 

Right, I went through all this for Inti back in the day. I think it'd be
useful to allow magic comments in the source to disambiguate. In the
dbus case, you always have the ability to edit the source code (you have
to add the #include for the metadata variable anyhow). Could also for
example be smart about "const int *array, int len" treating as a single
dbus arg.

> The thing I'm really missing right now is class method introspection. 
> There really is no way to intelligently override and chain to virtual
> methods now.  Basically, clones of g_signal_override_class_closure and
> g_signal_chain_from_overridden.  I don't know if you guys will trip over
> this for your application as well.

You're pointing out there's no way to override a method that isn't
registered as a signal, or am I misunderstanding?

Havoc