Currently in the QMitkRenderwindow, any mouse/key event is sent to the MITK event handlers and the VTKQWidget event handlers.
This should be fixed by:
when MITK doesn't process the event the respective VTK handler has to be called.
This allows simultaneous conflict-free usage of MITK interaction and VTK interaction in the same renderwindow.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Restricted Maniphest Task | ||||
| Resolved | None | T3254 Revise QT Event loop handling in MITK |
Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.
This was probably an issue, since fomerly there was no feedback from the event handling about whether or not the event has been handled, now we have this feedback so it could easily be implemented. Is this still intended to _not_ notify VTK widget if the event has been handled by MITK Interactions - will this cause any side-effects ?
Yes, these changes may cause side-effects if the interactor that uses the event does not request an update of the rendering if one is necessary.
Giving the event to VTK almost always leads to a new rendering (if I remember correctly). Only propagating the event to VTK if it's necessary should fix this.
The mitk::Interactors might need some adapting...
[152d46]: Merge branch 'bug-3254-DontForwardHandledEvents'
2013-09-04 17:21:23 Christian Weber [ba6517]
fix logic of dropped events
2013-09-04 16:51:11 Christian Weber [de2469]
only re-send event to vtk if it hasnt been handled