Re: custom vfunc problem

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.


Den 2016-03-21 kl. 03:30, skrev Ian Martin:
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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]