After a new segmentation node was been created, it is added to the data manager. This event itself will call RequestUpdateAll multiple times. However, the view will not be reset with the mentioned new value NO_UPDATE - that means, requesting a render update does not change the view / crosshair / camera orientation etc. The view is only updated / reset when InitializeViews or InitializeViewsByBoundingObjects is called (which in turn calls InternalViewInitialization and updates the slice navigation controller).

A first idea was mentioned here:

In T27613#225754, @kalali wrote:

Just for testing purposes: I created an additional Enum value to mitk::RenderingManager::RequestType, called NO_UPDATE. [...]

This allows to disable resetting the view / crosshair etc. after a new segmentation has been created.

The QmitkNewSegmentationDialog, which is used for the "New-button" does not contain any logic for resetting the render windows.
It can be used to simply create a new segmentation, e.g. when using the QmitkCreateMultiLabelSegmentationAction from the data manager context menu - here this dialog is used but no re-initialization / view resetting is done.

We should look into this and focus on the mentioned related task by @kislinsk to start with separating the two processes:

1. matching the geometry of the images for interaction
2. resetting the view of render windows to see the new segmentation

Will be done together with T28275: [Segmentation] AdaptiveRegionGrowingTool must be refactored / 4D Segmentation returns error message when point is not on the correct timestep.

Unassign myself because we removed the clipping plane from the release and have not discussed yet how to further proceed.

@kalali That is a good idea and proposal for how to proceed.

Currently not actively working on this. Packaging seems to work for the moment except for Python (never did). I think this task will soon be revived with the work on Python in MITK by Kim-Celine and Ashis.

Can D447 landed and this issue closed? If nothing speaks against it, it would be good, before I turning the rest of the seg tools upside down. Thanks.

@kompan What is the status here? Is it finish. If not, what has to be done to close it. Should be done before we make a release in january and if much is left, we should know what to do. Thanks.

Deleted branch bugfix/T28081-ShortcutsInWindowsInstallers.

Pushed new branch bugfix/T28081-ShortcutsInWindowsInstallers.

Deleted branch bugfix/T28080-RedistPackagingAndNSISGenerator.

Pushed new branch bugfix/T28080-RedistPackagingAndNSISGenerator.

I would see it positiv. No sense crying over spilt milk. Thanks for solving that problem!

Mixed feelings here: On one hand I'm happy that we, with a single trivial line of CMake code, finally fixed a decade old severe issue we had in MITK without really noticing it causing quite some inconvenience for our users and we were not able to reproduce it over the years. Maybe we even lost some users right before they actually used MITK because "it cannot open my DICOM files". On the other hand, we fixed a decade old severe issue with a single line of CMake code.