Haven't you mixed up signals and vfuncs? show and hide are signals. show_all, hide_all, map and allocate are vfuncs.
I'm not sure if the test for clutter_actor_real_allocate in clutter_actor_maybe_layout_children() can be problematic. It shouldn't be, when the vfunc is called. If it's not overridden by the user of cluttermm, the parent class version (i.e. the C code version) will be called, and the C code should find that klass->allocate == clutter_actor_real_allocate. But I see in the clutter code that clutter_actor_maybe_layout_children() is also called from clutter_actor_set_allocation(). Perhaps that call does not work as expected unless the CLUTTER_DELEGATE_LAYOUT flag is set.
Kjell
Den 2016-03-21 kl. 03:30, skrev Ian Martin:
Hi,
I'm slowly working my way through clutter trying to wrap it. I've come up against a recurring problem where the C functions work but the wrapped functions don't; looking at the clutter source, I think the problem might be that the vfuncs are listed in the class_init function with a _real_ qualifier:
klass->show = clutter_actor_real_show;
klass->show_all = clutter_actor_show;
klass->hide = clutter_actor_real_hide;
klass->hide_all = clutter_actor_hide;
klass->map = clutter_actor_real_map;
etc, and then in the source files this sort of thing happens:
if (CLUTTER_ACTOR_GET_CLASS (self)->allocate == clutter_actor_real_allocate)
goto check_layout;
which would mean that if every C++ instance is derived, it won't call the base class function; if possible, I should be pointing the vfuncs to the _real_ method, but as they're not declared in the headers this won't work either.
Is that correct? Is there an example in another wrapped library of this being done successfully?
Ian.
_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkmm-list