Re: [gtk-list] Interpreter requests



On 7 Jun 1998, Marius Vollmer wrote:

> 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.

Agreed. The only problem I have with this is that it's very hard to hack
stuff into Gtk, due to it keeping private data very private. (A good
thing, usually.)

> > 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.

Well, a few new features, I suppose, but IMO the GTK_PTR_TYPE is useless
for interpreters, and the C code doesn't care whether it's broken or
fixed. 

> > > 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.

Indeed.:-)

> > 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?

Obviously I chose a different approach that ends up with more voluminous
functions. Also, I need four separate functions -- since I can emit
signals, I need to both pack and unpack return values. 

> > 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?

Couldn't hurt. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]