View source for 2013 Summer Project Week:CLI modules in MeVisLab

__NOTOC__
<gallery>
Image:PW-MIT2013.png|[[2013_Summer_Project_Week#Projects|Projects List]]
Image:CLI module list in MeVisLab.png|MeVisLab module search result listing imported CLI modules
Image:CLI in action in MeVisLab.png|CLI module connected with other MeVisLab modules in a network
Image:BRAINSFit in MeVisLab.png|Example of a more complex GUI panel
Image:CLI debug window in MeVisLab.png|The MeVisLab module's context menu allows to debug CLI execution
</gallery>

==Key Investigators==
* Fraunhofer MEVIS: Hans Meine
* Steve Pieper, Isomics
* Jean-Christophe Fillion-Robin, Kitware
* Jim Miller, GE

<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Objective</h3>
<p>Integrate CLI modules in MeVisLab, much like it [http://www.commontk.org/index.php/Documentation/CLI_In_Context was done before with NiftyView and MITK], for instance.</p>
It shall be as convenient as possible to use CLI modules in MeVisLab, i.e. the integration should strive to achieve the possibility to seamlessly connect CLI modules with built-in MeVisLab modules in a network.
</div>

<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Approach, Plan</h3>

* In order to use CTK's convenience classes for accessing CLI modules, we will have to integrate CTK into our MeVisLab ThirdParty repository and our (qmake-based) build system.  It could become interesting because of CTK's dependencies, which must be pulled from our ThirdParty repository as well, if the (patched) versions are not close enough (yet).
* For integration of the generic CTK CLI support to a platform specific tool, the bulk data types parameters (volumes, models, transforms...) need to be mapped to platform-specific GUI elements and data management techniques (probably files to start).  This has been started for Slicer and we can review how it could work in MeVisLab.
* For seamless integration (see objective), it will be necessary not to use standard Qt widgets, but to have widgets with MeVisLab field connectors. Furthermore, image inputs and outputs shall be mapped to corresponding module inputs / outputs in MeVisLab. The question is whether it is easier to use the CTK support for custom widgets, or whether the CLI XML description should be mapped to a module description in MDL (MeVisLab definition language) instead. (MeVisLab does  not currently offer dynamic creation of fields, i.e. parameters, inputs or outputs.)

</div>

<div style="width: 40%; float: left;">

<h3>Progress</h3>
Working:
*Import of CLI modules into the MeVisLab module database
*Image inputs (optional and required) and outputs
*Parameters with different types (bool, int, float, enum, point etc.)
*Ranges (min/max) and steps (+/- spinners in GUI)
*Tooltips on parameters, inputs/outputs, the module itself and group boxes
*Working "Show Help" in the module's context menu(!)
*Heuristics for nice GUI layouts ("advanced" tabs etc.)
*CLI execution
**Optional: Automatic running on changed inputs/parameters
**Error reporting (exitcodes, UNIX signals)
**Debugging window (command, stdout, stderr)
*Simple output parameters (readonly values reported back via --returnparameterfile)

Not finished yet:
*XMarkerLists as input (for <point multiple=true>)
*Curve output (<measurement>)
*Regions (currently broken in Slicer)
*Coordinate system conversion (missing in Slicer, too)
*respect given fileExtensions

Unfinished, difficult:
*Transforms (at least, linear transforms could be converted to Matrix fields)
</div>
</div>

==Notes, Thoughts, Design Decisions==

*The MeVisLab module name will be the basename of the CLI executable, because module names are usually camelcase names without spaces, but the CLI description's title tag will contain spaces.
*Many properties of the CLI module have no direct correspondence:
**description maps to comment
**contributor roughly maps to author (the latter has a strict structure with comma-separation, though)
**title & version are put into the comment for now, too
**documentation-url (which does not always contain a URL in practice!) is not mapped; in MeVisLab, we would need to reference a documentation file (HTML)
**category is similar to genre (or group), but cannot be mapped – maybe as keywords?
**acknowledgments and license are not mapped, either -> maybe add to comment, too?

In Slicer, in order to debug CLI execution, it makes sense to change the preferences to 

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as a (please select the appropriate options by noting YES against them below)

#ITK Module
#Slicer Module
##Built-in
##Extension -- commandline
##Extension -- loadable
#YES – Other (Please specify) → a MeVisLab module (currently on [https://github.com/hmeine/MeVisLab-CLI GitHub as "MeVisLab-CLI"], will be bundled with MeVisLab in the future.

==References==
*http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation
*http://www.commontk.org/index.php/Documentation/Command_Line_Interface
*http://www.commontk.org/index.php/Documentation/CLI_In_Context
* Previous effort to catalog XML support http://www.na-mic.org/Wiki/index.php/2011_Winter_Project_Week:SEMXMLSchema
* Slicer code for CLI execution: https://github.com/Slicer/Slicer/blob/master/Base/QTCLI/vtkSlicerCLIModuleLogic.cxx