Re: GTK modula-3 bindings

["Daniel Solaz" <dsolaz sistelcom com>]

Michael Beach wrote:
>A quite convenient way to do it may well be to use the gtk.defs file,
>which describes the API in a more or less language independent way. It's
>written in a parenthesized prefix (ie LISP-ish) style, which you may or
>may not like the look of, but is dead easy to parse. Of course, if you
>are comfortable with LISP or Scheme, then you don't even need to
>explicitly parse it, just read the forms straight in.
Thank you. Yes, I happen to use and like LISP a lot. I'll have a look at
it.
However, this translation of all GTK types and then the procedures is
the HARD way (the same the DEC guys did for X headers, totalling 440
Kbytes of code). I've been considering an EASY one: the possibility of
creating my own hierarchy of objects, letting the Modula-3 type system,
which is far more strict that C's, handle 'castings', and giving pure
ADDRESSes (references to memory not traced by the garbage collector,
equivalent to C's void*) to the translation layer. This is more of a
hack, but I'm already popping windows in this way and will next go for
callbacks.
Questions:
(notice: I'm learning GTK by the way)
I see almost everything in GTK is done through functions and pointers to
GtkWidget structs (that is, no direct access to struct members). Is it
really safe if I do so from m3? Will I be able to declare a base class
with just one data atribute (the ADDRESS that points to GTK struct) and
the corresponding suite of methods, and subclass that?
My hierarchy of objects would follow GTK's. The docs say clearly that
GTK is an object oriented system, but I didn't see a tree showing the
structure of the hierarchy of classes. I looked at GTK-- for this sort
of info but didn't find any. Right now I don't know which class is
ancestor to which class. Will I have to take a closer look into each
header, or did I miss something? Maybe in gtk.defs as well?
Thanks in advance.
-Daniel