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

[Kenneth Albanowski <kjahds kjahds com>]

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

> > 	The requirement of needing to know the number of signals that will
> > be used, during construction. (This is certainly excusable, it's just
> > mildly painful when combined with everything else.)
> 
> What do you need that for?  I plan to add new signals to a class
> *without* having a class function pointer in the class struct.  You
> can do that already, just use a function_offset of 0.  The default
> handler would then be set via gtk_signal_set_class_function which can
> deal with function_offset being 0.

Yes, that is just fine.

> > 	Needing to construct the new object layout with class signals
> > manually, assuming that class signals are used. (I mean, using the class
> > size and arithmetic to lay out the subclass. This is perfectly workable
> > and reasonably portable, but feels messy.)
> 
> Manually laying out the object and class structures is acceptable, I
> think.  Given that one doesn't need class function pointers in the
> class struct, it shouldn't be too much of a hassle.

Agreed.

> > 	The names of primitive types (int, string, etc.) have danced
> > around a bit, making variables a little difficult to construct.
> 
> Are you referring to "arguments"?  I have not tried those.

Yes, arguments, I guess. Something like that. :-)

> > Disregarding these, the only real problems at the moment are insufficient
> > details in signal arguments (no type for pass-by-reference),
> 
> Yes, that's tough.  I have a scheme for this, which I posted some time
> ago, but I don't feel like implementing it right now.  I don't have
> the nerve to argue.

Likewise -- both. ;-)

> > and the lack of a "data" parameter for class signals.
> 
> Should be covered by gtk_signal_set_class_function, right?

Yup.

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

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