Re: custom vfunc problem

[Ian Martin <martin_id vodafone co nz>]

Hi,
Thanks.

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;
>     }
> else
>     {
>       /* 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.

Ian




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.
>
> 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.