I pushed my local branch to remote for others to continue working on it. The related differential {D705} has been updated and will remain open.

Pushed new branch to rMITK MITK: feature/T29273-Decouple-TimeNavigationController-from-SliceNavigationController.

The Diff should be landed after the 2023 spring release. We decided to go that way, as it is not necessary for the release and we are already shaking up a lot of things.

I pushed my local branch to remote for others to continue working on it. The related differential {D594} has been updated and will remain open.

In general this might be a problem also for other views because closing the workbench removes the render window part listener: m_RenderWindowListeners.remove(renderWindowListener) in QmitkViewCoordinator::PartClosed. This leads to the issue that the Segmentation view does not listen to the render window part being closed anymore.
Thus in the current scenario the render window part is NOT set to nullptr in the Segmentation view and in turn an invalid access is made when destroying the Segmentation view.

@a178n will close this task and create a new dedicated task.

It was discussed that the old reader information is not of any value and shouldn't be written into the files.

if I not mistaken this is something different, because scene serialization uses as different mechanism (it always stores all props of data and nodes; no matter what). Property persistence service is only relevant for reading or writing data to "directly" to files.

Wait, maybe we are talking about the same thing. In mitkSegmentationTaskListIO.cpp:181-184 the written properties are used in case everything is read from a scene file. Then, the original input location is read as search path for relative data that isn't contained within the scene file. Which I know is not a perfect situation in the first place but better than nothing in particular for users using the save button to checkpoint their progress.

You're right. I already suspected it to be different things but better safe than sorry. :D

In T29521#246322, @kislinsk wrote:

Input location is used by the SegmentationTaskList and SegmentationTaskListIO.

Input location is used by the SegmentationTaskList and SegmentationTaskListIO.

Please see the build instructions. Long story short: MITK uses a superbuild, meaning it has two build levels. What you see is the outer level, called superbuild. The superbuild downloads, configures, and builds all required third-party libraries (except Qt) automatically. One of the projects of the superbuild is the MITK build itself, the inner level. As soon as the MITK-Configure project was successfully built on superbuild level, you find a populated MITK-build folder in your superbuild folder. From then on you can set it as build directory in CMake to change the configuration of MITK itself, for example, enable plugins and so on...

Not necessary for the upcoming release but we should look into it nevertheless and take care of it.

This context and code artifacts referred in this issue seems obsolete or changes. The issue needs to be rephrased if not closed.

Pushed new branch to rMITK MITK: feature/T29497-totalseg-subtasks-support.

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 task may be deemed fully discussed. Hence, will be marked as resolved.
Another task, T29497, is created for tracking the full subtask support in the future.

A pop up appears with whatever error message was thrown from OtsuTool3D::DoUpdatePreview.

I uploaded a fix in D783. Let's see if this will solve the issue also for Ubuntu.

Deleted branch from rMITK MITK: bugfix/T25316-EnableThemedIconsInEagerPlugins.

I tested this on Windows with 4974a335ada8a85d7fba8d313e2efc20acc84b48, which was the latest develop I had, since I recently merged something into develop and couldn't reproduce the error.
Used StdMultiWidget, no other plugins open, no data loaded, only the widget planes available in the data storage.
I tested this with the commit given in the task description and couldn't reproduce the error there as well.

Pushed new branch to rMITK MITK: bugfix/T25316-EnableThemedIconsInEagerPlugins.

In T29432#244945, @kislinsk wrote:

While the original issue is rather easy to resolve by exchanging the class to data->Modified() with a RequestRenderWindowAll() (which is the actual intent anyway according to the comments), more hurdles start to appear that are not as easy to resolve.

The data loading that is now happening immediately, is happening even before the rendering manager has any registered render windows. Any geometry validation of the data against render window geometries is a no-op, and it is kind of okay as it just works. However, when now adding another label in the GUI for example, the Segmentation View again does its data validation and now there ARE render windows with geometries and these do not match the segmentation geometry, resulting in the Segmentation View complaining about a necessary reinit (that is not necessary, yet is technically correct). There are many strategies to resolve this issue, none of them seem easy. The most straight-forward concept at least would be to defer loading of any data until the application is done with initializing its plugins and editors. That would probably require some kind of "ready" event triggered which could be used to load data specificied on the command-line.

Deleted branch from rMITK MITK: feature/T29432-PreloadFirstTask2.

After meeting it is decided that:

1. Label names/classes & their pixel values that are hardcoded in the python codebase will be parsed directly and shown in MITK for 2023.04 release (Ref: https://github.com/wasserth/TotalSegmentator/blob/master/totalsegmentator/map_to_binary.py)
2. Certain subtasks which need multiple nifti file agglomeration (eg. "Body") will not be included in the 2023.04 release.

Deleted branch from rMITK MITK: release/T29488-2023-Week-11.

Pushed new branch to rMITK MITK: release/T29488-2023-Week-11.

Deleted branch from rMITK MITK: bugfix/T29481-FixOddIncludeGuard.

Pushed new branch to rMITK MITK: bugfix/T29481-FixOddIncludeGuard.

I noticed that it only happens in v2022.10 but not in the latest develop so chances are high that it is already fixed but it should be double-checked with the upcoming snapshot installer.

Deleted branch from rMITK MITK: bugfix/T29481-FixAndUnifyIncludeGuards.

Pushed new branch to rMITK MITK: bugfix/T29481-FixAndUnifyIncludeGuards.

Deleted branch from rMITK MITK: bugfix/T29480-RemoveUnusedFiles.

Pushed new branch to rMITK MITK: bugfix/T29480-RemoveUnusedFiles.

Pushed new branch to rMITK MITK: feature/T28578-Test-MxN-installer.

Pushed new branch to rMITK MITK: feature/T29468-totalsegmentator-install.

Deleted branch from rMITK MITK: feature/T29468-total-segmentator-install.

Pushed new branch to rMITK MITK: feature/T29468-total-segmentator-install.

From a first glimpse it really needs to be continued before merging. Can't make much sense right now out of mitk::StoreSCPLauncherBuilder in parallel to QmitkStoreSCPLauncher::Params. Have to take a closer look.

Should we integrate that in develop? Or any reason to wait?

Deleted branch from rMITK MITK: bugfix/T29471-UpdateAboutDialog.

Pushed new branch to rMITK MITK: bugfix/T29471-UpdateAboutDialog.