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

[Kenneth Albanowski <kjahds kjahds com>]

On Sun, 13 Dec 1998, Tim Janik wrote:

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

Yes, I think this covers what I was thinking of. The point is that, unlike
the C class-init functions, the interpreter variety may need to "figure
out what's going on", if you will, which might involve querying the type
system. Given what you describe, and what I'm familiar with, I can't think
of any easy way for it to break. 

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

The primary limitation is signal arguments that are passed by reference.
My Perl/Gtk binding is intended to be completely typesafe, which means the
pass-by-reference arguments, which are currently described only as
"pointers", cannot be represented. So I need code to manually remarshall
the signal arguments for any signal that has POINTER arguments. Currently 
this looks something like this:

	static int fixup_clist_u(SV ** * _sp, int match, GtkObject * object, char
	* signame, int nparams, GtkArg * args, GtkType return_type)
	{
        XPUSHs(sv_2mortal(newSViv(GTK_VALUE_INT(args[0]))));
        XPUSHs(sv_2mortal(newSViv(GTK_VALUE_INT(args[1]))));
        XPUSHs(sv_2mortal(newSVGdkEvent(GTK_VALUE_POINTER(args[2]))));

        return 1;
	}

	init()
         {
               static char * names[] = {"select-row",
			"unselect-row", 0};
               AddSignalHelperParts(gtk_clist_get_type(), names,
		fixup_clist_u, 0);
	}
  
The SignalHelper stuff is a lot of hidden (and expensive) logic in my
signal marshaller that knows to invoke the appropriate fixup routine if a
signal of a given name is invoked on an object descended from the given
type.

Marius has put a bit of thought into fixing this, but nobody has done the
work. Basically, the argument type system needs to be modified to
understand actual reference types, and record whether they are being used
to pass data IN or OUT of the signal handler, or both. Once this is in
place, my default marshaller can do everything, in a type safe manner. 
(I'm not _happy_ with OUT arguments, mind you, but it can still deal with
them automatically, one way or another.) 

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