Difference between revisions of "Developer Meetings/20130226"

From Slicer Wiki
Jump to: navigation, search
Line 1: Line 1:
=Introduction=
+
__TOC__
 +
 
 +
== To discuss ==
 +
===Module reorganization===
 +
====Introduction====
 
The listing of modules should be organized from the vantage point of an '''early stage end user'''. Power users know what module they want and usually look in the alphabetic listing. Developer oriented tools should not be prominent and should not crowd the listings. Developers should be directed as much as possible to the wiki as a start point.
 
The listing of modules should be organized from the vantage point of an '''early stage end user'''. Power users know what module they want and usually look in the alphabetic listing. Developer oriented tools should not be prominent and should not crowd the listings. Developers should be directed as much as possible to the wiki as a start point.
  
Line 5: Line 9:
 
*We should come up with guidance for developers on how to organize extensions. In some cases it makes sense for them to be in their own category and some cases, individual modules should be spread out to existing categories. Modules derived from extensions should have the extension acronym inside the module name. As a general rule, extension derived modules should be under the "advanced" section of a category so that the top level is not "messed up"
 
*We should come up with guidance for developers on how to organize extensions. In some cases it makes sense for them to be in their own category and some cases, individual modules should be spread out to existing categories. Modules derived from extensions should have the extension acronym inside the module name. As a general rule, extension derived modules should be under the "advanced" section of a category so that the top level is not "messed up"
  
=Listing of Modules=
+
====Listing of Modules====
 
<gallery widths="300px" perrow="3" caption="Slicer 4 Module Reorganization 2013-02-26">
 
<gallery widths="300px" perrow="3" caption="Slicer 4 Module Reorganization 2013-02-26">
 
Image:CoreModules-2013-02-21.png| Core Modules: Should we remove from or add to anything in this list? Also, wizards is empty and should be removed
 
Image:CoreModules-2013-02-21.png| Core Modules: Should we remove from or add to anything in this list? Also, wizards is empty and should be removed
Line 24: Line 28:
 
Image:WorkInProgress-2013-02-21.png|Work in progress: the current modules should be moved elsewhere. The category should be removed. All work in progress should happen through extensions
 
Image:WorkInProgress-2013-02-21.png|Work in progress: the current modules should be moved elsewhere. The category should be removed. All work in progress should happen through extensions
 
</gallery>
 
</gallery>
 +
 +
===Attaching units to image data===
 +
* This issue comes up in PET processing when we need to store SUV corrected volume.
 +
* Is there a similar issue for RT data?

Revision as of 13:52, 25 February 2013

Home < Developer Meetings < 20130226

To discuss

Module reorganization

Introduction

The listing of modules should be organized from the vantage point of an early stage end user. Power users know what module they want and usually look in the alphabetic listing. Developer oriented tools should not be prominent and should not crowd the listings. Developers should be directed as much as possible to the wiki as a start point.

  • We should reorganize the listing of modules in such a way that each category has only one choice per category/subcategory presented initially and everything else is under a tab called "Advanced". This is consistent with the way modules in Slicer should be organized.
  • We should come up with guidance for developers on how to organize extensions. In some cases it makes sense for them to be in their own category and some cases, individual modules should be spread out to existing categories. Modules derived from extensions should have the extension acronym inside the module name. As a general rule, extension derived modules should be under the "advanced" section of a category so that the top level is not "messed up"

Listing of Modules

Attaching units to image data

  • This issue comes up in PET processing when we need to store SUV corrected volume.
  • Is there a similar issue for RT data?