Re: some comments from the pov of a language binding author

[Tim Janik <timj gtk org>]

On Fri, 3 Nov 2000, James Henstridge wrote:

> 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.

patches are greatly apprechiated ;)

>   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).

yeah, talked about this with owen.
i'm pondering something like:

 guint   g_signal_new                         (const gchar       *signal_name,
                                               GType              itype,
                                               GSignalFlags       signal_flags,
-                                              GClosure          *class_closure,
                                               GSignalAccumulator accumulator,
                                               GSignalCMarshaller c_marshaller,
                                               GType              return_type,
                                               guint              n_params,
                                               ...);
+void    g_signal_set_class_closure           (guint              signal_id,
+                                              GClosure          *class_closure);

and to chain up to the parent handler from such a closure:
+void    g_signal_chain_parent		      (guint              signal_id,
                                               GType              handling_type);

that would work like (language binding glue code, provided the below
objects were not implemented in C):

gtkbutton_destroy ()    { g_signal_chain_parent (destroy_id, GTK_TYPE_BUTTON); }
gtkcontainer_destroy () { g_signal_chain_parent (destroy_id, GTK_TYPE_CONTAINER); }
gtkwidget_destroy ()    { g_signal_chain_parent (destroy_id, GTK_TYPE_WIDGET); }

(if someone has a better naming for GType handling_type that make the type id
to be passed in clearer, speak up)

the thing is that this will only work for language bindings and up to
the upper most C method closure. within pure C implementations chaining
will still have to occour via normal function pointers, because the
wrapper closure that calls the C imlpementation functions via
class+class_offset doesn't have any knowledge of handling_type (and couldn't
have that knowledge without grossly hacking the GClosure API).
that's because for C, we don't purely go through closures for signals,
if we did, g_signal_chain_parent() would work, but people would have
to provide closures in their widget implementations, rather then:
  object_class->destroy = my_destroy;

> * 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).

patches are greatly apprechiated here as well.

> * 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.

yeah, it might also help the recent pass by value/reference thread,
i'll have to ponder it some more, but it doesn't sound too bad actually
(if you sent in a patch as a reminder, that'd probably push the issue).

> I will send more comments when I think of them.

more of this sort are also greatly apprechiated ;)

> 
> James.
> 

---
ciaoTJ