Difference between revisions of "Documentation/Labs/CLIInfrastructureCleanupAndRefactoring"
From Slicer Wiki
(Created page with '= Motivation = See = Features = * TODO = Design and implementation = * TODO = Slicer core changes = * TODO = Future features = * TODO = Issues = * TODO = Topics to discuss…') |
|||
| Line 1: | Line 1: | ||
= Motivation = | = Motivation = | ||
| − | + | The current [https://github.com/Slicer/Slicer/blob/master/Base/QTCLI/vtkSlicerCLIModuleLogic.h CLI logic] and [https://github.com/Slicer/Slicer/tree/master/Base/QTCLI associated GUI classes] consists of complex set of hardcoded check to handle different type of MRML node. It is nearly impossible for extension to extend the existing mechanism and support other type of input and output for new [[Documentation/Nightly/Developers/Modules#Command_Line_Interface_.28CLI.29|CLI modules]]. For core module extending the infrastructure, the current approach is to copy the MRML node into MRML/Core directory. | |
| + | |||
| + | The current approach does not scale and is becoming more and more complex to manage and maintain. | ||
| + | |||
| + | The plan would be to generalize the infrastructure so that: | ||
| + | * module can easily register new type of CLI output and input | ||
| + | * module UI generation leverage CTK CLI infrastructure | ||
| + | * | ||
= Features = | = Features = | ||
| Line 9: | Line 16: | ||
= Slicer core changes = | = Slicer core changes = | ||
| − | * | + | * Some preliminary work (in both CTK and Slicer) has been done to reuse the CTK CLI infrastructure. It would have to be rebased against a current master: |
| + | ** https://github.com/jcfr/Slicer/tree/ctk-commandline-integration | ||
| + | ** https://github.com/jcfr/CTK/tree/279-tweak-cmdlinemodule-library-for-slicer-integration and [https://github.com/commontk/CTK/issues/279 GH#279] | ||
= Future features = | = Future features = | ||
Revision as of 17:48, 17 July 2015
Home < Documentation < Labs < CLIInfrastructureCleanupAndRefactoringContents
Motivation
The current CLI logic and associated GUI classes consists of complex set of hardcoded check to handle different type of MRML node. It is nearly impossible for extension to extend the existing mechanism and support other type of input and output for new CLI modules. For core module extending the infrastructure, the current approach is to copy the MRML node into MRML/Core directory.
The current approach does not scale and is becoming more and more complex to manage and maintain.
The plan would be to generalize the infrastructure so that:
- module can easily register new type of CLI output and input
- module UI generation leverage CTK CLI infrastructure
Features
- TODO
Design and implementation
- TODO
Slicer core changes
- Some preliminary work (in both CTK and Slicer) has been done to reuse the CTK CLI infrastructure. It would have to be rebased against a current master:
Future features
- TODO
Issues
- TODO
Topics to discuss
- TODO
Notes
- TODO
