T26609-2018.04.beta.CT-Registration-Demo is based on a old 2018.04.beta version, CT registration is working.

Pushed new branch T26609-2018.04.beta.CT-Registration-Demo.

T26609-2019-08-USNavigationFix is based on 2019-05 MITK master, US Navigation is working, but CT registration is buggy.

Pushed new branch T26609-2019-08-USNavigationFix.

Level window widget has been added to both multi widget editors, presets work.
Using the context-menu of the level window slider the user can select the node he or she wants to modify. Using the multi-node selection approach from T25804 requires the selected-property to be set by the render window manager.
However, the multi-node-selection approach is included as the data manager is currently always available.

Pushed new branch T26495-Enable-level-window-slider-and-presets.

I came across this as I re-added the level window slider to the MxNMultiWidget (we didn't include this before as we used the PACS mode inside the MxNMultiWidget - which allows to change the level window via mouse moving). Now our user wants to use the level-window-presets available from the context menu of the level window slider.

In T25804#185436, @kalali wrote:

This would be necessary if we want to use the render window manager with the mxnmultiwidget and the mentioned task (T25483).

This would be necessary if we want to use the render window manager with the mxnmultiwidget and the mentioned task (T25483).

For test purposes this has been solved for the segmentation module / plugin in 450d57dd of T24215.

Also when changing the interaction mode (PACS <-> MITK) while the segmentation tool (e.g. Add) is active, the changed interaction mode will overwrite the segmentation interaction and the render window changes again while drawing the segmentation.

There seems to be a problem with the mitkDisplayActionEventBroadcast-class in general. Some classes have legacy code that disables the default display interactor to load a scenario-specific state machine and config file (see e.g. https://phabricator.mitk.org/source/mitk/browse/master/Modules/Segmentation/Interactions/mitkTool.cpp$121).
This is done in other classes. The problem is that the function does not reset the display action event broadcast instance but only display interactor instances.

The modified render window has been added and can be used by the StdMultiWidget and the MxNMulwiWidget (see T24215).
This is used here and a new entry for the render window menu has been added.

Pushed new branch T25605-View-direction-change-in-render-window-menu.

Missed it. "improve python 3 integration", "migrate to improved python 3 integration". Potato, Potahto

@neher What's wrong with T26566: Migrate to improved Python 3 integration?

Pushed new branch T26559-Python3.

It's MITK_USE_Python3 now instead of MITK_USE_Python. On macOS CMAKE_FRAMEWORK_PATH can be used to hint our CMake script to find a specific version of Python as Python 3.7 does not work at the moment.

Pushed new branch T26588-GetData.

Pushed new branch T25595-New-render-window-access.

LayoutManager has been added in T24215.

Render window menu is now available (T24215).
However, QSplitter were added to the MxNMultiWidget so that resizing via mouse-dragging is also possible.

Pushed new branch T24215-Remove-stdmultiwidget-dependency.

Functions have been removed in T24215.
Additional functions to be removed: see T26542

@neher Relevant changes are in rMITKDIFFb55a6f64c48e: Rename MITK_USE_Python to MITK_USE_Python3. The other commit is just some rectified formatting of CMake script. Please merge into master.

Pushed new branch T26566-MigrateToImprovedPython3Integration.

Pushed new branch T26561-FixPhantomConfigurationCancelation.

Pushed new branch T26562-FixTyposInIGTUSTrackingNavigationCalibrationView.

Pushed new branch T26546-FixCppRestSDKAndBoostIncompatibility.

Pushed new branch T26559-ImprovePython3Integration.

Prepared fix for CTK: https://github.com/commontk/CTK/compare/master...kislinsk:fix-pythonlibs-handling

Yes, I know, cancelled working on it on Friday as it was pretty late. It is addressed/will be fixed in T26559: Improve Python 3 integration.

Unfortunately, now numpy is not found anymore on Windows and Ubuntu. See nightlies.

Just a comment. Python wrapping is handled independently. We should talk to Michel about this.

Bug(s) in CTK:

If you ask for all the nodes from data storage then you get also child nodes in random order. In the previous implementation, visibility of all child nodes of widgets are set to True when the widgets node is reached. Nonetheless, child nodes visibility were afterwards set to False in the outer loop.
Now the loop is only done on nodes in the first level that contain data, therefore crosshair nodes stay always visible.

Could you elaborate on this? I don't get it: aren't we processing each single data node inside the data storage?

In Ubuntu 18.04 data storage is accessed in random order therefore the visibility of crosshair was set randomly. Fixed in branch: T19683-ShowOnlySelectedNodesCrosshairVisibility-RandomAccess.

Pushed new branch T19683-ShowOnlySelectedNodesCrosshairVisibility-RandomAccess.