However, the implementation showed that it could take quite a long to download, depending on the model size. Hence, this should happen in a different thread.

A new combo box and button were added in the "Advanced" section. This combo box listed all available models for download, reading the JSON file.
The download button goes ahead & downloads the model and keeps it in the results folder location, in a valid way. No extra effort is required from the user.

Thank you for the report. The Python plugin is labeled as experimental and is not used by us anymore since quite some time now. We don't recommend to use it anymore.

I tried clicking different buttons and crashes happen regularly.

Deleted branch from rMITK MITK: bugfix/T29195-FixFlowBenchArgParsingAndIconLoading.

In T25725#239078, @kalali wrote:

@floca Did you test the differential in the Workbench? Actually I was just implementing this feature witch was there for many years but never functioning. It was never of any use since we only had a single rendering display. What I realized, though: the use is barely existing, since you can only "send" a node to a render display / multi widget. But the StdMultiWidget displays the nodes anyway and the mxnMultiWidget should be controllered differently, right (since you only send the node to the whole multi widget, not to a single render window)?
So I can land the changes but I'm also fine with removing the feature entirely, eventually.

Pushed new branch to rMITK MITK: bugfix/T29195-FixFlowBenchArgParsingAndIconLoading.

Pushed new branch to rMITK MITK: feature/T29187-nnunet-show-download-models.

@floca Did you test the differential in the Workbench? Actually I was just implementing this feature witch was there for many years but never functioning. It was never of any use since we only had a single rendering display. What I realized, though: the use is barely existing, since you can only "send" a node to a render display / multi widget. But the StdMultiWidget displays the nodes anyway and the mxnMultiWidget should be controllered differently, right (since you only send the node to the whole multi widget, not to a single render window)?
So I can land the changes but I'm also fine with removing the feature entirely, eventually.

I realized that this only happens for the second, third ... tab icon. Even if you change the order / number of tabs (and e.g. have the "Rendering tree" icon as the first icon tab) the first tab icon does not move. So I guess this is a Qt-issue and I would not deem this important enough, since this is barely visible and nondisruptive.

Deleted branch from rMITK MITK: feature/T29158-CustomLabelSuggestions.

Deleted branch from rMITK MITK: feature/T29158-OptionallyAskForLabelNamesAndColors.

resolved :)

Resolved?

In T25643#169056, @kalali wrote:

However, this leads to the question why the global descriptors (singleton instance) are necessary in the first place. It was probably used to add local actions to the globally accessible node descriptors, e.g. from a custom plugin. So this task is closely related to T19752 and T25583.

I finished this task in feature/T29158-CustomLabelSuggestions. After a mental break I will go through the code and double-check for any business logic bugs or edge cases but I am confident. Will create a Diff later or tomorrow morning.

In T26399#238936, @floca wrote:

In T26399#238893, @kalali wrote:

I'm not sure if this is the reason (T24348: Invalid pointer exception due to invalid QModelIndex in QmitkDataStorageTreeModel) for the decision. I would go the route to deprecate the QmitkDataStorageModel and replace it with the QmitkDataStorageSimpleTreeModel.
However, the QmitkDataStorageSimpleTreeModel probably needs to be extended (e.g. dropping, changing hierarchy). Do we already have a task for this / should we tackle this in this release-phase?

This should be carefully discussed. I think some of the features QmitkDataStorageModel does not belong in a model.

D657 should give surface interpolation multilablel functionality. Contour interpolation also partially.