GNOME Bugzilla – Bug 763073
Clutter::Actor: cannot wrap allocate, pick, or get_paint_volume vfuncs
Last modified: 2021-07-05 12:20:32 UTC
Created attachment 323046 [details] A minimum C file that shows the problem. The Actor class has taken over Container functions. However, Actor::allocate fails to allocate any space to child actors. The comment on clutter_actor_maybe_allocate_children suggests that the problem may be that allocation is only done if the class is not derived. As all C++ classes are derived, they return from this function before allocating their children any space.
Created attachment 323047 [details] this is the same set of commands as the C++ file, only in C. The file builds an actor with one child. If the actor is created via clutter_actor_new, the child is drawn; if created via Clutter::Actor::create(), it isn't. Comparing this file with the previous one, if run with --clutter-debug=actor,layout,paint shows that the child actor is not being allocated any space.
Created attachment 323048 [details] [review] patches the allocate vfunc. This works ( but feels like an ugly hack ). The initial gmmproc check is reduced to if(obj), because non-derived actors may have children; then if Actor::get_n_children != 0 a DELEGATE_LAYOUT flag is set on the actor. This then forces the children to get allocated space.
Do we need to override the vfunc much? For now, could we just comment out the vfunc in cluttermm?
Yes, that'd make more sense. I think the only impact is on custom actors with a non-rectangular allocation.
Could you try that, please, and maybe attach the patch?
I've parked this problem. This works for allocate, but pick() also suffers from a functionally identical problem, which means children of an actor created in gtkmm fail to receive any event signals. Looking at https://wiki.gnome.org/Projects/GTK%2B/Roadmap, GSK is due to be merged in 3.22; I believe this is the new improved Clutter. Due to the way Clutter has hardcoded inability to inherit from the C classes and the time frame for GSK, I don't see much point trying to get Cluttermm functional any more.
I think it is unwise and overly optimistic to wait for GSK in GTK+ rather than just commenting out a couple of lines of code. Hopefully you don't need cluttermm or GSK for anything urgent. I have commented out the problematic Actor vfuncs here: https://git.gnome.org/browse/cluttermm/commit/?h=cluttermm-1-24&id=4040eb5a6fd26f51e12eb5c898d7ff46014da364 For anyone reading this in future: The problem in general is that the C code compares function pointers to discover whether the vfunc has been overridden, and that comparison doesn't make sense if there is a level of indirection, such as that used by gtkmm: https://mail.gnome.org/archives/gtkmm-list/2016-March/msg00029.html As Kjell says, the developers seem to know that this is unwise: https://git.gnome.org/browse/clutter/tree/clutter/clutter-actor.c?h=clutter-1.24#n6134 This seems to be the bad function pointer comparison for allocate: https://git.gnome.org/browse/clutter/tree/clutter/clutter-actor.c?h=clutter-1.24#n2564 And this seems to be the bad pointer function pointer comparison for pick: https://git.gnome.org/browse/clutter/tree/clutter/clutter-actor.c?h=clutter-1.24#n2242 I don't see more such comparisons, at least in clutter-actor.c. Let's leave this open, but retitled.
On the other hand, this does make it impossible to properly implement a custom actor or container, which is not such an unusual thing to want to do.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/cluttermm/-/issues/ Thank you for your understanding and your help.