AHM 2006:ProjectsSlicerModuleTransition

Features

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.