Page MenuHomePhabricator

Interaction scheme has different level of interaction
Open, NormalPublic

Description

There seems to be an inconsistency in the usage and effect of the interaction scheme and the mouse mode: They seem to mix their level of responsibility.

The Interaction scheme can change from MITK scheme to PACS scheme. This is done by setting a property in the editor's preference page.
Using the render window menu of each render window inside the multi widget editor, the user is also able to change the interaction scheme to rotation scheme, swivel scheme etc.
However, these interaction schemes from the render window menu only work with the MITK scheme, so they switch the interaction configuration back to a (modified) MITK interaction.

The PACS scheme can also be modified by using the buttons inside the mouse mode toolbar QmitkMouseModeSwitcher. Here, the different modifications are explicitly called MouseMode, which is inconsistent compared to the MITK scheme.

My suggestions is to have two interaction schemes (MITK and PACS) and provide different mouse mode for both of them. This would also allow us to redefine the .xml-config files and reduce them to a minimum of xml lines.
We should consider this while reworking the mouse mode switcher classes.

Revisions and Commits

Event Timeline

Basically we have 9 schemes:

  • MITK standard
  • MITK rotation uncoupled
  • MITK rotation coupled
  • MITK swivel
  • PACS standard
  • PACS level window
  • PACS pan
  • PACS scroll
  • PACS zoom

The MITK modes each have an own complete .xml-file.
The PACS modes only add xml-text to the basic PACS.xml-file.

We should consider aiming for a consistent interaction scheme-handling (e.g. having each mode as an own complete .xml-file or, as written in the task description, use two basic modes and use all other modes as configurations with minimal .xml-files).

Complete .xml-files are used with SetEventConfig, whereas minimal .xml-files are used with AddEventConfig, which adds to a previously set event config.

I decided to go for having an own complete .xml-file for each mode, so I added the full definition for the different PACS modes.
The reason is that we want to have a consistent interaction scheme-handling which means either having full definition for both MITK and PACS modes or having base- and additional definition (like the original PACS modes). But changing the MITK configuration files to the base- and extra-mode variant requires event_variants to be empty in order to disable certain mouse events. Additionally any implementation needs to do two calls, one for setting the base-mode and one for adding the extra mode to make sure the correct base-mode is always set (e.g. switching from MITK to PACS). This was undesirable.

kalali claimed this task.

Has been solved on top of T26476.

kalali added a subscriber: s434n.

This task / branch was never merged into master; the mentioned BlackSwan task T26476 is still not contained in master / develop.
For reasons of cleanliness I will open a new branch / differential containing just the changes related to this task such that we can merge the new branch into develop and close this task.
@s434n will help me evaluate the relevance / validity of the changes.

kalali added a revision: Restricted Differential Revision.Wed, Aug 25, 11:33 AM

The proposed change goes kind of in the opposite direction of recent changes that were made, specifically in D531 and part of D532. If the approach of D535 is to be continued, it would need to take into account D532, in which an additional PACS scheme was introduced that leaves the left mouse button unused.
I would personally prefer the direction we have been taking now, splitting up the config files into smaller chunks. This reduces code redundancy, instead of having almost identical config files many times.
Also, in my opinion the approach of D531 makes a lot of sense for overlapping interactions. It allows to change only the aspects of interaction that are necessary while staying oblivious to the current interaction (MITK default, with swivel, PACS, ...). If we want to use full configs, one would need any variation of each scheme for each situation where alterations may be necessary. For example 2D segmentation tools require the left mouse button, so any possible interaction scheme needs to have a corresponding version where the left mouse button is unused. If a tool requires something new, like the right mouse button, new config files have to be implemented for every existing interaction scheme instead of just one file that will be appended.

We discussed this and came to the conclusion to abandon D535.
@s434n will take over and create split MITK config files to be consistent with the PACS config file style.
Generally, as mentioned in the previous comment, splitting the config files "into smaller chunks" [...] "allows to change only the aspects of interaction that are necessary".