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
