This task should be revised / kept in mind when reworking the interpolation in general

This task should be revised / checked if the problem still exists when the interpolation controller has been reworked.

I think this is caused because the interpolator gets notified of a new group being added as soon as that happens, but before a new label has been added to the group. When trying to update the interpolation, it tries to get the value of the active label inside QmitkSlicesInterpolator::OnInterpolationActivated(), which causes the error because there is no active label set.

I have added a fix for this in D810. It only includes a fix to OnAcceptInterpolationClicked and does not refactor AcceptAllInterpolations, which is still quite clunky. But this should at least solve the buggy behavior.

Since this is probably not going to be fixed until this release, I have added a safeguard in PlanarFigureMapper2D::MitkRender() that completely skips rendering of planar figures in all windows that don't belong to the StdMultiWidget, to avoid unexpected behavior and crashes.
When this task is tackled, that needs to be removed!

It was discussed and agreed upon, that it does not make sense to adapt this behavior in the Data Manager. If we want a clean implementation of the "set focus on planar figure"-feature, it should belong in the corresponding view (i.e. Measurement) instead of the Data Manager.
As this is not currently a specifically requested feature, this task will be closed.

In T29504#246386, @kalali wrote:

This is not solved with {D795}, right? I can still see slicer->GetRenderer() in line 926, so the render window is still retrieved from the slice navigation controller, which requires the getter to be available in the slice navigation controller.

After looking at the checklist again, I don't think there is a need to change anything. The checklist specifically only speaks of selecting the line-node once. When following the checklist instructions, everything should work as described.

This task is basically done with D778, which introduced a mechanism to save/load custom layouts, as well as select from provided presets. The only thing we could further add would be more presets, as there is only one at the moment (two rows with each view direction each).

This was briefly touched upon in the group meeting today. An idea that came up was to include a section in some checklists to gather feedback on existing and suggestions for new features / UX in general.

I don't think it is necessarily a bug, but rather unintuitive how it works. The recentering is not triggered by the clicking of a node, but via changes in the selection. One can also do things like select multiple lines (on different slices), then deselect one, and the view recenters to one of the still selected nodes.
For me, it would feel more intuitive if the view just recenters every time a node is clicked, regardless of the selection. But there is no bug apparent to me here.