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

[Kenneth Albanowski <kjahds kjahds com>]

On 7 Dec 1998, Marius Vollmer wrote:

> One of the problems are the class functions, I think.  With "class
> function" I'm referring to the functions that are directly pointed to
> from the class structures of a type, like gtk_button_draw.  I want to
> be able to use interpreted functions for these class functions, altho
> I'm not sure if I need them.  Therefore, I want to add this function
> to Gtk+:
> 
>   void gtk_signal_set_class_function_full (GtkType            type,
> 	    				   const gchar       *signal,
> 		    			   GtkSignalFunc      func,
> 					   GtkCallbackMarshal marshal,
> 					   gpointer           data,
> 					   GtkDestroyNotify   destroy_func);

Yes, I've run into the same problem with Gtk/Perl, of course. This (or
rather the underlying mechanism) would be appreciated. (Note that there is
currently no way to fake it, as "class functions" don't have any sort of
"data".)

> Additionally, to derive at runtime from arbitrary types requires
> knowledge about the sizes of their objects and their class struct.

Yes, it'd be nice to have a way of retrieving this information at
run-time. Currently the Perl code has a rather silly bunch of functions
that provide this information the hard way.


> > regarding your signal changes, please take into account that there
> > may exists third party code that will eventuall want to conect to
> > any signal of an object. so marshallers are a must to be provided.
> 
> A default marshaller is a must for signals that want to allow
> connections from handlers that are written in C in the usual fashion.
> I see the creation of a signal without a default marshaller as a
> conscious act of saying: "Look, as much as I like to, I just *can't*
> give you a default marshaller.  I know that C handlers with a static
> interface can't connect to this signal, but I'm willing to live with
> that."  From my point of view, this is a reasonable compromise because
> C handlers with a static interface that want to connect to dynamically
> (at run-time) defined signals can be avoided without loosing
> functionality (but convenience).

This of course hits Gtk/Perl as hard as it hits anything else. The basic
problem is that C has no ability to construct functions at run-time. (I
believe there is one or two libraries out there that attempt to solve
this, but they are by definition not portable. Some day this will be worth
considering, but not just yet.) This is fundamental to creating signals
from within a portable interpreted language.

I quite like the idea of making Gtk fully understand that a signal can be
missing the C marshaller, and thus cannot be invoked directly from
compiled C code. 

(Some method of providing a marshaller at a later time might make sense. 
If compiled C code is added to the running code, it is logical that a
marshaller could be constructed and added at that time. Bear in mind that
it seems likely to be extremely rare that _new_ compiled C code will be
invoking signals in widgets created at run-time by interpreted code.) 

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