Re: [gtk-list] Interpreter requests

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:

> Since the development series of Gtk is getting some work, now, I'd like to
> make some requests (I must apologize for not doing the work myself) to
> facilitate interpreter bindings:

I'd like to second this, and add some comments:
 
>  2. Make all usage of GtkArg's similar: currently the return value of a
> signal routine is implicitly a pointer, thus needing two sets of routines
> to pack/unpack GtkArgs. In an interpreter binding, this is a large amount
> of code, as these are workhorse routines. This is better replaced with a
> standardized mechanism for saying that the return arg is a "WRITE-ONLY
> POINTER TO INT", or somesuch, so the pack/unpack routines can be
> universal. 

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.  I noticed the code
duplication, too, but I think it is not too bad.  Only 57 additional
lines of code.

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

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.  [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?]

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.

>  4. Add a bit more .defs information describing whether the contents of a
> structure are important, the pointer to a structure, or both.

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.

> (I still don't know what to do with colormaps, btw. :-)

Colormaps are ref_counted with gdk_colormap_ref and
gdk_colormap_unref, no?

>  5. Add information (somewhere, perhaps the .defs files) indicating which
> function arguments can be NULL. It's especially important to know which
> widget pointers can legitimately be null.

There is the argument option `(null-ok)' that you can use for this.
The *.defs file might not be totally uptodate with respect to this,
tho.

> That's just off the top of my head, I'm sure I'll come up with some more
> stuff.

Here is some from me:
 
 6. Add a light-weight signal to GtkObject that can be used to trace
all internal references of a GtkObject.  This signal should work
somewhat like gtk_container_foreach but should include absolutely all
(counted) references that a GtkObject has to other GtkObjects.  This
can then be used to do precise garbage collection with a tracing
collector.  This prompts for changes in all widgets, but it is safe to
do these incrementally.  Missing some or all internal references might
lead to memory leaks (but not in the common case), but it will not
affect robustness.

[With light-weight I mean it should just be function pointer in the
 GtkObjectCalass struct, no gtk_signal_new, no handlers, no
 marshalling; just like the finalize light-weight signal.  It's
 probably best not to call these things `signal'.  In fact, I'm a bit
 worried about how the current signal machinery mixes `notification'
 with `virtual functions'.]

 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.

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

regards,
 Marius