Re: [gtk-list] Interpreter requests

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:

> Anything to make an interpreter binding simple is worthwhile, IMO. (And I
> don't mean that just for my benefit: every technique we are talking about
> here helps make Gtk+ usable in ways we haven't even thought of yet. The
> key is 'run-time introspection', something that the Unix tradition hasn't
> encouraged.) 

Yes, totally agreed.  However, we should try to not impose too much
overhead onto the C API.  I think C will always be the dominant
language to use Gtk and we should optimize for that case.

The approach I have taken so far is to let the glue packages provide
the introspection facilities on their own, because they probably know
best how to do that.  We might unify that and put it back into Gtk.

> In this particular case, the key is to make the use of GtkArg's regular,
> so the return value doesn't need special purpose code.

This would not add new features but only cleanup the existing stuff,
right?  Code cleanliness is a good thing, of course.

> > I noticed the code duplication, too, but I think it is not too bad. 
> > Only 57 additional lines of code. 
> 
> 880 lines of code in the Perl binding.

Uhh, that's plenty.

> Almost all autogenerated, I must admit, but I'd prefer to go
> without. (What does it do, you ask? Build my module, and look at
> GtkDefs.c.)

I'm afraid I can't quickly understand what it does.  Guile-gtk has
three functions to convert from a GtkArg to Scheme values, from Scheme
values to a GtkArg, and from a GtkArg that has a return value to a
Scheme value.  Each of these functions is about 60 lines.  They are
used when invoking callbacks and for gtk_object_set, gtk_object_get.
In what situations does Gtk use GtkArg structures?

> Agreed. My .defs is quite hacked over (and appended to, etc.) 
> Unfortunately, I don't have much time to work on this thing. If you can
> draw up some proposals, I'll take a look at it. 

Same here.  This has to wait at least a few weeks.

> Among other things, it'd be nice to have a spec for third-party widgets so
> that they can be detected and linked in solely via thir .defs file. 

Would installing all .defs file into, say, <prefix>/share/gtk/ be enough?

> I think this could be fairly easily handled by a gtk_type_reduce_arg
> function, invoked if the type doesn't match. It'll either downcast an arg
> to a specified type, or return an error. The arg & signalling systems
> could plug into this easily, without an extreme amount of overhead.

Yes, that's what I have in mind, too.