Developer Meetings/20130226 - Revision history

Grundlett: Text replacement - "slicerWiki/index.php" to "wiki"

2019-11-21T17:00:54Z

Text replacement - "slicerWiki/index.php" to "wiki"

JChris.FillionR: /* Conclusion */

2013-03-05T20:40:38Z

Conclusion

JChris.FillionR: /* Conclusion */

2013-03-05T20:39:09Z

Conclusion

JChris.FillionR at 02:27, 5 March 2013

2013-03-05T02:27:05Z

JChris.FillionR at 16:55, 25 February 2013

2013-02-25T16:55:42Z

Fedorov at 13:52, 25 February 2013

2013-02-25T13:52:21Z

Kikinis: /* Listing of Modules */

2013-02-22T05:24:07Z

Listing of Modules

Kikinis: /* Introduction */

2013-02-21T13:53:57Z

Introduction

Kikinis at 13:50, 21 February 2013

2013-02-21T13:50:01Z

Kikinis at 13:40, 21 February 2013

2013-02-21T13:40:00Z

@@ Line 28: / Line 28: @@
 Image:Utilities-2013-02-21.png|Utilities: Should be converted to extensions, I would think. I am not quite sure about the Brains utilities. Perhaps Hans can chime in.
 Image:DevelopersTools-2013-02-21.png|Developers tools: Is there a good reason not to turn this into an extension? Most people will not need this. Should performance test be moved to the testing category?
-Image:Legacy-2013-02-21.png|Legacy: Should be turned into an extension. Demian, how about otsu, is the module used for DTI estimation or is ITK accessed directly? http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/DeprecatedModules
+Image:Legacy-2013-02-21.png|Legacy: Should be turned into an extension. Demian, how about otsu, is the module used for DTI estimation or is ITK accessed directly? http://www.slicer.org/wiki/Documentation/Labs/DeprecatedModules
 Image:Tests-2013-02-21.png|Testing: Utilities, testing, developers tools should all be reviewed and reorganized together. As a guiding principle, the presentation should target end users. Developers should be directed to the developer page on the wiki.
 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
@@ Line 52: / Line 52: @@
 ** Surface Models: ICP. It shouldn't be to hard to create the associated extension.
 ** Multivolume: It seems creating a "Multivolume" category makes sens.
-** Deprecated / Legacy: Let's refine which module belong to this extension. See http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/DeprecatedModules
+** Deprecated / Legacy: Let's refine which module belong to this extension. See http://www.slicer.org/wiki/Documentation/Labs/DeprecatedModules
 *** Discussed concept of meta-extension (similar to what is done in ubuntu for example) ... it is just an extension that specify a list of other extensions that should be installed. It would give us flexibility.

← Older revision		Revision as of 20:40, 5 March 2013
Line 53:		Line 53:
	** Multivolume: It seems creating a "Multivolume" category makes sens.		** Multivolume: It seems creating a "Multivolume" category makes sens.
	** Deprecated / Legacy: Let's refine which module belong to this extension. See http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/DeprecatedModules		** Deprecated / Legacy: Let's refine which module belong to this extension. See http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/DeprecatedModules
		+	*** Discussed concept of meta-extension (similar to what is done in ubuntu for example) ... it is just an extension that specify a list of other extensions that should be installed. It would give us flexibility.

← Older revision		Revision as of 20:39, 5 March 2013
Line 38:		Line 38:

	= Conclusion =		= Conclusion =
		+
		+	* Csaba presented the proposed improvement for opacity and slice intersection visibility of models in a hierarchy. And we all agree it made sens. For reference: http://slicer-devel.65872.n3.nabble.com/Opacity-and-slice-intersection-visibility-of-models-in-a-hierarchy-tt4027732.html
		+
		+	* Julien mentioned that at some point he will be working on adding "unit" awareness application wide
		+
		+	* Reviewed modules re-organization proposed by Ron
		+	** Wizard category will be removed + ChangeTracker will be added to Quantification
		+	** Endoscopy -> will be moved into extension
		+	** Testing + Developer tools: Hidden by default. It will be possible to show "DeveloperTools / Testing" by enabling it from the settings.
		+	** Resample category: We probably need to discuss further
		+	** Editor in both segmentation and core modules - What should we do instead ?
		+	** Filtering: We need to come up with a clear plan
		+	** Surface Models: ICP. It shouldn't be to hard to create the associated extension.
		+	** Multivolume: It seems creating a "Multivolume" category makes sens.
		+	** Deprecated / Legacy: Let's refine which module belong to this extension. See http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/DeprecatedModules

← Older revision		Revision as of 02:27, 5 March 2013
Line 36:		Line 36:
	* This issue comes up in PET processing when we need to store SUV corrected volume.		* This issue comes up in PET processing when we need to store SUV corrected volume.
	* Is there a similar issue for RT data?		* Is there a similar issue for RT data?
		+
		+	= Conclusion =

@@ Line 2: / Line 2: @@
 == To discuss ==
 ===Module reorganization===
 ====Introduction====

@@ Line 1: / Line 1: @@
-=Introduction=
+__TOC__
 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"
-=Listing of Modules=
+====Listing of Modules====
 <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
@@ 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
 </gallery>

@@ Line 1: / Line 1: @@
 =Introduction=
-*We should reorganize the listing of modules in such a way that each category has only one choice per category or 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 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 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=
@@ Line 15: / Line 15: @@
 Image:SurfaceModels-2013-02-21.png|Surface Models: Is this the best name for this category? We need ICP registration. Its a must.
 Image:Converters-2013-02-21.png|Converters: Is this where the resampling tools belong? Does the Dicom converter belong here or into the Informatics category or both?
 Image:|
 Image:|
 Image:|
 </gallery>