Basic questions on CLI modules vs Scripted Modules

Development
1

I’m writing a basic ‘programming in Slicer’ tutorial for my lab (which borrows heavily from existing documentation and the Perk Lab bootcamp slides).

Something that wasn’t been clear to me: When would you write a CLI module vs. a scritped module? I’ve only written scripted modules, and from what I understand on https://www.slicer.org/wiki/Documentation/Nightly/Developers/Modules#Command_Line_Interface_.28CLI.29 it’s always better to write a scripted module for increased flexibility? If this is true, when would you write a CLI module?

2

CLI module has a number of restrictions, such as:

  • GUI is static, with a limited set of widgets, generated from the XML descriptor file
  • the module does not have access to the full scene (only to the selected input nodes)
  • only runs when the user clicks apply (or an input node is changed and auto-update is enabled)
  • always performs all computations from scratch

However, these limitations allow faster, simpler development and asynchronous execution (application GUI is not blocked).

CLI modules can be also created from any existing command-line applications or Python scripts - by simply creating an XML file that describes command-line arguments.

1 Like
3

The original motivation for CLI modules (which is still valid) was to allow people to write or adapt traditional C or C++ programs so that they would have a GUI. So they only rely on having a main(argc,argv) entry point with data access via files and progress reporting to stdout and errors reported via stderr and return codes. A lot of algorithms, like in ITK, are not interactive anyway and by writing them as CLI modules you can reuse the executable in batch jobs or other environments without having Slicer as a dependency.

1 Like
4

Thanks, this is very helpful!

I’ll be sure to tell my lab how to use this forum as a key Slicer resource :stuck_out_tongue:

1 Like