I just tested the latest mxn multi widget on develop and now the render window menu icons have a thick border around them - which does not look nice. Need to find out how this happened.

If I remember correctly I created a new renderwindowtreemodel, based on QmitkAbstractDataStorageModel because I could not reuse the classic tree inspector. Reason for this was probably mainly the different handling of data nodes for specific render windows. I will re-recheck this within the next weeks and probably come back to you for consultation ;)

The multi widget was was already introduced 2 years ago and used and tested inside the BlackSwan project.
We will continue working on this again and open a new meta-task for that purpose. Subtasks will be moved to the new meta-task and this task will be closed.

The refactored tests have been merged into dev; the CDash tests are also green again!

That's good to hear so I'm not missing something. However, I never paid attention to this and I'm still wondering why that's the case.
So in my tests I need to find a way to predict the correct outcome in order to make the test succeed.

I used the following code snippet to test the retrieval of the data nodes

void setUp() override
{
  for (int i = 0; i < 3; ++i)
  {
    m_LevelWindowManager = mitk::LevelWindowManager::New();
    m_DataManager = mitk::StandaloneDataStorage::New();

@kislinsk:
So I took a closer look into this and I found out the following:
Inside mitkLevelWindowTest:

• m_DataNode1: 0x00000221c86a80f0
• m_DataNode2: 0x00000221c86a6930
• m_DataNode3: 0x00000221c86a7bf0

We also found out that the current LevelWindowManagerTest fails: https://cdash.mitk.org/testDetails.php?test=774190&build=12215
The problem is the modified LevelWindowManager in combination with the mentioned random tests: The random tests can lead to all nodes having an invalid rendering mode. The LevelWindowManager has been modified in T28250 which conflicts with the current level window manager test.

This is a bigger topic, connected to the refactoring of the segmentation and should be handled in multiple sub-tasks, to split the topic into smaller issues.

I will start looking into this to give some examples of important warnings / errors that the user should know about.

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

@floca Is this something worth looking into before the refactoring is done? If we stick with LabelSetImages and the basic backend of the utilities, I don't see a reason for this to be postponed.

Maybe an option inside the node selection dialog would work here?

Is this an issue we need to address? Did anyone else experience this behavior?

I will close this for now as the issue cannot be reproduced.

No further work has been done here but I would like to keep this topic in mind when refactoring the segmentation modules.

@floca I can't reproduce this anymore. However, I'm not sure where some changes were done. Do you have an idea?

I agree on that. I had some problems with that with the new mxn-multiwidget. The topic was also mentioned in T27613: Improve reinit behavior.

So I modified the "Assert"-functions to directly encapsule the CPPUNIT_ASSERT_MESSAGE calls in that function as you suggested. The error still occurs and now the problem is that I can't see where the error occurs because it happens inside the "Assert"-function (which is the same for each test). So that is not an option. Any other suggestions? I could split the test to test each node individually.

Ok so I found a bug for the test in line 320. This showed some complex behavior with the level window manager, which I don't want to address here.
However, the test in line 288 still randomly fails - when debugging in that line the test does not fail but fails in line 292.

Yes, I agree that this is not the most straight forward way to do it. There was a reasoning behind it to do it that way.
I will think about it - but currently it seems as if something is not correct with the tests, in a way that I am actually expecting wrong test results - so I need to rethink the expected results and change the true / false arguments accordingly.

Since I modified and merged T28250 I wanted to continue here. I still get failed tests in line 288 and in line 320:

assertion failed
- Expression: AssertImageForLevelWindowProperty(false, true, false)
- "imageForLevelWindow" property not correctly set

assertion failed
- Expression: AssertImageForLevelWindowProperty(true, false, false)
- "imageForLevelWindow" property not correctly set