There seems to be a problem with the mitkDisplayActionEventBroadcast-class in general. Some classes have legacy code that disables the default display interactor to load a scenario-specific state machine and config file (see e.g. https://phabricator.mitk.org/source/mitk/browse/master/Modules/Segmentation/Interactions/mitkTool.cpp$121).
This is done in other classes. The problem is that the function does not reset the display action event broadcast instance but only display interactor instances.

see also:
BoundingShapeInteractor::DisableCrosshairNavigation()
QmitkMeasurementView::DisableCrosshairNavigation()

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.

For test purposes this has been solved for the segmentation module / plugin in 450d57dd of T24215.

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.

This problem still exists and existed also in 2018.04!

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

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.

The opposite problem can be seen e.g. in the Measurement plugin. There, this deactivation is not present, which means the PACS interactions are active all the time, even when activating/using a measurement tool. It would be useful to define in general how we want the behavior to be and how to implement it best, not just for the Segmentation plugin.

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.

In my opinion, option 3 would be the most intuitive and easiest to implement.

Additionally, we found that in mitk::SegTool2D::SegTool2D() is a hardcoded reference to the default display interaction (minus left mouse button), which doesn't make sense when using PACS or something else. It could be replaced by a more general approach to disable left-mouse-button interaction. We found that the underlying config xml files (e.g. DisplayConfigPACS.xml) are somewhat overwritten when adding another config that defines an already existing interaction. When it is added, only the newest option is used. (see mitkInteractionSchemeSwitcher.cpp). Instead of using the hardcoded configuration, one could instead add a small config that only defines left mouse button interaction as doing nothing. This should ensure that whatever config is currently active, the left mouse button will be disabled (and thus only used by the segmentation tool).
If this works, one should check if the config DisplayConfigMITKNoCrosshair.xml is still needed or could even be removed completely (decreasing redundant code).

What we haven't yet found a solution for is the previously mentioned problem of disabling/resetting configs when activating/deactivating tools. The current approach will still lead to unexpected behavior either way. It could make sense to rethink the whole design, since option 3 would mean it is totally fine for multiple interactors to be active at once, so none would need to be deactivated (and later reset) in the first place. For PACS, this could theoretically be removed completely when doing the proposed addition of allowing the user to disable the current PACS tool. However, it is still necessary for default MITK display interaction, where it doesn't usually produce problems since there is no way to "change" the default interaction while a tool is active (unless activating crosshair rotation, for example). Perhaps one needs to distinguish between default display interaction and PACS interaction, if that is possible.

To add to this: Point 2 sounds reasonable and that's what happens when the MITK mode is activated: The Segmentation Tool deactivates the left mouse click of the MITK mode.
However, this is not implemented for the PACS mode and would require additional complex logic.

But we thought that this is not consistent and mixes responsibilities:

• the segmentation tool is not deactivated if another left mouse click action is selected (e.g. a specific PACS mode)
• the segmentation plugin should not be responsible for changing the view interaction behavior automatically

That's why solution 3 is proposed: To have the user define if

• PACS / MITK interaction is activated with no segmentation tool activated
• Segmentation tool is activated with no PACS / MITK interaction activated
• both interactions are activated