Difference between revisions of "Projects:ARRA:SlicerEM:Developer:WorkflowManager"
From NAMIC Wiki
Line 16: | Line 16: | ||
* Core functionality in KWWidgets state machines that would be replicated for a "straight-forward" conversion: | * Core functionality in KWWidgets state machines that would be replicated for a "straight-forward" conversion: | ||
− | + | {| border="1" | |
+ | |- bgcolor="#abcdef" | ||
+ | ! KWWidgets functionality !! Present in Qt? | ||
+ | |- | ||
+ | | States have enter/leave events || ??? | ||
+ | |- | ||
+ | | Transitions have start/stop events || ??? | ||
+ | |- | ||
+ | | State events are processed before transition events || ??? | ||
+ | |- | ||
+ | | Clusters of states || ??? | ||
+ | |- | ||
+ | | Can save transition history || ??? | ||
+ | |- | ||
+ | | Can define custom inputs || ??? | ||
+ | |- | ||
+ | | || ??? | ||
+ | |} | ||
== Transition from KWWidgets workflow manager to a workflow manager using Qt's state machines == | == Transition from KWWidgets workflow manager to a workflow manager using Qt's state machines == | ||
Line 27: | Line 44: | ||
== GUI implementation in Qt == | == GUI implementation in Qt == | ||
− | * [http://doc.trolltech.com/4.6/qstackedwidget.html qStackedWidget] and/or [http://doc.trolltech.com/4.6/qtablewidget.html qTabWidget] | + | * [http://doc.trolltech.com/4.6/qstackedwidget.html qStackedWidget] (and/or [http://doc.trolltech.com/4.6/qtablewidget.html qTabWidget]) |
− | * plus [http://doc.trolltech.com/4.6/qdialog.html qDialog] | + | * simply connect signal to the stacked widget's setCurrentIndex(int) slot to change the displayed widget |
+ | * plus [http://doc.trolltech.com/4.6/qdialog.html qDialog] as well | ||
+ | * in Qt Designer - could have one .ui file for the entire stacked widget, or, for widgets representing complicated steps, could have a separate .ui | ||
− | == | + | == Concepts to keep in mind == |
* Undo / redo and forward/back transitions | * Undo / redo and forward/back transitions | ||
* Branching workflows / skipped states | * Branching workflows / skipped states | ||
+ | * Design / output of state machines in a graphical format | ||
+ | * Logging state transitions, user actions, inputs and results thoughout | ||
== Additional ideas and questions == | == Additional ideas and questions == | ||
− | + | * Image processing throughout - need to deal with failures in image processing that are unrelated to the GUI | |
− | ** | + | * Would be a good idea to make the workflow manager as general as possible for CTK - ex. use for management of IGT workflows in Slicer, where you may be coordinating several modules (ex. calibration module -> registration module -> tracking module), and may need to notify other components of current state (ex. over OpenIGTLink) (ex see [http://hdl.handle.net/10380/3075 this IJ paper]) |
+ | * May even like to provide the option to save the MRML tree at the end of each step (to restore state if there is a crash, for example |
Revision as of 18:34, 14 July 2010
Home < Projects:ARRA:SlicerEM:Developer:WorkflowManagerContents
- 1 Summary
- 2 Previous workflow manager implementation in KWWidgets
- 3 Transition from KWWidgets state machines to Qt state machines
- 4 Transition from KWWidgets workflow manager to a workflow manager using Qt's state machines
- 5 GUI implementation in Qt
- 6 Concepts to keep in mind
- 7 Additional ideas and questions
Summary
- EMSegmenter has a fairly complicated workflow
- Need a mechanism to validate user input and transition appropriately between steps of the workflow
- Should be dependent on Qt only (and not VTK)
- Current plan (subject to change) = use Qt's state machine implementation, with our own workflow manager on top
Previous workflow manager implementation in KWWidgets
- Please see the documentation here, as it is already well described
Uses:
- KWWidgets state machines - incorporates states (ex. user interaction within a workflow step, validation of the user input within a workflow step), transitions (between states), and inputs (pushed onto a queue to trigger transitions)
- KWWidgets wizard workflow - provides additional functionality to manage workflow using a state machine (ex. bundles pairs of user interaction and validation states into a workflow "step", handles a navigation stack of steps encountered along the way that triggers updates of widgets and/or dialogs)
Transition from KWWidgets state machines to Qt state machines
- Core functionality in KWWidgets state machines that would be replicated for a "straight-forward" conversion:
KWWidgets functionality | Present in Qt? |
---|---|
States have enter/leave events | ??? |
Transitions have start/stop events | ??? |
State events are processed before transition events | ??? |
Clusters of states | ??? |
Can save transition history | ??? |
Can define custom inputs | ??? |
??? |
Transition from KWWidgets workflow manager to a workflow manager using Qt's state machines
- Will likely need to reimplement the four KWWidget workflow manager classes:
- vtkKWWizardStep: a wizard step
- vtkKWWizardWorkflow : a wizard workflow
- vtkKWWizardWidget : a wizard widget, embedding UI (buttons) and a wizard workflow engine
- vtkKWWizardDialog : a wizard dialog, embedding a wizard widget in a toplevel/dialog window.
GUI implementation in Qt
- qStackedWidget (and/or qTabWidget)
- simply connect signal to the stacked widget's setCurrentIndex(int) slot to change the displayed widget
- plus qDialog as well
- in Qt Designer - could have one .ui file for the entire stacked widget, or, for widgets representing complicated steps, could have a separate .ui
Concepts to keep in mind
- Undo / redo and forward/back transitions
- Branching workflows / skipped states
- Design / output of state machines in a graphical format
- Logging state transitions, user actions, inputs and results thoughout
Additional ideas and questions
- Image processing throughout - need to deal with failures in image processing that are unrelated to the GUI
- Would be a good idea to make the workflow manager as general as possible for CTK - ex. use for management of IGT workflows in Slicer, where you may be coordinating several modules (ex. calibration module -> registration module -> tracking module), and may need to notify other components of current state (ex. over OpenIGTLink) (ex see this IJ paper)
- May even like to provide the option to save the MRML tree at the end of each step (to restore state if there is a crash, for example