Re: [gtk-list] Interpreter requests

[Kenneth Albanowski <kjahds kjahds com>]

On 6 Jun 1998, Marius Vollmer wrote:

> Yes.  I think we should ditch the GTK_RETLOC_* macros and just use
> GTK_VALUE_* for return values.  This means changing *all* marshalling
> functions, so it might not be worthwhile. 

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

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. It makes the most
sense, therefore, to treat it identically to a 'WRITE-ONLY' argument, and
whether that be by reference or value is up to the implementors. 

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

> >  3. Some simple mechanism of looking up the names of object variables. 
> > Currently the procedure needed to see whether "X" is a variable of class
> > "Y" is quite tedious, involving pasting together "Y::X", seeing if it is
> > legal, if not, try "Y-Ancestor::X", and then "Y::signal::X",
> > "Y-Ancestor::signal::X", etc. A function to automate this lookup (and
> > return type information at the same time) would be very helpful. 
> 
> We should the key handling of gtk_object_new and gtk_object_set be
> smarter.  It should accept "GtkButton::label", as well as "label".
> The searching for the key should start at some class and then continue
> with the base class, and the then the base^2 class, etc.  When
> specifying a qualified key "class::attribute", the search should start
> at "class"; when specifying an unqualified key "attribute", the
> searching should start at the most derived class.

Yes, that's precisely what I implemented outside of Gtk+ (which wasn't
easy.) I reckoned that a Perl user probably doesn't want to care that
'GtkButton::label' is needed to set the label of his perl
MyStuff::Neato::Button widget.

> This will not only make using these functions more convenient and the
> code easier on the eyes, but it actually adds more functionality.  We
> can then move some attributes into a base class and user code will
> still work. 

Hmm, yes, that seems reasonable. On the other hand, requiring the class
name means that the action won't break if you replace the object with a
descendant type. (Equally, the action cannot change in the circumstance,
either.)

> [Btw. I propose to call these things `attributes'.  The
> natural name would probably be `slots', but this term is already taken
> by geometry management, right?]

Could be called 'variables', as well.

> The latest release of guile-gtk contains some code to (partially)
> shoe-horn this onto the current Gtk implementation.  I think it's not
> too inefficient, so you might want have a look.  It's on ftp.gimp.org
> right next to your Perl bindings in the guile/ subdir.

My code is in 'FindArgumentType' in GtkTypes.c. Mine looks a little
fancier, as it tries to convert Perl naming convention to Gtk -- manually. 
Hmm, you keep a translation table, which may make a bit more sense, in
this case. 

> The .defs file stuff is not in the best shape it could be.  I think
> the best would be to actually remove gtk.defs from the Gtk distro and
> make sure that gtktypebuiltins is always upto date with some adhoc
> perl or whatever.
> 
> The version of gtk.defs in guile-gtk has actually evolved away from
> the gtk.defs in Gtk.  We should coordinate what we would like in the
> *.defs files (including syntax, installation locations, mechanism for
> third party widgets, etc), document it and then move it back into Gtk.

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. 

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. 

> Colormaps are ref_counted with gdk_colormap_ref and
> gdk_colormap_unref, no?

Indeed they are. Those creeped in without my noticing. :-)

>  7. Make the GtkType mechanism be closer to a real dynamic type
> system.  This means that the producer of a value should also be the
> one who decides about the type.  For example, when constructing the
> GtkArg array for gtk_object_set, the caller should be able to put in
> the type that he thinks is the most appropriate.  The attribute setter
> routine of the actual widget should then look at the type and deal
> with whatever it finds.
> 
> The concrete situation I'm thinking about is the "signal::<name>"
> pseudo-attribute.  The setter routine requests a GTK_TYPE_SIGNAL, but
> interpreters would certainly want to use GTK_TYPE_CALLBACK.
> 
> The setter functions should still provide a default type and maybe
> even a separate type checking routine that could be used by the
> interpreter glue code to produce appropriate error messages.  This
> overhead is not necessary for the C API, so we should probably have a
> layered system, where the C API uses the lower level setter functions
> that do no checking at all, and an upper level, that is more expensive
> but also more flexible.

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.

Another from me:

 8. Hooks into the type creation system, so that we can get notified
whenever a new type is installed, allowing an interpreter binding both to
delay initialization until really needed, and to support, to some degree,
the installation of completely novel widgets at run-time. (Hmm. This
implies that a widget should be able to, in some manner, deliver its .defs
data at run-time.)

> Standard disclaimer: I do not have the time to actually work on this
> and I'm not at all happy about that fact.

Likewise.

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