some comments from the pov of a language binding author

[James Henstridge <james daa com au>]

As some of you may know, I am the author of the python bindings for
gtk.  I have been working on bindings for the HEAD branch of gtk/glib
for a while, and have a snapshot that is almost useable:
  http://www.gnome.org/~james/pygtk2-SNAP-20001102

This may not compile or work correctly on your system, due to some
weirdness in my system.

I have a few comments from my work on these bindings:

* GSignal/GClosure is a lot nicer to use than the previous gtksignal
  code from a language binding.  It would be nice to add GClosure
  versions to some of the other parts of gtk that require callbacks.

  The ability to specify a class closure when adding new signals with
  g_signal_newv is good for language bindings.  But it would also be
  nice if we could specify a class closure for an existing signal if
  we derive a GObject from the language binding (this issue was brought
  up by Lupus).

* It would be nice if most of the remaining GTK_TYPE_POINTER arguments
  to signals could be changed.  To understand why this is important,
  you need to understand how signal handlers are called in language
  bindings.  We get the list of arguments for the handler as a GValue
  vector in our marshal function.  We then need to select the
  appropriate wrapper object for that argument.  We do this by
  checking the GType for that value.  If the GType is POINTER, then we
  don't know what to do with that argument (in python, I return a
  cobject object, which is opaque and useless to the person using
  pygtk).  It would be great if these signal arguments could be
  defined as new boxed types (I don't mean changing to GTK_TYPE_BOXED
  -- I mean deriving a new boxed type and using that typecode).

* Recently Tim switched the GtkCTreeNode arguments to the GtkCTree to
  GTK_TYPE_POINTER, which has suddenly made the widget almost useless
  to language bindings.  I understand the reason he made this change
  is because it doesn't make sense to copy/free or ref/unref this
  type, like you can with all the other boxed types.  Unfortunately,
  we can no longer recognise GtkCTreeNode arguments to signals.  If we
  aren't going to define types like this as boxed, would it be
  possible to derive new types from POINTER instead of BOXED for these
  cases?  For a language binding, having a unique GType code is the
  most important thing.

* The new text widget looks very nice, and since Havoc made the
  changes to the signal arguments, it is very easy to use from
  language bindings.  I haven't looked at the wrapping the code for
  inserting pixbufs or widgets yet though.

* The existing models provided for the new tree widget are probably
  not that easy to wrap for a language binding.  From talking with
  Owen, it sounds like the best way to go about this is to derive a
  new GtkTreeModel for use in python (which will probably be more
  useful), so this may not matter.

I will send more comments when I think of them.

James.