Difference between revisions of "Documentation/Labs/ModulesAndEvents"
From Slicer Wiki
(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...") |
|||
Line 8: | Line 8: | ||
* There is not always the right kind of documentation for what you want to do. | * 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. | * 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 | * Scope is limited to C++ development | ||
Line 22: | Line 23: | ||
** Implement filter-type logic, which manipulates MRML nodes without need for persistent state | ** 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 | * There may be multiple logic classes associated with a single MRML node | ||
+ | |||
+ | == Widget classes == | ||
+ | |||
+ | * What is the difference between qvtkConnect and qvtkReconnect?? | ||
== MRML nodes and multithreading == | == MRML nodes and multithreading == | ||
Line 27: | Line 32: | ||
* Slicer is implemented as a single threaded process | * 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 | * Therefore, there is no need to implement transaction logic to ensure atomicity when modifying multiple MRML nodes | ||
+ | |||
+ | == 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 MRML node updates custom MRML node via logic function call (no events) | ||
+ | * custom MRML node fires Modified event (or custom event) | ||
+ | * widget logic (or widget MRML?) receives event | ||
+ | * widget logic updates widget MRML (if needed) | ||
+ | * widget logic (or widget MRML?) fires event to module widget | ||
+ | * module widget updates UI | ||
+ | ** How does this not re-fire the above loop? |
Revision as of 15:27, 6 January 2016
Home < Documentation < Labs < ModulesAndEventsThis page keeps track of Greg's notes on how to hook up module events
Contents
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.
- 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
Widget classes
- What is the difference between qvtkConnect and qvtkReconnect??
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 (?)
- signal from UI element received by module widget
- module widget updates module MRML node via module logic function call (no events)
- module MRML node updates custom MRML node via logic function call (no events)
- custom MRML node fires Modified event (or custom event)
- widget logic (or widget MRML?) receives event
- widget logic updates widget MRML (if needed)
- widget logic (or widget MRML?) fires event to module widget
- module widget updates UI
- How does this not re-fire the above loop?