Re: [gtk-list] Re: GTK modula-3 bindings



Daniel Solaz wrote:
> 
> 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.

In other words, proxy objects. Sounds ok, but naturally you have to
manage the interaction between Modula-3's GC and the gtk+ reference
counting scheme. BTW is the Modula-3 GC conservative, or does it use
tagged types, or none of the above?

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

Can't see why not.

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

Yep, this is in gtk.defs too. You can also query this sort of stuff at
runtime too, for what its worth. The gtk+ doco describes the functions
required to do this.

Regards
M.Beach



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]