There is at least few places in underlying C libraries where behavior is dependent on vfunc definition. E.g. in GstBaseTransform class, if transform or transform_ip vfunc is not defined, then plugin is set to passthrough mode. In C++ wrapper, you need to manually set this flags. Unfortunately, I didn't come up with any good idea.
2016-03-21 10:13 GMT+01:00 Kjell Ahlstedt <kjell.ahlst...@bredband.net>: > 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 > -- Pozdrawiam Marcin Kolny
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
