Documentation/Labs/ModulesAndEvents - Revision history

Gregsharp at 16:23, 6 January 2016

2016-01-06T16:23:56Z

Gregsharp at 15:43, 6 January 2016

2016-01-06T15:43:04Z

Gregsharp at 15:27, 6 January 2016

2016-01-06T15:27:17Z

Gregsharp: Created page with "This page keeps track of Greg's notes on how to hook up module events TOC == Motivation == * Getting things working in Slicer can be hairy * There is not always the rig..."

2016-01-06T15:14:41Z

Created page with "This page keeps track of Greg's notes on how to hook up module events __TOC__ == Motivation == * Getting things working in Slicer can be hairy * There is not always the rig..."

New page

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

__TOC__

== 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.
* 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.
* MRML nodes can emit events. To emit an event, do ??
* MRML nodes 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.

== 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

== 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

@@ Line 32: / Line 32: @@
 * What is the difference between qvtkConnect and qvtkReconnect??
 == MRML nodes and multithreading ==
@@ Line 40: / Line 44: @@
 == Best practices for hookup (?) ==
 * signal from UI element received by module widget
-* module widget updates module MRML node via module logic function call (no events)
+* module widget updates module MRML parameter node (directly, or via module logic) function call
-* module MRML node updates custom MRML node via logic function call (no events)
+** the widget normally gets modified events from parameter node, and calls updateWidgetFromMRML()
-* custom MRML node fires Modified event (or custom event)
+** DisableModifiedEventOn()/Off() can be used to prevent MRML parameter node from emitting modified events back to widget
-* widget logic (or widget MRML?) receives event
-* widget logic updates widget MRML (if needed)
+From observed node (Markup Node) to observing MRML node (Beam Node) and back to widget
-* widget logic (or widget MRML?) fires event to module widget
+* Note: you can observe without referencing and vice versa
 * module widget updates UI
-** How does this not re-fire the above loop?
+** Use blockSignals() to prevent UI element from emitting signals

@@ Line 14: / Line 14: @@
 * MRML nodes are used to store persistent state.  You need to use MRML nodes if you want to save and restore slicer scenes.
-* MRML nodes can emit events.  To emit an event, do ??
-* MRML nodes 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.
+== Events ==
 == Logic classes ==

@@ Line 8: / Line 8: @@
 * 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.
 * Scope is limited to C++ development
@@ Line 22: / Line 23: @@
 ** 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
 == MRML nodes and multithreading ==
@@ Line 27: / Line 32: @@
 * 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

Documentation/Labs/ModulesAndEvents - Revision history

Gregsharp at 16:23, 6 January 2016

Gregsharp at 15:43, 6 January 2016

Gregsharp at 15:27, 6 January 2016

Gregsharp: Created page with "This page keeps track of Greg's notes on how to hook up module events __TOC__ == Motivation == * Getting things working in Slicer can be hairy * There is not always the rig..."

Gregsharp: Created page with "This page keeps track of Greg's notes on how to hook up module events TOC == Motivation == * Getting things working in Slicer can be hairy * There is not always the rig..."