Difference between revisions of "Slicer3:EventBroker"

From NAMIC Wiki
Jump to: navigation, search
(New page: == Currently === 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) == Problem...)
 
m
Line 1: Line 1:
== Currently ===
+
== Currently ==
 
The basic idea of the EventBroker is that currently we have a lot of this kind of code in GUIs:
 
The basic idea of the EventBroker is that currently we have a lot of this kind of code in GUIs:
  

Revision as of 13:45, 18 December 2007

Home < Slicer3:EventBroker

Currently

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?