Hi Miklos, I would like to see your patch. Could you please create a differential ( https://phabricator.mitk.or g/differential/ ) so we can discuss your changes there? Thank you!
Regards Christoph On Fri, 2016-07-15 at 19:01 +0200, Miklos Espak wrote: > 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
