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