In the CustomMultiWidget- and RenderWindow-Synchronization-scenarios we came across the QmitkMouseModeSwitcher and the mitkMouseModeSwitcher.
We spotted several flaws in the design and implementation so I propose to rework both classes. This way we could also include our ideas that arose in the mentioned scenarios (see T24216 and T24300).
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | kalali | T24356 Rework mouse mode switcher | ||
| Resolved | kalali | T24357 Rework mitkMouseModeSwitcher | ||
| Resolved | kalali | T24358 Rework QmitkMouseModeSwitcher | ||
| Resolved | kalali | T24367 SetWidgetPlane-functions in QmitkStdMultiWidget not used | ||
| Resolved | s434n | T24368 Interaction scheme has different level of interaction | ||
| Resolved | kalali | T26486 PACS mouse mode does not allow scrolling with mouse wheel | ||
| Resolved | kalali | T24635 PACS scroll leads to an infinite loop if no image is loaded |
Event Timeline
Comment Actions
This task is intended to combine both classes and show their interaction and usage.
Currently the StdMultiWidgetEditor creates a QmitkMouseModeSwitcher as part of its GUI (via pimpl).
It also creates a StdMultiWidget as part of its GUI (via pimpl).
The StdMultiWidget automatically initializes a new mitkMouseModeSwitcher.
This mitkMouseModeSwitcher is set as the mitkMouseModeSwitcher of the QmitkMouseModeSwitcher of the StdMultiWidgetEditor
The QmitkMouseModeSwitcher GUI element can then be used two switch the mouse mode of the multi widget editor: The user can click buttons in the mouse mode switcher toolbar which triggers the OnMouseModeChangedViaButton-function inside the QmitkMouseModeSwitcher. This GUI element is only visible if the PACS-like interaction mode is selected via the editor preferences in the MITK workbench. This means that the mouse mode can only be changed for the PACS-like interaction mode (this is also double-checked in the mitkMouseModeSwitcher itself).
The interaction scheme can be changed at different places:
- The render window menu (top-right menu inside each render window) allows to change the interaction mode. This is passed to the mouse mode switcher of the QmitkStdMultiWidget and leads to loading a different .xml interaction-config file.
- Additionally the editor preferences in the MITK workbench can be used to change between the classic MITK interaction mode and the PACS-like interaction mode. This is done by retrieving the mouse mode switcher of the QmitkStdMultiWidget and setting its current interaction scheme.
There are several things to point out here:
- We could split the class into a real mouse mode switcher that only changes the mouse mode .xml-config file for a new mouse mode.
- Another class should be responsible for changing the interaction scheme: the mouse mode and the interaction scheme are independent from each other. The only exception: The mouse mode can only be changed in the PACS-like interaction mode. However, this can be checked at the place where the mouse mode is changed. This is currently only done inside the QmitkMouseModeSwitcher, which is also only visible if the PACS-like interaction mode is activated. (Sidenote: The QmitkMouseModeSwitcher changes the interaction mode to PACS-like interaction anyway, each time the mouse mode is changed; this is not its job!)
- the QmitkMouseModeSwitcher can actively change the check-state of the buttons if it receives an event that indicates that the mouse mode has been changed (new button corresponding to the mouse mode will be checked). This is done by observing the set mitkMouseModeSwitcher and calling a function on receiving a MouseModeChangedEvent. However, this event is even sent when the QmitkMouseModeSwitcher itself changes the mouse mode. Also the event is sent when the interaction scheme is changed. This breaks expectations and can confuse developers. Since the mouse mode can only be changed inside the QmitkMouseModeSwitcher there is no need to listen to the events of the mitkMouseModeSwitcher.
All these different problems and more led to the decision to rework both mouse mode switcher classes and to include possible future requirements. This is done in the subtasks.
Comment Actions
Questions:
- Do we allow different mouse modes / interaction schemes for different render windows / for different multi widgets / workbench parts?
- Are all modes / schemes still needed?
Comment Actions
Well, I don't think that we need more flexibility for the MITK Workbench, so if it isn't driven by your needs for the custom editor, keep it simple. :)
- Are all modes / schemes still needed?
We still need the default and PACS mode as well as the schemes accessible from the render window menus, yes.
Comment Actions
Well, there exists the DisplayConfig.xml, which does not seem to be used anywhere.
There is a DisplayConfigMITK.xml, a DisplayConfigMITKNoCrosshair.xml and a DisplayConfigMITKLimited.xml, where the first is the original config, the second removes crosshair positioning and the third additionally removes scrolling.
The second is used in BoundingShapeInteractor and the third is used in QmitkMeasurementView.
There is something written about legacy solution in these classes so I'm wondering if we still need these different schemes.
(We could also think about a mechanism to disable/enable some interaction actions (e.g. scrolling) on request during runtime.)
However, I agree that the mentioned configurations are not directly associated with the mouse mode switcher, as they are set by individual classes (as mentioned above).
Comment Actions
There are several things to point out here:
- We could split the class into a real mouse mode switcher that only changes the mouse mode .xml-config file for a new mouse mode.
A new class has been introduced that handles all basic MITK- and PACS- interaction .xml-files in T24357.
- Another class should be responsible for changing the interaction scheme: the mouse mode and the interaction scheme are independent from each other. The only exception: The mouse mode can only be changed in the PACS-like interaction mode. However, this can be checked at the place where the mouse mode is changed. This is currently only done inside the QmitkMouseModeSwitcher, which is also only visible if the PACS-like interaction mode is activated. (Sidenote: The QmitkMouseModeSwitcher changes the interaction mode to PACS-like interaction anyway, each time the mouse mode is changed; this is not its job!)
Interaction schemes have been changed, mouse mode has been removed in T24368.
- the QmitkMouseModeSwitcher can actively change the check-state of the buttons if it receives an event that indicates that the mouse mode has been changed (new button corresponding to the mouse mode will be checked). This is done by observing the set mitkMouseModeSwitcher and calling a function on receiving a MouseModeChangedEvent. However, this event is even sent when the QmitkMouseModeSwitcher itself changes the mouse mode. Also the event is sent when the interaction scheme is changed. This breaks expectations and can confuse developers. Since the mouse mode can only be changed inside the QmitkMouseModeSwitcher there is no need to listen to the events of the mitkMouseModeSwitcher.
A new class has been introduced that simplifies the scheme switching in T24358.