Difference between revisions of "AHM 2006:ProjectsSlicerModuleTransition"
m (Update from Wiki) |
m (Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/") |
||
| (One intermediate revision by one other user not shown) | |||
| Line 47: | Line 47: | ||
Yes, clean out the base so that it's only what's required in the core. | Yes, clean out the base so that it's only what's required in the core. | ||
| − | Describe the current module GUIs via an XML file, using templates from the [ | + | Describe the current module GUIs via an XML file, using templates from the [https://www.slicer.org/wiki/Slicer3:Execution_Model Slicer3:Execution_Model]. |
Latest revision as of 18:01, 10 July 2017
Home < AHM 2006:ProjectsSlicerModuleTransitionFeatures
This project is concerned with the transition of some representative modules from the Slicer 2.x format to Slicer 3.x. Once these have been translated, the remainder will be (theoretically) easy.
The modules to be transitioned first are:
- vtkEMLocalSegment
- vtkEMAtlasBrainClassifier
- vtkIbrowser
- vtkFMRIEngine
- vtkDTMRI
An automated transition script should do the majority of the transition but some manual intervention will be necessary.
Outstanding Questions
The Slicer Base must be defined first in order to drive the translation of the individual modules, as well as supporting their dependencies on the Base code.
Do we keep the same directory structure?
How do we compile individual modules?
How do we handle dynamic loading?
How do we handle inter-module compilation dependencies?
How do we handle inter-module run time dependencies?
Do we transition old modules from Base/tcl/tcl-modules into independent modules?
How do we describe the current GUI so that it can be transitioned into the new framework?
Strawman Answers
As soon as an alpha model of the base is defined, begin preliminary transition.
Yes, don't change the directory structure.
Use CMake with flags to build each module.
Stay with the package require construction to load modules. is there something more elegant?
Rely on CMake for inter-module compilation dependencies.
Use an in memory MRML tree for run time dependencies?
Yes, clean out the base so that it's only what's required in the core.
Describe the current module GUIs via an XML file, using templates from the Slicer3:Execution_Model.
