Re: custom vfunc problem


Sorry Kjell, I clipped the init function. All of the non-deprecated methods and signals are pointed to the _real_ version of the vfunc or signal in clutter_actor_class_init(), and I'm wondering if using that to ensure the object is not a derived class is preventing cluttermm from calling the appropriate vfuncs. Stepping through the code the _real_functions are being skipped from C++ code, but being called when the identical C code is run.

Running a program with a debug flag( --clutter-debug=layout) I'm seeing lines like the following:
Clutter-Message: [ +58820]:[LAYOUT]:clutter-actor.c:2342: Querying the layout manager 'gtkmm__ClutterBoxLayout'[0x2922670] for the preferred height
where the C code gives
Clutter-Message: [ +85160]:[LAYOUT]:clutter-actor.c:2342: Querying the layout manager 'ClutterBoxLayout'[0xb1ea10] for the preferred height

which looks to me like the C++ object used is a derived class given the gtkmm_ prefix; that would explain why it wouldn't call the base methods if a check for a _real_ vfunc is present, and that would explain what I'm seeing happen. I can't see anywhere in the gtkmm code where the same problem occurs; lots of gtk+ classes - GtkButton for one - have a series of _real_ signals, but I don't see anywhere the same use of the _real_ function as a way of blocking derived classes from using C code. clutter_actor_allocate_vfunc I got around by making sure a flag was set; now I'm stuck trying to get around clutter_get_paint_volume, and there's no flags to use to get around it- this piece of code in clutter_actor_real_get_paint_volume ensures any derived class returns false, and therefore any update won't happen.
  if (klass->paint == clutter_actor_real_paint &&
      klass->get_paint_volume == clutter_actor_real_get_paint_volume)
      res = TRUE;
      /* this is the default return value: we cannot know if a class
       * is going to paint outside its allocation, so we take the
       * conservative approach.
      res = FALSE;

I can't point the C++ vfuncs to the _real_ vfuncs (as is done in clutter_actor_class_init) because they're declared in the .c files, not the public header.


On 21/03/16 22:13, Kjell Ahlstedt wrote:
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]