Matthew Allum wrote: > Also its worth noting now in trunk clutter group size querying is fixed > to correctly take into account child transforms now.
The code is there (clutter_group_query_coords), but is not enabled. Also, the group only resizes itself right/down, so even if the code is enabled, the returned size is still not guaranteed to be the real size of the box, as it is possible to have an actor sticking out over the left/top edge of the group box. Making the group to expand in all directions comes with side effects, as the position and size of the group is then dependent on the state of its children, which complicates things if the children or the group are animated in any way. From my experiments I am inclined to think that it will be very difficult to devise a way to make a generic container that will just work in different scenarios. So, I am really wondering, especially since ClutterGroup is a very simple layout-less container, whether we should not stick to the original behaviour and leave it to higher level containers to implement behaviour specific to the intended use. We can add convenience API to ClutterGroup that will calculate the actual size of the box relative to the ClutterGroup top-left corner, but I would leave it to the sub classes to decide what should be done with that information. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
