View Issue Details

IDProjectCategoryView StatusLast Update
0001602Slicer4Core: Documentation and Wikipublic2014-05-12 11:52
ReporterfedorovAssigned Tojcfr 
PrioritynormalSeverityminorReproducibilityhave not tried
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0001602: "tag" to identify CLI executables
Description

On Thu, Dec 1, 2011 at 10:30 PM, Andriy Fedorov <fedorov@bwh.harvard.edu> wrote:

Hi,

Today at RSNA we had several people asking about instructions for
batch mode execution of Slicer modules. I think we need to have this
documented on the wiki.

I initially though this will be trivial thing to do, but as I thought
more, there are several issues that are not straightforward:

* how can the user know which modules in Slicer are suitable for
command-line execution? Should we use CLI "tag" in the documentation
to mark them, and provide the executable name?
TagsNo tags attached.

Relationships

related to 0001522 closedmhalle Make sure GetData special page does NOT pre-append two extra empty lines 
related to 0003474 closedjcfr Consolidate list of modules. 

Activities

fedorov

fedorov

2012-01-23 08:52

developer   ~0003519

related to this, it might be helpful to have "tags" to organize other modules, not only CLIs.

For example, Editor is a "Core" module, but also it is a "Segmentation" module.

finetjul

finetjul

2012-01-23 19:59

administrator   ~0003521

I think there are 2 separate issues:

  • tag (rename to 'type' ?): define the type of a module. You can currently cast the module into qSlicerCLIModule and ask for its moduleType(). There have been already some discussions about exposing the type of a module at a more low level (qSlicerAbstractCoreModule). For now, an easy way to know the type of a module is to look at its class type (module->metaObject()->className()). I'm not sure how and where we want to present the type information to the user; just adding a line in the "help" ?.
  • category: the editor module part of Core and Segmentation should be handled by QStringList qSlicerAbstractCoreModule::categories. Right now, only QString qSlicerAbstractCoreModule::category exist; it should be renamed to support more than one category. Besides making sure the renaming is done everywhere, the only place to change to support more than one category is in qSlicerModulesMenu.cxx (it's a line change: foreach(QString category, module.categories() at line 386)
fedorov

fedorov

2012-01-24 17:21

developer   ~0003524

By saying "tag", I wanted to emphasize that each module can have multiple "tags". I like "categories" call -- but this is just a different name, right? Category is fine, I guess "CLI" can be one of the categories in one of the taxonomies for the modules. does it make sense to add "CLI" as a category?

About your suggestions to query class name, this is an option, but keep in mind that users who need to know this may not be programmers. These are people who just want to quickly script pipelines (not necessarily with Nipype). IMHO, as long as we have a documentation, and it is not overwhelming, it should be ok to use any reasonable approach.

finetjul

finetjul

2012-01-25 10:37

administrator   ~0003526

Multiple categories is supported in r19133.

jcfr

jcfr

2012-01-25 12:23

administrator   ~0003535

A very short term solution would be to manually categorised every module.
=> Not scalable, error will be introduced, high maintenance

Solving 0001522 would help, a central location where information associated with a module could be created. It means, the categories associated with each module could be centralised in one document available on the wiki.

Ultimately, since the category (CLI, Lodable, scripted) is represented by the location of the source within slicer repository .. we could think of extracting this "category" from the path. This could work is we assume that extension will also respect that naming scheme ... not sure if that would be the case. Indeed, the example of simple git repo containing one CLI doesn;t allow to do so.

It means the solution will be a "mix" of the following:
The centralise location available on the wiki will allow to specify if a module if within Slicer source or not. If in Slicer source, the category would be automatically extracted from the path. If an extension, it would have to be specified. I believe this approach would be scalable and will minimise redundancy.

Again .. issue 0001522 is the show stopper :(

finetjul

finetjul

2012-01-25 12:32

administrator   ~0003536

To make sure we all talk of the same:
category = Segmentation, Diffusion, Core, Filtering...
tags = type = CLI, loadable, scripted, (executable CLI, loadable CLI, scripted executable CLI, extension CLI, local CLI ...)

jcfr

jcfr

2012-01-25 12:41

administrator   ~0003538

Sounds good. We could introduce an additional xml element named "type" that would be either "CLI, loadable, scripted".

Within mediawiki, it would still be a Category. The same way there is Filtering, etc ...

fedorov

fedorov

2012-01-25 14:23

developer   ~0003545

IMHO, the solution that involves categorization based on parsing of path + categories() call, and differentiating bw extensions is an overcomplication.

I would delegate the task of "categorization" to the module developer, and use just module API to get the list of categories. Yes, we would have to categorize the existing modules, but forward-looking, this is a very manageable solution. Developer is the ultimate expert to assign categories.

To handle "Loadable"/"CLI"/"Scripted" categories/tags, how about having the appropriate superclass adding the proper tag to the list of categories returned, and make it a rule to call superclass categories() in the child?

All CLIs are coming through qSlicerCLIModule.h, scripted through qSlicerScriptedLoadableModule, what do you think?

jcfr

jcfr

2012-01-25 14:41

administrator   ~0003547

I was talking about mediawiki categorisation ... not within python or c++.

And as you mentioned, within c++/python the module itself will easily now which type it is because it derive from either qSlicerCLIModule, qSlicerScriptedLoadableModule, etc ...

Issue History

Date Modified Username Field Change
2011-12-01 17:51 jcfr New Issue
2011-12-01 17:52 jcfr Reporter jcfr => fedorov
2011-12-12 07:39 finetjul Status new => assigned
2011-12-12 07:39 finetjul Assigned To => jcfr
2012-01-23 08:52 fedorov Note Added: 0003519
2012-01-23 19:59 finetjul Note Added: 0003521
2012-01-24 17:21 fedorov Note Added: 0003524
2012-01-25 10:37 finetjul Note Added: 0003526
2012-01-25 11:44 jcfr Category Documentation => Slicer Wiki
2012-01-25 12:23 jcfr Note Added: 0003535
2012-01-25 12:23 jcfr Relationship added child of 0001522
2012-01-25 12:32 finetjul Note Added: 0003536
2012-01-25 12:41 jcfr Note Added: 0003538
2012-01-25 14:23 fedorov Note Added: 0003545
2012-01-25 14:41 jcfr Note Added: 0003547
2012-02-02 03:22 jcfr Relationship deleted child of 0001522
2012-02-02 03:22 jcfr Relationship added related to 0001522
2012-05-15 14:56 jcfr Category Slicer Wiki => Documentation & Wiki
2012-08-21 11:59 jcfr Target Version => Slicer 4.3.0
2013-08-30 20:31 jcfr Target Version Slicer 4.3.0 => Slicer 4.4.0
2014-05-12 11:52 jcfr Status assigned => acknowledged
2014-05-12 11:52 jcfr Target Version Slicer 4.4.0 =>
2014-05-12 18:59 jcfr Relationship added related to 0003474
2016-06-20 14:15 jcfr Category Core: Documentation & Wiki => Core: Documentation and Wiki