Slicer3:Extensions

Introduction

• 3D Slicer now supports plug-ins which we call extensions. Extensions are available from an extension server. This allows end-users to select the extensions useful to them, without having to download the entire extension archive.
• The process of creating an extension is as follows:
  • create a module (command line, scripted or loadable)
  • make sure that it compiles on all supported platforms
  • create an s3ext file pointing to the source code
  • talk to the slicer team to integrate it into the nightly build process.

• We are using NITRC as the primary repository for contributed extensions, however any subversion or cvs repository can be used. As a general rule, the slicer team does not test the extensions. Use them at your own risk.
• Look at the Associations section of the slicer project page on NITRC for other software that can be used to extend slicer. here to see a listing of Slicer 3 extensions on NITRC.
• Extensions are compiled as part of the nightly build. In order to have your extension compiled nightly and made available to end users, please contact the Slicer team (provide a .s3ext file as described below).
• In order to start your own extension, you can look at the sources for these examples and copy one that looks similar:

http://viewvc.slicer.org/viewcvs.cgi/trunk/Extensions/

• Several example modules are hosted on the nitrc.org site and can be used as a template. These include the major types of loadable and scripted modules.
• Here is a link to user documentation on extensions.

This work was sponsored in part by the collaboration between NA-MIC and NITRC.

Module Types

The following types of modules are available:

• command line modules - executables that follow the Slicer Execution Model
• scripted modules - Tcl or Python scripts that implement the callbacks of the Module GUI API or the Slicer Execution Model
• loadable modules - shared libraries that implement the Module GUI API and can call/extend the C++ API directly (can provide subclasses of vtk/itk/kwwidgets/MRML/slicer code and other libraries).

All three module types are dynamically discovered by slicer at run time.

See Jim Miller's presentation from the NA-MIC 2010 All Hands Meeting and Steve Pieper's presentation from the 2010 Summer Project Week.

For generic module templates, see the examples on nitrc.org. For a fully fleshed out working example, see the Vascular Modeling Toolkit (vtmk) project which includes a loadable module of vtk/itk code along with several python scripted modules that implement the kwwidgets-based user interface.

Versions

Version 3.6

Please refer to the status page for extensions for slicer version 3.6.

Support in Slicer 3.5

Support in Slicer 3.4

Development in the slicer3 trunk through early August 2009 has led to a version that works well and is being migrated to the 3.4 release branch for use in patch version 3.4.1. Fixes from the following files are being migrated:

• Applications/GUI/Slicer3.{cxx,xml}
• Base/GUI/vtkSlicerApplication.{h,cxx}
• Base/GUI/vtkSlicerApplicationSettingsInterface.{h,cxx}

• Base/GUI/vtkSlicerModulesWizardDialog.{h,cxx}
• Base/GUI/vtkSlicerModulesStep.{h,cxx}
• Base/GUI/vtkSlicerModulesConfigurationStep.{h,cxx}

• Scripts/extend.tcl
• launch.tcl.in

FOR DEVELOPERS

Extensions must follow the appropriate architecture and must meet minimum documentation requirements for them to be made available to end users. See Slicer3:Loadable_Modules for an example of how to make GUI and GUI-less Loadable Modules. Command Line and Scripted Modules will also work with this framework.

You can choose the version of your code that you want to make available to end users by having the Subversion repository URL in the s3ext script point to either the trunk of your code base or to a stable branch.

Once your code compiles successfully on all of the standard platforms (win32, OsX, linux 32 and linux 64) you can choose to talk to Katie Hayes to make your extension available through the extension wizard in Slicer3.

To enable your Command Line, Scripted, or Loadable module, add an "s3ext" script to the Slicer3/Extensions directory of the Slicer3 source repository.

 Slicer3/Extensions/MyModule.s3ext

Building Locally

The source code manager parameter in the .s3ext file will point to a repository where a top level CMakeLists.txt file is checked out as well as your source code. The CMakeLists.txt file can use External_Project CMake command to check out additional code from other repositories if necessary. As you're developing your extension module, you can build it by running the extend.tcl script:

 cd Slicer3/Scripts
 ./extend.tcl MyModule

On Windows, make sure that you set the project name in the top level CMakeLists.txt file to MyModule as otherwise extend.tcl will not find the MyModule.sln file to build.

The extend script will create

 Slicer3-ext/MyModule

and check out your code into that directory. It will then delete any old versions of these directories and create them fresh:

 Slicer3-ext/MyModule-build
 Slicer3-ext/MyModule-install

At the top level you can use ${CMAKE_CURRENT_BINARY_DIR} or ${MyModule_BINARY_DIR} to refer to the MyModule-build directory and ${CMAKE_INSTALL_PREFIX} to refer to the MyModule-install/lib/Slicer3 directory during the install step. Files placed in the ${CMAKE_INSTALL_PREFIX} directory will be zipped up by the extend.tcl script and uploaded to the extension server under the current svn revision number of Slicer3.

Test inegration of your extension by downloading and installing your module from the extension server. The archive will be expanded in the designated extensions installation directory, so it must contain everything needed to run your module.

For testing a command line module, at a minimum use the CMake command add_test to test the --xml argument:

 add_test(MyModule_TEST_XML ${CMAKE_INSTALL_PREFIX}/lib/Slicer3/MyModule --xml)

Run the test with the following:

 cd Slicer3-ext/MyModule-build
 ctest -R MyModule_TEST_XML -VV

Sample .s3ext file

Sample .s3ext file for a python module:

PythonSampleScriptedModule.s3ext

#
# first token of each non-comment line is the keyword and the rest of the line 
# (including spaces) is the value.
# - the value can be blank
#

# scm is source code manager (i.e. svn)
scm       svn
svnpath   https://www.nitrc.org/svn/slicer3examples/trunk/Slicer3ExampleModules/Scripted/PythonSampleScriptedModule
svnusername slicerbot
svnpassword slicer

# list dependencies 
# - these should be names of other modules that have .s3ext files 
# - the dependencies will be built first
depends ScriptedModule

# homepage
homepage  http://www.slicer.org

# match category in the xml description of the module (where it shows up in Modules menu)
category  Developer Tools

# give people an idea what to expect from this code 
# - is it just a test or something you stand beind?
status    Beta

# One line description of what the module does
description This is an example of an extension module written in python