Change Details

We have a hierarchy of interaction events: Qt mouse events (`QMouseEvent`) are received by a `QmitkRenderWindow` and transformed into an `mitk::InteractionEvent` (e.g. `mitk::MouseMoveEvent`). This event is process by the renderer-specific dispatcher of the render window. The dispatcher now retrieves all `mitk::InteractionEventObserver` using the micro-service approach. Thus all observer get notified, regardless of whether they are in any way connected to the sending render window or not. A notified observer handles the event (e.g. the `mitk::DisplayInteractor` transform the event into a function call using its state machine configuration). An example of this process for a `mitk::DataInteractor` can be seen here: http://docs.mitk.org/nightly/DataInteractionPage.html Using our broadcast-class this would lead to another event being sent (via `itk::Object::InvokeEvent`). This is the concrete display interaction event that we want to process in a customized manner. However, we want to include filtering techniques on different levels: 1. Since the micro-service approach calls all interaction event observer, we want to filter if the interaction happened inside the MITK workbench part we are interested in (e.g. inside a specific multi widget editor). 2. Since we might only want to react on specific render windows (e.g. only those that display the same images), we want to filter if the itk event is relevant for a certain observer.

We have a hierarchy of interaction events: Qt mouse events (`QMouseEvent`) are received by a `QmitkRenderWindow` and transformed into an `mitk::InteractionEvent` (e.g. `mitk::MouseMoveEvent`). This event is process by the renderer-specific dispatcher of the render window. The dispatcher now retrieves all `mitk::InteractionEventObserver` using the micro-service approach. Thus all observer get notified, regardless of whether they are in any way connected to the sending render window or not. A notified observer handles the event (e.g. the `mitk::DisplayInteractor` transform the event into a function call using its state machine configuration). An example of this process for a `mitk::DataInteractor` can be seen here: http://docs.mitk.org/nightly/DataInteractionPage.html {F974798} Using our broadcast-class this would lead to another event being sent (via `itk::Object::InvokeEvent`). This is the concrete display interaction event that we want to process in a customized manner. However, we want to include filtering techniques on different levels: 1. Since the micro-service approach calls all interaction event observer, we want to filter if the interaction happened inside the MITK workbench part we are interested in (e.g. inside a specific multi widget editor). 2. Since we might only want to react on specific render windows (e.g. only those that display the same images), we want to filter if the itk event is relevant for a certain observer.

We have a hierarchy of interaction events: Qt mouse events (`QMouseEvent`) are received by a `QmitkRenderWindow` and transformed into an `mitk::InteractionEvent` (e.g. `mitk::MouseMoveEvent`). This event is process by the renderer-specific dispatcher of the render window. The dispatcher now retrieves all `mitk::InteractionEventObserver` using the micro-service approach. Thus all observer get notified, regardless of whether they are in any way connected to the sending render window or not. A notified observer handles the event (e.g. the `mitk::DisplayInteractor` transform the event into a function call using its state machine configuration). An example of this process for a `mitk::DataInteractor` can be seen here: http://docs.mitk.org/nightly/DataInteractionPage.html {F974798} Using our broadcast-class this would lead to another event being sent (via `itk::Object::InvokeEvent`). This is the concrete display interaction event that we want to process in a customized manner. However, we want to include filtering techniques on different levels: 1. Since the micro-service approach calls all interaction event observer, we want to filter if the interaction happened inside the MITK workbench part we are interested in (e.g. inside a specific multi widget editor). 2. Since we might only want to react on specific render windows (e.g. only those that display the same images), we want to filter if the itk event is relevant for a certain observer.