Re: [gtk-list] Re: GC and GTK+

[Kenneth Albanowski <kjahds kjahds com>]

On 22 Apr 1998, Vollmer Marius wrote:

> Yes, we could use the GTK_TYPE_FOREIGN for giving info to Gtk about
> foreign values.  The interpreter bindings would register a new type
> (or several) with a parent type of GTK_TYPE_FOREIGN.  Associated with
> this new type would be functions for destroying it, and what else is
> needed.
> 
>     GtkType gtk_type_new_foreign (char *name, GtkDestroyNotify, ...);
> 
> We can then replace the DestroyNotify parameter thru out by a GtkType.

Actually, I'd rather unify more: the existing pointer values passed by the
signal handlers cause great problems for my Perl code (as it needs to know
the exact type of each of those pointers). I'd change the GTK_TYPE_POINTER
GtkType to include a DestroyNotify callback, and then expand the GtkArg a
bit to include flags saying whether the type is read, write, or both
(i.e., in, out, or both) and who has ownership of the pointer (the caller
retains ownership, or transfers ownership to the called.)

"Foreign" types would be handled simply by creating a new descendant of
GTK_TYPE_POINTER, using the existing mechanisms.

Note that the signal handlers have to be overhauled, regardless. Currently
my code has to be hand tweaked for each handler with a GTK_TYPE_POINTER,
which is very limiting.

> Sigh, yet another variant on the _interp/_full theme.  I think we
> should start taking out the _interp functions when their functionality
> has been superceded by the _full variant.  We might introduce another
> _typed family (or _foreign?) and the get rid of _full.

Unify...

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