As of now, we will remain with Qt 5.12 for a while, since it is a well maintained long-term version

The cause for this problem lies in missing state-transitions of the interaction state-machine. DisplayConfigPACS.xml defines the events based on which the state-machine in DisplayInteraction.xml acts. For modifier-based interactions, a MousePressEvent / MouseReleaseEvent in combination with a modifier-key are responsible to transition into / out of the corresponding state ("move", "zoom", ...). When the modifier-key is released BEFORE releasing the mouse button, the second event is never triggered, causing the state machine to get stuck in that specific state, which blocks most other interactions.

It seems this idea is currently not directly implementable, in the way of clicking a button again to deactivate it. In the constructor of QmitkInteractionSchemeToolBar.cpp the line m_ActionGroup->setExclusive(true); guarantees that exactly one option is selected at any time. Since Qt 5.14 there is the option to set an ExclusionPolicy of ExclusionOptional, which accomplishes exactly what was thought of in this task. As this is not available yet, one would either need to manually implement the desired behavior of activating/deactivating actions, or wait until perhaps a newer version of Qt is used.

So far, I have not heard from anybody about the message I sent around. I wanted to send another reminder of it soon, in case some people just forgot

André, Amir and I discussed the problem a bit and found multiple problems and ideas. The general question is: what is the intended behavior? Some options are:

1. only one interaction can be active at any time. This would mean activating a segmentation tool would deactivate any PACS functionality and vice versa. Not really what we want, since it prohibits using regular MITK interaction behavior (e.g. zooming with the right mouse button) while segmenting
2. only one left-mouse-button interaction is active at any time. Activating a segmentation tool would automatically disable left-mouse-button usage for display purposes
3. multiple interactors can operate on the same events, i.e. PACS + segmentation at the same time is intended behavior, if the user wishes to do so. To make this useful, it should be possible to deactivate PACS interaction, either by allowing to click a button again to deselect it or by providing an additional button that does nothing on left clicks.

The problem really seems to be the disabling / resetting of interactors that was mentioned in an earlier comment, even with the fix that corrects the resetting when the tool is deactivated again. Correct usage would be:

1. moving around the gui, using PACS
2. selecting a segmentation tool (which deactivates other interactors)
3. only using the segmentation tool, without changing the view
4. deactivating the segmentation tool (and thus reenabling previous interactors)
5. -> everything works as intended

When a PACS tool is selected after step 2, this messes up the active interaction and after the segmentation tool is deactivated it resets to what was previously selected, before the tool was activated.

Some additional observations:

• The behavior works as expected when selecting the segmentation tool AFTER changing the PACS action. Only when selecting a new PACS action while the segmentation tool is still active, they both act simultaneously
• When some PACS action (action 1) is selected, then a segmentation tool is selected, the PACS action is changed (to action 2), and the segmentation tool is deselected again, PACS action 1 will be active but action 2 is marked in the sidebar as selected

I was not able to reproduce this bug on Windows with the v2021.02 release as well as the current develop branch

I was able to reproduce the bug for all morphological operations (Dilation, Erosion, ...) and also in all orientations (axial, coronal, sagittal). Other segmentation utilities all work without problem.

It seems to be the same bug, I just failed to find the existing task. Since I found it in the last Release version, the bugfix was just not included yet, but the problem is still solved. I guess this task can be closed then

I've started a draft for a message to send around, found here if you want to have a look or add something: https://hub.dkfz.de/s/HzpkipeWRkq3K8K

I got the same result as kislinsk, the crash only occurs when the documentation is open and not in the background