Re: language bindings & Gnome

[Jaka Mocnik <jaka mocnik kiss uni-lj si>]

Andreas Kostyrka wrote:

> 4.) Callbacks. Callbacks must always carry one freely setable pointer
>     argument. Callbacks should also have a DestroyNotify.
>     Rationale: In most language generating new C functions is either
>                impossible or too difficult. This means, that usually
>                language map all callbacks (at least of one kind) to a
>                given function, and this function uses the pointer argument
>                to know which binding in the host language is meant.
>                As this data areas for method binding are probably
>                dynamically allocated, a DestroyNotify is a "good
>                thing"(tm) to prevent memory leaks.
>     Bad example: GnomeMDIChild set_menu_template that uses
>                  gnomeapp_create_menus_with_data. This is basically
>                  nonwrappable.
As said in the previous post, I (hopefully) fixed this.

> 5.) Subclassing. At the moment I believe there is no language wrapping
>                  for subclassing a GtkObject class. This is by design
>                  difficult, as it involves structs that point to callbacks
>                  without the needed extra parameter and other niceties :(
>                  So don't force the user of your widget to subclass some
>                  object to use your code. You can make it easier by
>                  subclassing but always leave a possibility to do it
>                  without full blown subclassing. To explain what is
>                  probably managable from all languages:
>                  C: GnomeMDIChild            TOM: GnomeMDIChild
>                                                   \- MyChild
>                  So on the C side MyChild objects are represented by
>                  GnomeMDIChilds. Callbacks are handled in such an setup
>                  not by overwriting function pointers in the class struct
>                  (as in gnome-hello-7-mdi MyChild class), but by
>                  connecting signals to these slots.

An alternative to subclassing GnomeMDIChild would be to
gtk_object_set_data() your own data to instances of GnomeMDIChild
objects instead of subclassing the object. This would result in a bit
more code when creating new children (you'd have to create a
GnomeMDIChild, set its values (name), allocate the structure with your
data and then make a gtk_object_set_data() call so that this data could
be accessed via the GnomeMDIChild (in callbacks etc.). I haven't tried
it out, but I don't see no reason why it shouldn't work - it just seems
a bit awkward to me.

regards,
	jaKa

-- 
email: jaka.mocnik@kiss.uni-lj.si
w3:    http://www.kiss.uni-lj.si/~k4fe0026