Difference between revisions of "Documentation/4.0/Developers/Modules"
From Slicer Wiki
m (Text replacement - "slicerWiki/index.php" to "wiki") |
|||
| (11 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| + | <noinclude>{{documentation/versioncheck}}</noinclude> | ||
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. | 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. | ||
= Command Line Interface (CLI) = | = Command Line Interface (CLI) = | ||
| Line 6: | Line 7: | ||
* GUI automatically generated | * GUI automatically generated | ||
* Links: | * Links: | ||
| − | ** [http://www. | + | ** [[Slicer3:Execution_Model_Documentation|Slicer3 execution model]] (Slicer4 is very similar) |
| + | ** [http://www.na-mic.org/Wiki/index.php/File:Slicer4_CLI.ppt CLI in Slicer4] (presentation of 2012 NAMIC AHM) | ||
= Loadable Modules = | = Loadable Modules = | ||
| Line 14: | Line 16: | ||
* Optimized for heavy computations | * Optimized for heavy computations | ||
* Links: | * Links: | ||
| − | **[http://www. | + | **[http://www.na-mic.org/Wiki/index.php/File:LoadableModules.pptx Loadable modules] (presentation of 2012 NAMIC AHM) |
| + | **[[Documentation/4.0/Developers/Tutorials/ModuleWriting|How to write a loadable module]] | ||
= Scripted Modules = | = Scripted Modules = | ||
| Line 22: | Line 25: | ||
* Recommended for fast prototyping | * Recommended for fast prototyping | ||
* Links: | * Links: | ||
| − | ** [http://www.slicer.org/ | + | ** [http://www.slicer.org/wiki/Documentation/4.0/Developers/Python_scripting Python Scripting] |
| + | |||
| + | =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 [http://slicer.org/doc/html/classqSlicerAbstractModuleFactoryManager.html 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. | ||
Latest revision as of 17:05, 21 November 2019
Home < Documentation < 4.0 < Developers < Modules
|
For the latest Slicer documentation, visit the read-the-docs. |
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.
