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?
I stumbled upon these different tasks because of T26394: [Render window manager] Provide tree view / model, which is related to the mxnMultiWidget.

See T16165: Reinit after deletion for a reasoning. Both tasks are justified but maybe we should highlight / utilize the general preference "Call global reinit if node is deleted" more.

My changes related to this task were mainly to clear some classes and remove uncertainty (see T28617: Inconsistent view initialization in rendering manager).
As far as I see it some changes have been made in the subtask T28490: Segmentation plugin: "new" segmentation should not run reinit! and the respective D523: This was mainly concerned with NOT resetting the view / camera using a newly introduced parameter "resetCamera".

In T26399#238874, @kalali wrote:

• move the node-tree-items to their new parents immediately inside the QmitkDataStorageSimpleTreeModel::NodeRemoved, like it is done here: https://phabricator.mitk.org/source/mitk/browse/develop/Modules/QtWidgets/src/QmitkDataStorageTreeModel.cpp$675-684

I quickly tested the second suggestion and I was not able to reproduce the bug anymore.

@floca : Ilooked into this again and found the following:
After a node has been removed, inside QmitkDataStorageSimpleTreeModel::NodeRemoved the function QmitkDataStorageSimpleTreeModel::UpdateModelData is called. Here the data storage pointer is used to retrieve the data node subset of a given node predicate. The returned nodeset still returns 6 nodes in my case, although only 5 should exists, since one node was removed.
The node still exists in the data storage, because the signal for a node being removed (RemoveNodeEvent) is sent before the actual removal of the node from the list of nodes inside StandaloneDataStorage (data member m_SourceNodes)).

Instead of command output string parsing, the plan is to export available models' information and place it in a machine-readable format (eg. JSON) in the RESULTS_FOLDER.
This file can be further read by MITK and shown in GUI.
So, this involves making changes on the Python side, as well, for the dumping of the information in a machine-readable format (eg. JSON) natively.

The output of the abovementioned command, for reference:

Started dicussion about it. Current discussion result: We should go for a new model view based implementation instead of try to fix the current boiler plate code.
Have to discuss design of the model view pattern in detail in the next MITK meeting.

in the new data structure it won't happen as there is no active label anymore. But you are right I thought the same when I looked through the class. My motiviation to refine this obsolete class was only limited 🙈 .

I just stumbled upon the following:

yes, that will help. Also, this worklist will be quite helpful, allowing a new form of "batch-processing".

@gaoh maybe also the worklist feature covered by T29159 would also help/suffice? Than you could explicitly define the output path.

Yes. My work will take care of this. Just need to finish off the label merging for individual slices.

Yes, so I changed it already, and I am using the seriesUID as name for the images. Additionally, I had to add the layer property: Because by introducing the image name property, somehow the layer is also set (to a high number, probably). When I create a new SEG without setting the layer of the image to 0, the SEG is only put on top, when opening the data manager.