Documentation/4.2/Developers/StartHere
For the latest Slicer documentation, visit the read-the-docs. |
3D Slicer is a free open source extensible software application for medical image computing and visualization. Mainly written in C++ and based on the NA-MIC kit, 3D Slicer relies on a variety of libraries: VTK, ITK, CTK, CMake, Qt and Python.
To ensure the stability of the application, relying on a robust software process, the source code is compiled and tested on a daily basis on a variety of platform configurations. The testing results are summarized and reported using a web-based centralized CDash dashboard. Developers of 3D Slicer can also report issues on the open mailing list or using the web-based bug tracking system.
3D Slicer consists of both a lean application core and modules offering specific functionality. The core implements the user interface, provides support for data input/output (IO) and visualization and also exposes developer interfaces that support extension of the application with new modules.
Multiple types of modules are supported: CLI, Loadable module, Scripted module and Editor effect. While the developer has to choose between one of these types to implement its module, the end user won't notice the difference as they all share the same look & feel. The choice for a given type of module is usually based on the type of inputs/parameters for a given module.
These modules can be either built-in or installed on demand via the extensions manager.
Contents
Overview
- Slicer has a plug-in architecture. There are different types of plug-ins available. We recommend to begin development work in Slicer by programming a so-called command line interface plug-in also known as CLI plug-in.
Typically, a development project will begin with a prototype functionality. Depending on the nature of the algorithm, you might consider implementing it as a ITK function, and submit to the Insight journal. An alternate infrastructure for adding new functionality is through programming in Python. By turning this functionality into a CLI plug-in, it becomes possible to use Slicer as a platform for the functionality. Slicer will provide I/O and visualization capabilities, you will provide the new algorithm. Finally, Slicer has infrastructure and support for sharing the functionality with your friends and the world. We call them Extensions. There is a process which will allow you to add your extension to the Slicer extension catalog.
- I would like to develop an extension for 3D Slicer
- I program in Python ==> Go here (this is the fastest way to get going)
- I program in C++ ==> Go here
- I would like to use CLI modules to develop processing pipelines ==> Go here
- I have a CLI module and would like to share it with the world. ==> Go here
ToDo List for joining the Slicer Developer Community
Sign-up on the developers mailing list
Register on the issue tracker
Sign-up on github and setup Git
Fork Slicer repository: https://github.com/Slicer/Slicer
Read the Slicer Style Guidelines so that we all understand each other :)
Develop a module and create an extension
- Build Slicer application
- Learn about the different type of modules
- Create
- Read documentation guidelines
- Build modules outside of Slicer source tree.
Hack, hack, hack :)
- Bundle module(s) into a Slicer extension
- Build, test, package and distribute extensions
Contribute a patch
The following instructions describes the recommended workflow to contribute patch to Slicer code base.
It is also assumed you followed the New community member checklist and have a clone of https://github.com/Slicer/Slicer/.
If not already done, make sure to read the Slicer Coding Style Guide :-)
- 2. Make sure your fork has a git remote. Replace
jcfr
with your git login.
git remote add jcfr git@github.com:jcfr/Slicer.git
- 3. Create a topic named
<issuer_number>-a-descriptive-topic-name
. For example:
git checkout -b 1906-uninstall-extensions-on-restart
- 4. Add a note to the issue with a link pointing to your topic. For example, see note 1906#c4578
- 5. Send an email on the slicer-developers list pointing to the reported bug. Title of the email should start with
[BUG <IssueNumber>] Title of the bug - <category>
Mantis workflow
The following diagram illustrates Slicer issue workflow:
Source: Adapted from http://www.warelab.org/blog/?p=24