Interpreter requests

[Kenneth Albanowski <kjahds kjahds com>]

Since the development series of Gtk is getting some work, now, I'd like to
make some requests (I must apologize for not doing the work myself) to
facilitate interpreter bindings:

 1. _Everything_ must have a type, and a destruction callback! Any place
raw pointers are used limits the capabilities of a interpreter binding, or
at least an interpreter binding that doesn't expose pointers.  Since we
now have a type mechanism, use it! This means signal arguments, as well as
object data (get_data/set_data). The GTK_POINTER_TYPE is effectively
useless (from my point of view), and probably is simplest replaced with a
set of types for each structure, and a new type for each primitive that
can be passed by pointer. 

  I'm not yet decided whether some sort of ownership flag would make
sense, or perhaps READ/WRITE flags. One of these is needed to let
interpreter bindings know whether values passed by pointer are intended
for passing data in or out of the signal function.

 2. Make all usage of GtkArg's similar: currently the return value of a
signal routine is implicitly a pointer, thus needing two sets of routines
to pack/unpack GtkArgs. In an interpreter binding, this is a large amount
of code, as these are workhorse routines. This is better replaced with a
standardized mechanism for saying that the return arg is a "WRITE-ONLY
POINTER TO INT", or somesuch, so the pack/unpack routines can be
universal. 

 3. Some simple mechanism of looking up the names of object variables. 
Currently the procedure needed to see whether "X" is a variable of class
"Y" is quite tedious, involving pasting together "Y::X", seeing if it is
legal, if not, try "Y-Ancestor::X", and then "Y::signal::X",
"Y-Ancestor::signal::X", etc. A function to automate this lookup (and
return type information at the same time) would be very helpful. 

 4. Add a bit more .defs information describing whether the contents of a
structure are important, the pointer to a structure, or both. (Or firmly
define boxed & struct in these terms). Consider that only the contents of
a GdkEvent matter, while the location of a GdkColormap is important,
despite not being reference counted. (I still don't know what to do with
colormaps, btw. :-)

 5. Add information (somewhere, perhaps the .defs files) indicating which
function arguments can be NULL. It's especially important to know which
widget pointers can legitimately be null.

That's just off the top of my head, I'm sure I'll come up with some more
stuff.

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