Difference between revisions of "Documentation/4.0/Developers/Modules"
m (→ToDo) |
|||
Line 28: | Line 28: | ||
=Module Factory= | =Module Factory= | ||
Loading modules into slicer happens in multiple steps: | Loading modules into slicer happens in multiple steps: | ||
− | *module factories must be registered into the factory manager | + | *module factories must be registered into the factory manager |
− | |||
− | |||
− | |||
* directories where the modules to load are located must be passed to the factory manager | * directories where the modules to load are located must be passed to the factory manager | ||
− | |||
− | |||
− | |||
* Optionally specify module names to ignore | * Optionally specify module names to ignore | ||
− | |||
− | |||
− | |||
* scan the directories and test which file is a module and register it (not instantiated yet) | * scan the directories and test which file is a module and register it (not instantiated yet) | ||
− | |||
− | |||
* Instantiate all the register modules | * Instantiate all the register modules | ||
− | |||
* Connect each module with the scene and the application | * 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== | ==ToDo== | ||
* Transform all core modules into Loadable modules. | * Transform all core modules into Loadable modules. | ||
Line 69: | Line 57: | ||
** To have the settings panel be generic but have the code proper of each registered factory somewhere else | ** 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. | * 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. |
Revision as of 20:16, 22 February 2012
Home < Documentation < 4.0 < Developers < ModulesSlicer 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
- 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.