The mitk::SlicesRotator works fine with the QmitkStdMultiWidget setup, which is three 2D views and one 3D view. As soon as somebody uses the class in order to coordinate four 2D views (axial, sagittal, frontal, axial clone of the first view) it will fail. Nothing will be done in reaction to mouse input because there are some hard-coded expectations about exactly two orthogonal planes being visible. These expectations will fail whenever there is a fourth render window.
To fix this, I basically reviewed and refactored the whole class:
- the long switch/case block in ExecuteAction was distributed into methods
- some 20 lines which would be used to determine a value that is used in an if-clause and would always(!) evaluate to true was removed
- the whole "check whether we want to rotate slices or move the crosshair" logic was re-thought, documented first, then implemented as intended
The modified class works fine in a setting like described above.
To make review of this bug easier, I'll attach a patch to tutorial step 8 which will modify the tutorial application in a way that it has two axial views.
Since this is a rather big change to an important class, I'd like if a second person would review and test the code before we integrate it. Basti, since you worked much with geometries, could you perhaps look into this? Otherwise this would be a nice bugsquashing-review.