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

[Marius Vollmer <mvo zagadka ping de>]

Owen Taylor <owt1@cornell.edu> writes:
> 
> My comments here will be mostly from the perspective of Perl ...

BTW, where would I find Kenneth' Perl bindings?  I have tried to work
my way into the CPAN, but without luck.  A precise ftp location would
help alot...

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

Yes, that was the point of it.  You are right, large parts of Gtk are
very easy to wrap.  I tried it for Scheme and it worked very well.

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

Agreed, but I want to reduce the `non-linear' parts (those that
require hand-written glue) to a minimum.

And - independent wheather the stubs are automatically generated or
not - it should be possible to make the bindings robust, considerably
more robust than the C interface.  Each gpointer should carry type
information with it, for example.

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

Yes, then we need two functions, one for C and one for the
interpreters.  But when the original author of gtk_widget_get_point is
aware of the difficulties of foreign language bindings and Gtk offers
tools and advice for working around them, he might actually design the
interfaces accordingly.

I'm mostly concerned with keeping up with the devlopment of Gtk and
extensions.  If Gtk would be an IEEE standard that is only revised
every 6 years or so, things would be different.

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

And I want to make sure that it will remain the only case.  Imagine
someone sitting there and designing the style mechanism.  If she has
interpreters in mind, she might say: "Well, this collection of
structures, arrays and magic indices doesn't translate cleanly to the
high-level interface.  But it's soo convienient for C code.  I guess,
I'll leave it the way it is and just add a function or two that are
straightforward to access from an interpreter."

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

But there's still no connection between the enum and the array
indices.
 
> > 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.

Yes, I've have to admit that I'm probably seeking the impossible:
automatically generating a robust and natural interface to every
imaginable interpreter.  But I still like to get as far as is
reasonable.

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

Ah no, I don't want to change Gtk to use a dynamic type system thru
out.  That would be silly.  Only when it comes in handy, mostly in the
spots where GTK_ARG_* is currently used and maybe for expressing the
exported function prototypes.

> [...]
>
> 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, ............. )

Yes, that's what I have in mind.

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

A static description would be fine with me.

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

Agreed.

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

That is what I'm hoping for.  I'm not sure that we can achieve that
goal...

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

Exactly.

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

Yes, if GList can fill the role, that is nice.  But GList items are
essentially untyped, right?  That could be a minar distraction.
 
> > 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.

[Ah, language war time! ;-) Ok, some quick comments from the hip,
because I can't resist...]

You might be surprised, but I actually agree with you wholeheartly.
But you can't get carefully (static) typing from C or even C++ in
general.  I think Gtk itself is a prime example.

> But interpreted languages are great for extension and for little
> programs.

At least Scheme is not tied to an interpretive implementation.  Heck,
there's also a TCL compiler (that mostly served to show how broken the
TCL semantics are).

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

I agree completely.  "Major overhaul" were probably the wrong words.
But I still think that the changes (or better: additions) would
require a non-trivial amount of work.

best regards,
 Marius