Has this been considered unnecessary then? See "Additional information" field.

Note: I will work on consolidating the category for BRAINS

Otherwise, to allow user to easily find the installer extension categories and associated modules, you will find some suggestions at the end.

First, here is an attempt to describe in more details the current problem:

Currently modules provided by freshly installer extensions are either "dispatched" into existing categories or new category are added (alphabetical order).

For a user that do not know which category extensions module are associated with, it can be hard to find the module of an extensions.

To help the user, we should provide some "clues". There are few options:

(1) textual: After installing an extension ... popup a dialog explaining where to find the modules.

(2) visual: After clicking on the module menu, user can easily identify the new categories and modules.

I think implementing option (2) will be the most helpful for the user.

As suggested by Csaba, new categories and modules could be listed after the favourite modules and before the categories.

Without extensions installed:

###################

Annotations

Data

DataStore

DICOM

Editor

Markups

Models

Scene Views

Subject Hierarchy

Transforms

View Controllers

Volume Rendering

Volumes

Welcome to Slicer

--------------------

Wizzard

Informatics

Registration

[...]

#####################

With extensions installed, new categories and modules will be listed at before the builtin categories:

###################

Annotations

Data

DataStore

DICOM

Editor

Markups

Models

Scene Views

Subject Hierarchy

Transforms

View Controllers

Volume Rendering

Volumes

Welcome to Slicer

--------------------

SlicerRT

--------------------

Wizzard

Informatics

Registration

[...]

#####################

If an extension adds module to an already existing category (for example Registration), what should we do ?

Thanks for the comment!

What did you mean by that the newly added categories are ordered alphabetically? The categories don't seem to be ordered like that to me.

I like the idea of adding the extension modules between the main module list and the other categories by a separator. I can work on this part.

Good question about extension modules added in existing categories. If a developer specifies an existing category for their extension module, it is a conscious decision, so I think the best we can do is make sure the extension modules are on top within that category.

Just my two cents.

1. Separator is a great idea.

2. If I add module path in application settings (without installing extension), does it go into extension section?

3. Extension writers should be discouraged from adding to Registration section. IMO, can even be disallowed. It is not helpful for users; they won't easily find where it got added.

4. Ability to add a extension icon to menu branch (SlicerRT entry in your example) would make a nice visual cue.

I implemented the built-in module concept, and the categories defined by external modules appear separately between the top-level modules and the built-in categories in the modules list (see screenshot attached to pull request)
https://github.com/Slicer/Slicer/pull/356

What I didn’t implement for this round:

• Adding external modules without any category (top-level) to the separated section
• Adding extension icon to the category created by an extension
• Adding additional clues/icons to all external modules
  I’m not sure whether any of these are needed, but these are the ideas that were thrown in at the discussion. I can implement the ones that prove necessary later.

I just see these comments now. I agree that showing new categories on top is good because they are likely to be used frequently. However, I'm very surprised by Greg's idea of prohibiting extensions from adding modules to existing categories.

My assumption is that Slicer is a single product and extensions seamlessly integrate into this product. I don't want to know about how modules are implemented, where they are downloaded from, who developed them. If I'm interested in registration then I would prefer to see all registration features in one place.

What do you think? What would be the reasons for quarantining modules that are provided by extensions?

I agree with Andras. If I install an extension that belongs to category X, I expect to find it in that category after it is installed. I am puzzled by Greg's comment as well.

I also think that existing categories should be used when adding new modules through extensions or custom path. I think Greg's comment was about easy access of these modules. This is why my implementation is not fully comprehensive, because it facilitates access only for external modules that have their own new category. Steve's suggestion was an icon on the right side of the module name, similar to Andras' "NEW" postfix. Eventually something like this would be needed. In the meantime, the developer either assigns it to a new category, or trusts that the user finds it without extra pointers.

existing categories should be used when adding new modules through extensions or custom path

Agreed.

Steve's suggestion was an icon on the right side of the module name, similar
to Andras' "NEW" postfix
In the meantime, the developer either assigns it to a new category, or trusts
that the user finds it without extra pointers.

Makes sense

The difference of opinion is that I do want to know which module comes from an extension.

So for me, it is more organized if they are not intermingled.

Greg, what are the reasons you want to know if a module is in the default Slicer installation package or installed by an extension?

When I install any software, I like to easily find and understand what was installed. Using separate menu items is one method to achieve this.

Anyway, whatever the group decides is fine with me.

The reason why I want to know if a module comes from an extension is explained in the issue decsription above. I install an extension because I know I'll need those features. As Slicer has more than a hundred built-in modules, it is not obvious what modules the extension added.

@greg: note that listing a module at the top level does not mean it disappears from the menu sections corresponding to the category/categories it is assigned to. As you can see, Editor shows up at the top level, as well as under Segmentation. So if you install a new extension that does some form of registration, you could potentially list it at the top and under Registration.

Fixed in r24594
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24594