Documentation/4.1/Developers/Modules

Slicer supports 3 types of modules. While the developer has to choose between one of the 3 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.

Command Line Interface (CLI)

CLIs are standalone executables with a limited input/output arguments complexity (simple argument types, no user interactions...). They are typically implemented using ITK.

• Shared lib or executable
• GUI automatically generated
• Where to start ?
  • Recommended: Use the module wizard and look at existing existing modules
• Links:
  • Slicer3 execution model (Slicer4 is very similar)
  • CLI in Slicer4 (presentation of 2012 NAMIC AHM)

Loadable Modules

Loadable modules are C++ plugins that are built against Slicer. They define custom GUIs for their specific behavior as they have full control over the application.

• C++ shared library
• Full control over the GUI (Qt) and Slicer internals (MRML, logics, display managers...)
• Optimized for heavy computations
• Where to start ?
  • Recommended: Use the module wizard and look at existing existing modules
• Links:
  • Loadable modules (presentation of 2012 NAMIC AHM)
  • How to write a loadable module

Scripted Modules

Scripted modules are written in Python and typically but not necessarily use the high level API of Slicer and toolkits.

• Python Console
• Full access to the API: VTK, ITK, MRML, Qt and Slicer are fully wrapped
• Recommended for fast prototyping
• Where to start ?
  • Recommended: Use module wizard and look at existing existing modules
• Links:
  • Scripting
  • See the Python Scripting Tutorial

Module Factory

Loading modules into slicer happens in multiple steps:

• module factories must be registered into the factory manager
• directories where the modules to load are located must be passed to the factory manager
• Optionally specify module names to ignore
• scan the directories and test which file is a module and register it (not instantiated yet)
• Instantiate all the register modules
• Connect each module with the scene and the application

More details can be found in the online doc

ToDo

• Transform all core modules into Loadable modules.
  • the factory manager only support file based modules, core modules are not file based (linked into the core factory itself)
• Move factory registration in qSlicerApplication (or a general application library) to support module discovery/loading without needing to instantiate Slicer.
  • Currently can't be moved into qSlicerApplication as the CLI factories that are in QTCLI depend on QTGUI
  • QtTesting is also limited with the QTCLI dependency on QtGUI (->qSlicerApplication would need to access QtTesting code from QtCli)
  • Proposed architecture

Base
  Application -> classes that are useful to build an application (mix of qSlicerCoreApplication, qSlicerApplication, Main.cxx...)
  Core -> formally QtCore
  Modules -> contains the factories and module specific code
     Loadable
     CLI
     Scripted
  Scripted -> all that is python specific
     Cxx
     Python
  Widgets -> formally QtGUI

• Add category hierarchy in the Settings module panel
• Register factory settings/command-options(e.g. disable-loadable-modules) when registering module factories
  • To have the settings panel be generic but have the code proper of each registered factory somewhere else
• Add mechanism for modules to register dialogs (toolbars that open dialogs), e.g. the sceneview module needs to register the sceneView dialog into an icon.
• Ignore modules from the launcher command line.
• cloning" of module panels at run time. See "here and here