Documentation/Labs/ModulesAndEvents

This page keeps track of Greg's notes on how to hook up module events

Motivation

• Getting things working in Slicer can be hairy
• There is not always the right kind of documentation for what you want to do.
• The goal of this page is to take some notes on this process for eventual inclusion in the developer documentation.
• This is intermediate-level documentation
• Scope is limited to C++ development

MRML nodes

• MRML nodes are used to store persistent state. You need to use MRML nodes if you want to save and restore slicer scenes.

Events

• MRML nodes can emit events. Logics don't emit events ?
• Either MRML nodes or logic classes can receive events.
• To receive an event, define a function called ProcessMRMLEvents(). This function receives all requested events as an (object, event id) pair. The event id might or might not be unique.
  • If I make my own events, how to I ensure they are unique?

Logic classes

• Logic classes implement processes. They serve purposes such as:
  • Implement helper logic for widget classes, so that all business logic can be performed without the need of a GUI
  • Implement filter-type logic, which manipulates MRML nodes without need for persistent state
• There may be multiple logic classes associated with a single MRML node

Widget classes

• What is the difference between qvtkConnect and qvtkReconnect??

Parameter nodes

• These should be a serializable copy of the widget state

MRML nodes and multithreading

• Slicer is implemented as a single threaded process
• Therefore, there is no need to implement transaction logic to ensure atomicity when modifying multiple MRML nodes

Best practices for hookup (?)

Between parameter node and widget

• signal from UI element received by module widget
• module widget updates module MRML parameter node (directly, or via module logic) function call
  • the widget normally gets modified events from parameter node, and calls updateWidgetFromMRML()
  • DisableModifiedEventOn()/Off() can be used to prevent MRML parameter node from emitting modified events back to widget

From observed node (Markup Node) to observing MRML node (Beam Node) and back to widget

• Note: you can observe without referencing and vice versa
• Markup Node fires Modified event (or custom event)
• Beam node receives event in ProcessMRMLEvents()
  • Should Nodes receive events or should this be logic
• Beam node fires event using Modified() (or InvokeEvent())
• module logic receives event
• module logic fires event to module widget
• module widget updates UI
  • Use blockSignals() to prevent UI element from emitting signals
• module widget updates parameter node (if needed)