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

[Kenneth Albanowski <kjahds kjahds kjahds com>]

On Thu, 21 Aug 1997, Owen Taylor wrote:

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

I certainly have done that. Yes, I found binding GTK to Perl to be _very_
simple, very clean, and in fact far superior to something simpler like a
complete GNU Readline binding (which is, in fact, impossible, at least
with 2.0.) 

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

Sure, interface differences will always play hob, but that's why we have
wrapper code -- so that you can work these things out.

I don't believe there is any single mechanism you can reliably use to
describe an interface in a way that is transportable to all languages
without abominations in one (like lvalue arguments being used in Perl) or
the other (returning a list of values in C).

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

The real trick is enforcing it in other languages. I've found Java to be
the best for this, (but only) because it has static typing and importation
of nested packages. The result makes it dead simple to implement
enumerations that are type-safe at compile time and run-time. (Though
allowing arbitrary values and bit-flags is a tad harder.)

I've yet to see any interface description mechanism that deals usefully
with enumerations. The C technique is, of course, a cop-out. 

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

Agreed. And I didn't need this at all, because almost all of the Gtk and
Gdk types are quite static -- a function call always takes a type of a
particular sort and returns a type of a particular sort. Once those types
were modelled in XS, there was no need for dynamic type recognition.

The only exception to that is, of course, Gtk objects, for which I used a
list of type numbers to reference object->klass->type into the appropriate
Perl type. 

> As I see it, the classification of GTK objects looks something like:
> 
> * enumerations (GdkWindowType, ...)
> * bitfields (GdkEventMask, ...)
> * structures (GdkColor, ...)

You need to distinguish between GdkColor, which is always managed by Gdk
as part of another object, and GdkPoint, for example, which is allocated
and copied on the fly.

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

Oh, and one other thing I _really_ need: a list of which pointer arguments
can safely be left NULL. It's dead simple to crash the Perl module by
feeding undef in places where it expects a value of some type, and the
Perl code is helpless to detect where the error occured.

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

Yes, that is very important. Ideally, the functions that store a single
arbitrary pointer away (like the selection and Gdk user_data stuff) would
allow a second/third slot for type and/or length. Unfortunately, where the
X routines are involved, there isn't much that can be done about that. 

>  * Except for the exceptions (see above), no pointers passed into
>    GTK will be stored.
> 
>  * No cycles for reference counted objects

And allow an external library to participate in reference counting! If the
Perl module were to _ref and _unref Gtk objects, then the destroy
mechanism breaks down, as the object never has zero ref counts.

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

Agreed. Perl could do it, in theory, but that part (tied arrays) isn't
actually finished yet.

So far, it appears we've been very lucky with Gtk/Gdk: at no point does
program code need to _modify_ a GList or GSList owned by another object.
Lists are only passed into or out of functions, or copied from the
structure. These are easy to translate into copy operations to the
languages native list mechanism. Lvalue lists would be much more
troublesome, and hopefully can be avoided.

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

My viewpoint is that some mechanism for describing the types can
easily be added transparently to the current code. Most of it is just
documentation or comment headers, with perhaps comments in the actual
prototypes to make automatic processing possible. The only important code
change I can see is getting GTK_ARG_* o describe enums and pointers fully.

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