Re: [gtk-list] Gtk and the scripting languages of the world

[Kenneth Albanowski <kjahds kjahds kjahds com>]

On 22 Aug 1997, Marius Vollmer wrote:

> Then, some objects are passed by reference for efficiency reasons (the
> transparent GdkColor) and some are passed by reference to hold
> additional return values (the mask).  These conventions are not
> enforced thru the type system and are therefore difficult to extract
> for automatic stub generation.

This is a severe issue, along with the more subtle one of objects that are
always described as pointer (like GdkWindow* and GtkObject*). Some of
these objects are pointers to objects that are stored elsewhere (like
GdkColor's, for example), and some of them are merely big clumsy
structures (like GdkEvent, I believe) that are always copied, or at least
you don't need to worry about retaining the original pointer.

There really needs to be some way to distinuish these types easily (a note
in the documentation or headers would suffice) and, ideally, provide
reference counting for all of the former objects, so that any environment
could safely retain a reference to them. (This wouldn't be very easy for
GdkColor*'s, though.)

The difference in these from inside the Perl module is pretty obvious:
the latter sort of object are copied whole into equivalent Perl
structures. A GdkEvent, for example, becomes a hash with keys for all the
various items that are used.

The other type of is retained only as a wrapped pointer, and all Perl
access dereferences the pointer to get to the original C structure. It
would be helpful if Perl could increment the object's refcount when it
wraps the pointer, and decrement it when it frees the wrapper, but this
isn't feasible at the moment.

> Gtk should also acquire a dynamic type system.  Most of it is already
> there, in the form of GtkObjects and GTK_ARG_INT, etc. 

But GTK_ARG_INT isn't sufficient if the INT is really an ENUM.

> There will also be some form of automatic memory management that Gtk
> has to respect.  This mostly effects how Gtk treats values from the
> interpreter that it stores away (like callbacks, or arbitrary user
> data) but also for Gtk objects in interpreter land.  Gtk already has a
> reference counting mechanism.  Although reference counting has its
> problems, I think we can make it work with some care.  (We only allow
> cycles for objects that are forcefully destroyed by the user, like
> widgets.)

Callbacks are pretty simple (the userdata gpointer is almost always
sufficient, though I think idle and timeout are missing deletion
callbacks.) But a real problem is the raw pointers used for user_data.
Without a length, these pointers are essentially useles. My Perl module
can successfully store user data in a Gtk object by storing a second
argument describing the Perl type of the data, but access to foreign data
is impossible, unless you want to guess it is a ASCIIZ string.

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