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.

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)

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.

Multiple categories is supported in r19133.

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 :(

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 ...)

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 ...

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?

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 ...