wrong bbox of 3d box when in transformed group

Very similar to behavior seen on page resize at bug 187668 (maybe a dupe, in fact)...

Also, there is a simpler use case (you don't need two 3d boxes + text.)

1. draw a 3d box
2. draw any object (say an ellipse)
3. select and group these 2 (ctrl-A, ctrl-G)
4. drag, rotate, or flip the group...
strange behavior as described above.

confirmed here

Max: please try to fix this for 0.46, it's quite annoying :)

Phew, this was a tough one, but it's fixed now (please test!). I hope there is a chance to get this into 0.46.1. I'm going to add a patch in the correct format and the necessary information/explanations later today.

Okay, the patch is attached. Bryce, do you see any chance to get this into 0.46.1? (If it's released at all, that is).
Here is the information you requested on the wiki in connection with such patches.

* Bug: The bug is as described above: When 3D boxes are grouped with other objects and the group is transformed, the bounding boxes are wrong, and sometimes the boxes themselves are transformed in the wrong way. Also, selecting boxes inside groups shows the selection rubber band (or the knot handles if in 3D box context) in the wrong place. Even if 3D boxes were not available in earlier releases, I'd call this a regression (and a serious one, too).

* Fix: The patch appears quite long but doesn't really change a lot. It's mostly that a couple of functions involved in computing coordinates of 3D box corners needed to be slightly refactored and/or called at different places, whence the amount of altered code lines. The real cause of the problem was that perspectives were not updated correctly when groups containing 3D boxes were transformed. Since one perspective can have several boxes attached to it, it was necessary to ensure that a perspective is only transformed once even if a group contains several boxes with this perspective. Now we keep track of all boxes and perspectives in the current selection (recursing into groups if necessary) and update them correctly on each transformation. As I said, the rest of the code is refactoring of coordinate-computing functions to ensure that correct coordinates of corners/handles of grouped 3D boxes are returned when queried by the knotholders or the bbox functions. Thus I believe that despite the length of the patch the chances for introducing other errors or regressions are minimal.

Please tell me if I forget anything or you need further information.
Thanks!
Max

Sure, we can take a look at this for 0.46.1; given the length of the patch and that the issue is not seriously critical (i.e., does not cause data loss or a crash), I don't know if it is the most appropriate for a stable release. But when we get closer to 0.46.1 we can review the patch in depth. Meanwhile, please make sure this is applied to main, and update this bug report if there are any issues found there. Thanks!

@Maximilian - was the patch 'fix_for_wrong_3d_boxes_in_transformed_groups.patch ' ever committed to the trunk after the release of 0.46 or did you set the Status to 'Fix committed' because you attached it to the bug report?

The patch is quite old now, but parts of its code seem to be present in the current SVN (and some others have probably been reworked).
Anyway, I can't reproduce the bug on Ubuntu 9.04, inkscape revision 22548, and thus "fix committed" seems correct.