Difference between revisions of "Slicer3:EventBroker"
From NAMIC Wiki
Line 41: | Line 41: | ||
* perhaps can be model after:[http://java.sun.com/products/jms/javadoc-102a/index.html Java Message Service (JMS) API] | * perhaps can be model after:[http://java.sun.com/products/jms/javadoc-102a/index.html Java Message Service (JMS) API] | ||
+ | |||
+ | Additional possible extensions: | ||
+ | |||
+ | * rather than maintaining a distinct queue, the broker could queue events into the GUI event queue | ||
+ | |||
+ | * the event queue could be protected by a mutex lock so that multiple threads can access the MRML scene in parallel but only the GUI thread talks to the display |
Revision as of 17:49, 10 January 2008
Home < Slicer3:EventBrokerCurrently
The basic idea of the EventBroker is that currently we have a lot of this kind of code in GUIs:
node->AddObserver(vtkCommand::ModifiedEvent, callbackCommand)
Problems
The problems with this:
- node 'owns' the observer, but the callbackCommand is opaque so it doesn't know anything about what will happen when the event is invoked
- the GUI needs to explicitly remove the observer before it is destroyed
- node is not introspectable; you cannot get a list of observers on the node
- there's no easy way to know what side effects will happen for any Set call (either a priori or experimentally).
- there's no way to collapse events or disable them
Goals for Solution
So the EventBroker would be a singleton, perhaps owned by the ApplicationLogic that would look something like:
broker->RegisterObserver(node, vtkCommand::ModifiedEvent, this, callbackCommand);
The broker would do the following:
- add DeleteEvent observers to both node and this so it can remove the observer automatically if either side is destroyed
- keep an introspectable list of all observers it knows about
- have an option to keep a log of all event invocations for debugging and performance analysis
- have an option to turn off all event invocations
- have an option to queue all event invocations and invoke them later
- have methods to collapse redundant events in the queue
- perhaps have method to pass event invocations from a processing thread to the main GUI thread?
- perhaps can be model after:Java Message Service (JMS) API
Additional possible extensions:
- rather than maintaining a distinct queue, the broker could queue events into the GUI event queue
- the event queue could be protected by a mutex lock so that multiple threads can access the MRML scene in parallel but only the GUI thread talks to the display