I quickly modified the code to see if this works potentially. For this I set m_PaintingPixelValue to 1 for both cases and used the OnMousePressedOutside-function also for a mouse pressed inside:

m_PaintingPixelValue = inside ? 1 : 1;

I started looking into this and what I found inside mitk::RegionGrowingTool::OnMousePressed:

if (inside)
      {
        MITK_DEBUG << "Clicked inside segmentation";
        // For now, we're doing nothing when the user clicks inside the segmentation. Behaviour can be implemented via
        // OnMousePressedInside()
        // When you do, be sure to remove the m_PaintingPixelValue check in OnMouseMoved() and OnMouseReleased()
        return;
      }
      else
      {
        MITK_DEBUG << "Clicked outside of segmentation";
        OnMousePressedOutside(nullptr, interactionEvent);
      }

Looking at the file history it doesn't look like that was implemented in MITK at anytime.
So we can actually discuss if we want to allow such a functionality and if, what the obstacles are.

Obviously it was not clear what we are expecting here so I will close this task and refer to two new tasks for the specific topics mentioned here:

• Where to put "publicly available" / "shareable" test data --> availability: T28480: [Checklist] [Test data] Define publicly available location to store user test data
• Which data to use for specific checklists --> suitability: T28481: [Checklist] [Test data] Define publicly available user test data

@floca I could only find two tasks mentioned here that are not closed, T27872 and T27684, but they are unrelated to the task description. Can this task be closed?

Don't get me wrong - I'm not saying that you or someone "verschlimmbesserte" anything :D I understand and appreciate all the effort that has been made by you.
I am more thinking of a different approach architecture wise - you already mentioned "abstraction levels". For me it seems as if different classes and functions are on the same "level" of doing something but they do it differently - which makes it even harder to grasp the logic behind it. That's why I mentioned "class diagrams". Also, often classes and functions are way too overloaded (e.g. SegTool2D) with way too many responsibilities.

Ok I have to admit: The whole code base that is related to this topic is totally unclear to me and I find it very hard to understand what is going on. I don't know why the code is like that but I would highly suggest to simplify and clean the relevant classes and functions as much as possible before it becomes problematic (e.g. more complex cases with 4D-dynamic segmentations with multi-layer multi-label segmentation masks or similar). Also, I highly doubt that this is future proof when it comes to changes in the following years so as already mentioned in my last comment: I think we really need to discuss this topic - maybe it helps to have a clearer picture by creating (class) diagrams with relations etc.

Thanks for the clarification. I will look into the FeedbackCntourTool and ContourModelUtils and see if I can make sense of all this :D
Depending on what I find out I think we should really talk about the future of the (multilabel) segmentation modules / plugins and how we can simplify the code base (generalize it) and remove redundancy as well as decouple classes etc.

I am not sure what is exactly done here to reproduce. To get any help page I have to click on a plugin anyway. How would I provoke a blank page?
When I use F1 while the Standard Display is activated I get a blank page for the Standard Display. If that's what is meant than we need to reconsider how to display this specific help page: There is a description of the "four window view" inside src\Plugins\org.mitk.gui.qt.ext\documentation\UserManual\MITKUserManual.dox but we can not move it to the stdmultiwidgeteditor-plugin as it contains more information about the workbench, not only about the standard display.

I tried to reproduce this issue and found the following:
With the changes in T28211 @floca mentioned, there is no legend anymore m_Controls.chartWidget->SetShowLegend(false);
Showing this legend again displays "histogram" as the label name - not even the original segmentation node name. Now when I add another segmentation and add it to the statistics, the histogram is completely removed (it's calculated but the widget does not provide any space for the histogram anymore).

@floca I sarted looking into this and found out the following:
The threshold tool used is QmitkBinaryThresholdToolGUIBase, which is a subclass of QmitkAutoSegmentationToolGUIBase. This class uses the AutoSegmentationTool, a subclass of the mitkTool. As far as I can see the target node that will be connected with this tool upon activating the tool is done inside mitk::AutoSegmentationTool::GetTargetSegmentationNode().
However, there is no information about any layer or even the information that this can be used with multilabel segmentation nodes.

I will put this up for grabs as it does not make sense to start a new project now. Personally I will investigate further after the Conan evaluation report has been written.

One long term solution would also be to create an own Litmus Conan recipe and use this external Litmus package inside MatchPoint.

I was trying to test if I can forward the ITK_USE_FILE variable inside the ExternalProject call to Litmus, as we did in the change for the CMAKE_PREFIX_PATH. I realized that neither the CMAKE_PREFIX_PATH nor the ITK_USE_FILE is correctly forwarded and accessible inside Litmus CMake configuration.

I started looking into this and some changes need to be made in order to get some errors out of the way:

• Conan-center recipes are built without CMake find / config files, as mentioned here: In short: Conan creates own find / config files so they are removed from the original package.

I set the priority to high because we defined that having appropriate data at a reachable location is one of the most pressing issues when it comes to manual GUI tests.

Does not seem to happen anymore. Can somebody confirm, e.g. @kislinsk?

In T26485#185423, @kalali wrote:

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.

I looked into it and I have the impression that there is a lot of unnecessary complexity created in order to generate a valid UI state. The problem, as far as I can see, lies in the overuse of if-statements and having functions that have way to many responsibilities. This is a typical "clean code" task and I suggest to go through the whole QmitkSegmentationView.cpp file and apply some best practices of writing clean code.
But since it is not clear how much effort we want to put into it (thinking of T28142), it might be wise to not work on this right now but to use a general refactoring task (parent task) to fix the mentioned bug.
I advise also to have a look https://phabricator.mitk.org/file/data/7bghshzurxwupnipv3dl/PHID-FILE-n2hwm6xv2mil3ola47sq/QtStateMachineFramework.pdf.

It seems as if datanode->GetBoolProperty("binary", binary, renderer) inside mitkImageVtkMapper2D always results in binary being false. This might be true for our LabelSet images, but the properties view still shows the property binary as true, e.g. for segmentations created with the classic segmentation view.

Following this, are there some requirements that need to be specified here T28280?