Re: Exporting the Gtk+ object system to interpreters [was:no_marshall signals and GtkTypeInfo]

[Tim Janik <timj gtk org>]

On Fri, 11 Dec 1998, Kenneth Albanowski wrote:

> On 10 Dec 1998, Marius Vollmer wrote:
> 
> > Kenneth Albanowski <kjahds@kjahds.com> writes:
> > 
> > > 	No way of getting the object and class sizes of a type at
> > > run-time, without compiling a of sizeof() invocations.
> > 
> > Should be solved with gtk_type_get_info, right? [Or with this silly,
> > new fangled memory leak called gtk_type_query once it has its bugs
> > fixed.]
> 
> Yup, anything like that should be fine. Um, that does remind me about one
> other point: it's not clear what stuff is "ready" when the class-init
> function is being called. Can gtk_type_get_info be invoked for a type from
> within that type's class-init function, for example? (This is another
> general issue with interpreter bindings: the class-init function may be a
> bit weird, compared to how it normally works in Gtk+.) 

hm, gtk_type_query() can be invoked at any time, if the corrsponding
_get_type() function has already been called, it'll return the data
you were asking for. thus anything like
gtk_type_query(gtk_window_get_type()) will always do what you want
(assuming the type system is initialized with either gtk_type_init() or
gtk_init()).
i'm not sure what else you are asking for, once a type's class_init
function is called, all the classes that it derives from are
already properly initialized, while it's children classes are definitely
not.
this is different from the discrete type intializations though, since
class initializations are defered from type announcements and are performed
on demand.
so with GtkWidget inheriting from GtkObject, and GtkContainer inheriting
from GtkWidget, you can do gtk_type_class (GTK_TYPE_OBJECT) from
within gtk_widget_class_init and gtk_container_class_init, but
gtk_type_class (GTK_TYPE_CONTAINER) is a nono from within gtk_widget_class_init
or gtk_object_class_init, because the base classes need to be initzialized
first. gtk_type_query() or gtk_type_parent() will work for any type at any
time though, except from within _get_type() functions of parent types, but
you shouldn't do something else than announcing a type from within such
functions anyways.

> > In general, I'm not too sure how useful this exprting really is.
> > Compared to what the usual dynamic language has, the signal argument
> > stuff is quite limited (for good reasons).  Using it for full-blown OO
> > programming in Scheme, for example, just doesn't work.
> > 
> > What do you use it for in Perl/Gtk?
> 
> Arguments to signals? So far, I'm just worried about the signals that
> C/Gtk provides, and my concern is that currently Perl/Gtk needs special,
> and expensive, code to handle many signals (not to mention some extremely
> complex and massive compile-time generated code to handle object and
> signals arguments, which I'd like to trim.) I won't consider Gtk (C &
> Perl) complete until I can successfully "plug in" to a new object without
> writing a ton of code. 

with the object argument system, and the global marshalling facilities
of signal system, i don't see what's stopping you from handling
signals and properties in a generic fashion, maybe you could extend on that?

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

---
ciaoTJ