Difference between revisions of "Documentation/Labs/CLIInfrastructureCleanupAndRefactoring"

From Slicer Wiki
Jump to: navigation, search
 
Line 3: Line 3:
  
 
The current approach does not scale and is becoming more and more complex to manage and maintain:
 
The current approach does not scale and is becoming more and more complex to manage and maintain:
* https://github.com/naucoin/Slicer/commit/3e6845ee1fa13212b97f0b4155c6f6c2c81d04c2#commitcomment-12229331
+
* [https://github.com/naucoin/Slicer/commit/3e6845ee1fa13212b97f0b4155c6f6c2c81d04c2#commitcomment-12229331 Andras comment of July 17th 2015]
  
 
The plan would be to generalize the infrastructure so that:
 
The plan would be to generalize the infrastructure so that:
 
* module can easily register new type of CLI output and input
 
* module can easily register new type of CLI output and input
 
* module UI generation leverage CTK CLI infrastructure
 
* module UI generation leverage CTK CLI infrastructure
*  
+
*
  
 
= Features =
 
= Features =

Latest revision as of 17:50, 17 July 2015

Home < Documentation < Labs < CLIInfrastructureCleanupAndRefactoring

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

Future features

  • TODO

Issues

  • TODO

Topics to discuss

  • TODO

Notes

  • TODO