Difference between revisions of "Documentation/4.0/Developers/Modules"

From Slicer Wiki
Jump to: navigation, search
m
m (Text replacement - "slicerWiki/index.php" to "wiki")
 
(5 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 24: Line 25:
 
* Recommended for fast prototyping
 
* Recommended for fast prototyping
 
* Links:
 
* Links:
−
** [http://www.slicer.org/slicerWiki/index.php/Documentation/4.0/Developers/Python_scripting|Python Scripting]
+
** [http://www.slicer.org/wiki/Documentation/4.0/Developers/Python_scripting Python Scripting]
  
 
=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
−
qSlicerModuleFactoryManager* factoryManager = app->moduleManager()->factoryManager();
 
−
factoryManager->registerFactory(new qSlicerLoadableModuleFactory);
 
−
...
 
 
* 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
−
factoryManager->addSearchPath(app->slicerHome() + "/" +  Slicer_QTSCRIPTEDMODULES_LIB_DIR + "/" );
 
−
factoryManager->addSearchPath(app->slicerHome() + "/" + Slicer_CLIMODULES_LIB_DIR + "/" );
 
−
...
 
 
* Optionally specify module names to ignore
 
* Optionally specify module names to ignore
−
For startup speed-up and memory consummation, it can be useful to not load some modules
 
−
factoryManager->setModulesToSkip(QStringList(QString("Data")));
 
−
 
 
* 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)  
−
For each file in the search paths, the factory manager asks each registered factory if they can load the file. If there is a factory that supports the file, the manager associates the factory to the file path, otherwise the file is discarded.
 
−
factoryManager->registerModules();
 
 
* Instantiate all the register modules
 
* Instantiate all the register modules
−
factoryManager->instantiateModules();
 
 
* Connect each module with the scene and the application
 
* Connect each module with the scene and the application
−
The application logic and the scene are passed to each module. The order of initialization is defined with the dependencies of the modules. If module B depends of module A, it is assured that module B is initialized/setup after A.
+
More details can be found in the [http://slicer.org/doc/html/classqSlicerAbstractModuleFactoryManager.html online doc]
−
factoryManager->loadModules();
+
 
 
==ToDo==
 
==ToDo==
 
* Transform all core modules into Loadable modules.
 
* 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)
 
** 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.
 
* 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 are in QTCl that depends on QTGUI
+
** 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
 
** Proposed architecture
 
  Base
 
  Base
Line 69: Line 59:
 
** 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.

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.

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.

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.

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.
Retrieved from "https://www.slicer.org/w/index.php?title=Documentation/4.0/Developers/Modules&oldid=61760"