Gtk and the scripting languages of the world

[Marius Vollmer <mvo zagadka ping de>]

I'd like to design a common, high level interface to Gtk for the
benefit of the various scripting and extension languages.  I myself am
mostly interested in Scheme (guile) and don't speak Perl or Phython
and my only experience with Gtk comes from translating parts of
testgtk.c to Scheme.  So I'm not well equipped, but let me try anyway.

I welcome your cirticism and support very much; the following is
mostly opinion and not experience, so you will find ample opportunity
for flames, but please don't clutter the list with them.


The Gtk is a powerful and versatile graphical toolkit that offers
enough depth for the ambitous projects that surround it.  But
unfortunately, it is sometimes *necessary* to use rather involved
interfaces to achieve some mundane effect.

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

      GtkWidget *pixmapwid;
      GdkPixmap *pixmap;
      GdkBitmap *mask;
      GtkStyle *style;

      style=gtk_widget_get_style(button);
      pixmap = gdk_pixmap_create_from_xpm (window->window, &mask,
				 &style->bg[GTK_STATE_NORMAL], "test.xpm");
      pixmapwid = gtk_pixmap_new (pixmap, mask);

While this looks quite innocent, it uses some constructs that are very
natural (and ok) for C code but don't translate easily to more
high-level languages like Scheme.

First, the involved data types are not very abstract.  To get at the
normal background color of the style, you have to know that it is a
regular struct that has an array which is indexed by some magic
constants.

Then, some objects are passed by reference for efficiency reasons (the
transparent GdkColor) and some are passed by reference to hold
additional return values (the mask).  These conventions are not
enforced thru the type system and are therefore difficult to extract
for automatic stub generation.

GTK_STATE_NORMAL, while being given a nice name, is still an ordinary
integer and has no connection to the array indices.  There's no check
for overflow and nobody prevents you from writing
"style->bg[GTK_WINDOW_TOPLEVEL]".

Further, there is a lot of detail going on, for such a simple task,
but that's a different story.

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.

We need a more precise description of the things that Gtk offers.  In
addition, we should allow for the more dynamic nature of scripting
languages.  We should install a rich enough interface that is adequate
for all scripting languages that we care about.  Gtk and `third party'
widgets should be written to this interface (as far as possible
without hampering the C interface too much).

Whenever I say "interpreter" in the following, I mean the
implementation of your favourite scripting language.

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.

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

We also need a way to protect values from the interpreter that are
stored in Gtk objects (and possibly nowhere else) from being garbage
collected.  Gtk could help the scripting language maintain a reference
count on this values.  When the interpreter has some `real' garbage
collector, it can `mirror' the references that Gtk has to the value.

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.

This is all very vague but I already have some more concrete ideas.
They are not concrete enough to be written down and in any case, they
will probably require a major overhaul of Gtk.  So I would like to
hear from you if there's enough support for a clean interface to high
level languages.

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.

Marius

-- 
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.