Hi,
I am wondering if it would be possible to send the focus change events from
interactors rather than from mitk::Dispatcher.
The reason is a bit complicated. We have a custom viewer with very rigorous
unit tests. For instance, the state changes of the viewer have be atomic
for any interactions. E.g. if the user clicks in a render window, the state
of the viewer has to change in one go and then all the signals (including
ITK events and Qt signals) have to be sent out. Partial state change,
signals, another partial state change then other signals again: this is not
a valid scenario.
I enforce this policy by BlockUpdate() and BlockSignals() functions. At the
beginning of the interactions I block the update of the viewer, that blocks
the signals from itself and from the slice navigation controllers. (See
#16895.) During the interaction the state changes are recorded but the
renderer is not updated. At the end of the interaction I unblock the
update, that realises the state changes, unblocks sending signals and sends
out the pending signals.
This works pretty well, except for the focus event. Now when the user
clicks in a render window, the dispatcher sends out an
mitk::FocusChangedEvent, the viewer catches it and changes the selected
window. Then the interactor receives the mouse press event, and changes the
state again (world position at crosshair and the position of the crosshair
in the window) and sends out signals about this. If someone is listening to
the focus change event, he will find the viewer in an invalid state. (The
selected window has changed, but the position has not yet.)
It would be possible to ignore the focus change event in the viewer and
change the selected window only when the interactor is notified. But this
is another only invalid scenario, a focus change event is sent, but the
state of the viewer has not changed.
A possible solution could be to move sending out the focus change event
from mitk::Dispatcher to an mitk::EventStateMachine or
mitk::DisplayInteractor action. Then subclasses could override the handler
function.
A possible drawback is that if there is a render window which has no
interactor then the focus event is not raised. I do not have that use case,
though, and I believe MITK does not use the focus events at all, anyway.
Does it make sense?
I am happy to send a patch.
What do you think?
Cheers,
Miklos
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users