Re: [gtk-list] Gtk and the scripting languages of the world

[Owen Taylor <owt1 cornell edu>]

[ Warnign, long, incoherent blatherings follow, ]

My comments here will be mostly from the perspective of Perl ...

> For example, take the pixmap test from "testgtk.c".  It has the
> following code to create a pixmap widget:

I think by using this code as an example, your emphasizing the
problem areas over the areas (most of them) where GTK is very easy to
bind to an interpreted language. Not to say that there aren't
improvements to be made, but I'm not sure it's worth trying to
abstract the interface too far. It's going to be necessary to write
some glue code by hand for any language if we want to have a truly
natural interface for that language. Otherwise, we'll have uniformly
clunky bindings in every language.

For instance, in Perl, the natural interface to gtk_widget_get_pointer
is:

  ($x,$y) = $widget->get_pointer;

Now this is great in Perl, and probably OK in scheme, but in some
languages (for example, C and C++) it would be a horrible nuisance if 
gtk_widget_get_pointer returned a list of values!

So it doesn't horrify me that you'd have to write a special case to
get handle different states in a GtkStyle. (And this was definitely
the worst special case I ran into while writing an interface to
essentially all of GTK)

> GTK_STATE_NORMAL, while being given a nice name, is still an ordinary
> integer and has no connection to the array indices. 

This isn't really isn't completely true - it's an enum value of state
GtkStateType. While its true that C is sloppy in enforcing these
things, this information is available to use while generating language
bindings.

> Therefore, it's not practical to export the Gtk API [wow, I never
> thought that I'd use that TLA without sarcasm] to some other language
> that doesn't have the problems of C.

Funny, Ken Albanowski seems to have done a pretty good job of it
so far ... ;-) But yes, generating an interface isn't completely
trivial and there are some snags.

> The typical interpreter has a dynamic type system.  Therefore, I think
> Gtk should also acquire a dynamic type system.  Most of it is already
> there, in the form of GtkObjects and GTK_ARG_INT, etc.  This needs to
> be unified and extended to *every* piece of data that could escape to
> the interpreter (that would probably include the Gdk structures but
> not GList, etc.)  Some types can be converted between Gtk and the
> interpreter (like ints or strings), but most probably cannot.

This sounds pretty expensive to me. A lot of the data structures in
GTK are pretty small structures and having to deal with typing all of
them dynamically could slow things down significantly. Plus the most
natural way of dealing with structures will depend on the language.

Perhaps we should say that anything that persists in GTK beyond the
scope of the call needs to be treated as an object. (But not as a GTK
object - extending the GTK type system back into GDK would be a
nightmare. Reference counting and maybe a bit more is what I mean
here, and reference counting is mostly already there) (The distinction
here is between structures that basically just pack up a collection of
values, and structures that really represent some kind of object)

As I see it, the classification of GTK objects looks something like:

* enumerations (GdkWindowType, ...)
* bitfields (GdkEventMask, ...)
* structures (GdkColor, ...)
* Miscellaneous non-GtkObject "objects" (GdkWindow, GtkStyle, ...)
* GTK objects (GtkObject, GtkWidget, ............. )

What we maybe need if we want to make automatic interface generation
easy is a set of files that describe GTK types in an easily parseable
fashion. The GTK header files are almost stylized enough for this
use, but lack some important information (for instance, which fields
of a structure are public/private.) What you're proposing sounds like
a dynamic ProcDB type interface to this information, while I think a
static description is sufficient, decidedly more efficient, and
probably a whole lot more compatible.

(The dynamic interface concept I think is probably better suited to
something like Scheme, which doesn't have much of an object system of
its own, than to languages like Perl/Python/Java which are
(progressively from left to right) more typed). I'm not sure having
some type of abstract interface description language is better than
hand-crafting bindings, but it is appealing to think that when a
change is made to the core, a corresponding change could be made to
the description file, and it would propagate into the language
specific bindings without further manual intervention.

> The typical interpreter has a dynamic type system.  Therefore, I think
> Gtk should also acquire a dynamic type system.  Most of it is already
> there, in the form of GtkObjects and GTK_ARG_INT, etc.  This needs to
> be unified and extended to *every* piece of data that could escape to
> the interpreter (that would probably include the Gdk structures but
> not GList, etc.)  Some types can be converted between Gtk and the
> interpreter (like ints or strings), but most probably cannot.

Changes certainly need to be made to GTK_ARG_INT and friends, as
discussed earlier in postings by Ken Albanowski and followups. 

> There will also be some form of automatic memory management that Gtk
> has to respect.  This mostly effects how Gtk treats values from the
> interpreter that it stores away (like callbacks, or arbitrary user
> data) but also for Gtk objects in interpreter land.  Gtk already has a
> reference counting mechanism.  Although reference counting has its
> problems, I think we can make it work with some care.  (We only allow
> cycles for objects that are forcefully destroyed by the user, like
> widgets.)

I think we probably just need some design rules for GTK. Things like:

 * Any time an opaque pointer is passed into GTK to be stored
   (e.g., callback user data), a pointer to a function that will
   be called when the data is no longer needed will be passed as well.

 * Except for the exceptions (see above), no pointers passed into
   GTK will be stored.

 * No cycles for reference counted objects

> We will probably also need some form of composite data type that can
> travel between the two worlds.  Some form of a very restricted list
> (or vector) that can also be implemented with a vector (or list)
> should be enough.

I'm not sure I agree. GTK has GList's, which can be thunked into the
languages native list type at the border. Using anything but the
native type is really unattractive in Scheme or Perl.

> If you ask me, writing large, interactive programs in C sucks.  There
> has to be something like Phython, or Perl, or Scheme, or maybe even
> TCL.

OK, OK, OK, aargh! (throws up hands in horror) Actually, my opinion is
that the larger the program is the more you gain from having the core
written in something compiled and carefully typed. But interpreted
languages are great for extension and for little programs.

My general thought is that while some fairly minor (if not trivial)
changes to GTK would be quite useful, a major overhaul into a generic
interface is unecessary, would cause performance problems and/or a
clumsy interface for many languages, including C, and would be a big
backwards compatibility issue. Finally, any changes should be
carefully discussed with the people who are considering making changes
for doing a QT-like C++ interface.

Regards,
                                        Owen