Re: Exporting the Gtk+ object system to interpreters [was: no_marshall signals and GtkTypeInfo]
- From: Marius Vollmer <mvo zagadka ping de>
- To: gtk-devel-list redhat com
- Subject: Re: Exporting the Gtk+ object system to interpreters [was: no_marshall signals and GtkTypeInfo]
- Date: 10 Dec 1998 21:23:55 +0100
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.]
> 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.
> 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.
> 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.
> 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.
> and the lack of a "data" parameter for class signals.
Should be covered by gtk_signal_set_class_function, right?
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?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]