Documentation/Labs/ModulesAndEvents

From SlicerWiki
Jump to: navigation, search
Home < 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)