Interaction Concept Implementation

Table of Contents

• Description of Interaction Concept Implementation in MITK
• Dispatcher
  • Event Distribution
• State Machine & Configuration

This page describes some technicalities of the implementation and the workflow, for a detailed list of tutorials see Topics related to interaction - further information: .

Description of Interaction Concept Implementation in MITK

Dispatcher

After an event is received by the mitk::Dispatcher it is given to a mitk::DataInteractor that has to decide if it can process this event. On a high level this is done by the mitk::EventStateMachine. First the state machine asks if the received event is known in the configuration. If it is, the matching variant name is returned. Then the state machine checks if there exists a transition in its current state that is triggered by this event variant. If this is the case all actions that are associated with this transition are queried and executed. The actions themselves are implemented on mitk::DataInteractor level. The following diagram illustrates the process:

Each mitk::BaseRenderer creates a mitk::BindDispatcherInteractor object which encapsulates the connection between the mitk::DataStorage and the mitk::Dispatcher, and thereby allowing a mitk::DataInteractor to register with a mitk::Dispatcher when only knowing the mitk::DataNode.

mitk::BindDispatcherInteractor creates a new mitk::Dispatcher object and registers for mitk::DataNode events at the mitk::DataStorage, as a callback function the dispatchers AddDataInteractor() and RemoveDataInteractor() functions are set.

This way the mitk::Dispatcher is notified about all changes regarding DataNodes that are shown in the mitk::BaseRenderer. When a node is added, remove or modified the mitk::Dispatcher can check if a mitk::DataInterator is set, and accordingly add or remove this mitk::DataInteractor from its internal list.

Events that are generated within the scope of the mitk::BaseRenderer are sent to the associated mitk::Dispatcher to be handled.

Event Distribution

A mitk::Dispatcher can operate in different processing modes, which determine how the interactor that receives an event is chosen. These modes are managed and set by the mitk::Dispatcher itself.

• Regular:
  DataInteractors are sorted by their layer, and distribution is stared with the top-most.

• Connected Mouse Action:
  A connected mouse action is described by the sequence of Mouse-Press, (optionally) Mouse-Move , Mouse-Release Events.
  Within this sequence all events are sent to the same mitk::DataInteractor, the one which received the event from the Mouse-Press action.
  m_ConnectedMouseAction - is set to true, when a Mouse-Down Event occurs and a DataInterator takes the event and m_SelectedInteractor is then set to this DataInteractor.
  m_ConnectedMouseAction is reset to false, after the Mouse-Release Event occurs,
  while it is true, the m_SelectedInteractor is the only one that receives Mouse-Events.

• Grab Input:
  Whenever a mitk::DataInteractor performs a state change into a state that is marked by the grab input-tag, the mitk::Dispatcher switches into this mode. As long as it is in this mode ONLY the selected mitk::DataInteractor will receive the event. This mode is ended when the mitk::DataInteractor switches back to a state without a tag/ or the REGULAR-tag.
  

  Note

  In this mode mitk::InteractionEventObserver instances will NOT receive the events.

• Prefer Input:
  Basically works as Grab Input, with the difference that if the mitk::DataInteractor is in the prefer input state but cannot process the event offered, it will be offered to the other interactors in the regular way.
  In this mode mitk::InteractionEventObserver instances ARE informed.

State Machine & Configuration

A mitk::EventStateMachine points to a state, which in turn references transitions (which describe a change from one state to another) and actions (indicating which functions are executed when a transition is taken).