Documentation/4.0/Developers/Modules
Slicer 4 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 a difference as they all share the look&feel. The choice for a given type of module is usually based on the type of inputs/parameters for a given module.
Contents
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. The recommended way to write your own CLI is to copy an existing module.
- Shared lib or executable
- GUI automatically generated
- 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
- 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
- Links:
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.