Documentation/Labs/SubjectHierarchy - Revision history

Pinter: /* Create subject hierarchy item */

2017-04-03T15:24:43Z

Create subject hierarchy item

Pinter: /* Manipulate subject hierarchy item */

2017-03-31T17:56:23Z

Manipulate subject hierarchy item

Pinter: /* New features */

2017-03-07T16:42:33Z

New features

Pinter at 17:30, 22 February 2017

2017-02-22T17:30:55Z

Pinter: Code samples

2017-02-22T16:46:17Z

Code samples

Pinter at 21:40, 21 February 2017

2017-02-21T21:40:35Z

Pinter: Subject hierarchy 2.0

2017-02-21T17:59:48Z

Subject hierarchy 2.0

Pinter: /* Future features */

2014-06-04T10:06:41Z

Future features

Pinter: /* Issues */

2014-06-04T10:05:14Z

Issues

Pinter: /* Future features */

2014-06-04T10:02:56Z

Future features

@@ Line 70: / Line 70: @@
 ==== Create subject hierarchy item ====
-   # If it is for a data node, it is automatically created, but the create function can be used to change certain properties (such as parent):
+   # If it is for a data node, it is automatically created, but the create function can be used to set parent:
-   shn.CreateItem(parentItemID, dataNode, level) # Level is Series if omitted
+   hn.CreateItem(parentItemID, dataNode)
    # If it is a hierarchy item without a data node, then the create function must be used:
-   shn.CreateItem(parentItemID, name, level) # Level is folder if omitted
+   shn.CreateSubjectItem(parentItemID, name)
 ==== Get subject hierarchy item ====

@@ Line 94: / Line 94: @@
    shn.SetItemName(itemID, 'NewName')
    # Set item parent (reparent)
-   shn.SetItemParent(itemID, newParentItemID)'
+   shn.SetItemParent(itemID, newParentItemID)
 == Branch on GitHub ==

@@ Line 49: / Line 49: @@
 == New features ==
 * Enabled by default, because it does not clutter the MRML scene and there are no special mechanisms to support other hierarchies
 ** No pop-up window when entering the module, it can be used immediately
 * Improved drag&drop
 ** Re-ordering of items is supported, and is restored correctly when reconstructing the hierarchy (loading a scene etc.)
@@ Line 56: / Line 59: @@
 * Expand and collapsed states of the items are preserved, and restored when reconstructing the hierarchy
 ** (this and re-ordering was supposed to be implemented in Models, but it seems to have never worked, and there is a lot of dead code in the repository)
-* Drop-down subject hierarchy tree is possible to add in the modules instead of a simple MRML node selector. This, besides allowing an easier overview of the data, makes it possible to differentiate between nodes that have the same name but belong to different patient or study
+* Subject hierarchy combobox showing a drop-down tree
-* Full support of model hierarchies in subject hierarchy
+** It can be added in the modules instead of a simple MRML node selector. This, besides allowing an easier overview of the data, makes it possible to differentiate between nodes that have the same name but belong to different patient or study
-** Subject hierarchy shows the same tree that the Models module shows, and it is handled the same way (drag&drop, show/hide, etc.)
+* More versatile filtering options in the tree and combobox (name, attribute, level)
 == Programmatic access and manipulation ==

@@ Line 84: / Line 84: @@
    # Invalid item ID for checking validity of a given ID (most functions return the invalid ID when item is not found)
    invalidItemID = slicer.vtkMRMLSubjectHierarchyNode.GetInvalidItemID()
 == Branch on GitHub ==

@@ Line 59: / Line 59: @@
 * Full support of model hierarchies in subject hierarchy
 ** Subject hierarchy shows the same tree that the Models module shows, and it is handled the same way (drag&drop, show/hide, etc.)
 == Branch on GitHub ==

@@ Line 40: / Line 40: @@
 <br>
 This necessitates a re-design of the subject hierarchy mechanism. The proposed solution is to store the whole subject hierarchy tree in one node, the internals of which are synchronized with the data nodes of the scene. A new Qt item model needs to be implemented for this node that supplies the information to the tree view and the future node selectors.
-* The proposed quasi-singleton vtkMRMLSubjectHierarchy node
+* The proposed pseudo-singleton vtkMRMLSubjectHierarchy node
 ** Contains items that have unique identifier numbers that is strictly incremental
 ** Item information can be accessed using accessors, the item class itself is private

@@ Line 20: / Line 20: @@
 * Provides a multitude of features through the plugin mechanism
-= Subject hierarchy plugin mechanism =
+= Subject hierarchy 2.0 =
 The plugins extend the abstract plugin class that provides broad API offering many customizations. '''These plugins are the building blocks that make subject hierarchy a really useful central organizing point.'''
 === Plugin types ===
@@ Line 55: / Line 100: @@
 ** ...
-= Code branch on github =
+== Branch on github ==
 https://github.com/cpinter/Slicer/tree/subject-hierarchy-integration
 For code examples, see C++ and python tests
-= Slicer core changes =
+== Slicer core changes ==
 * SubjectHierarchy module added in Modules/Loadables
 * Subject hierarchy plugins added in Markups, Models, and Volumes
@@ Line 73: / Line 118: @@
 * Added two subject hierarchy python self tests in Applications/SlicerApp/Testing
-= Future features =
+== Issues ==
 * Not all data is automatically added to subject hierarchy
 ** DICOM data is covered
@@ Line 92: / Line 127: @@
 ** The tree collapses when loading data when subject hierarchy module is active, and sometimes after drag&drop. As a workaround, the user can use the expand to level option of the scene item.
 ** The tree can completely disappear. The user has to switch to another module and back.

@@ Line 81: / Line 81: @@
 * Improve visibility controls - multiple 3D and 2D views, volume rendering, etc.
 * Select and drag&drop multiple nodes from the potential list
-* Create subject hierarchy based node selector that replaces qMRMLNodeComboBox. Provides a small window with a simple tree view showing only the nodes of the requested type (and attributes)
+* Create subject hierarchy based node selector that can replace qMRMLNodeComboBox in places where the user wants to have a nicer (and familiar) view of the loaded data that is available for that role. Provides a small window with a simple tree view showing only the nodes of the requested type (and attributes)
 = Issues =

← Older revision		Revision as of 10:05, 4 June 2014
Line 89:		Line 89:
	** The user can drag&drop supported nodes in the hierarchy, but currently only one can be moved at a time		** The user can drag&drop supported nodes in the hierarchy, but currently only one can be moved at a time
	** Outputs of analysis and processing modules have to be added manually, unless it supports subject hierarchy		** Outputs of analysis and processing modules have to be added manually, unless it supports subject hierarchy
		+	* Refresh problems related to scene model
		+	** The tree collapses when loading data when subject hierarchy module is active, and sometimes after drag&drop. As a workaround, the user can use the expand to level option of the scene item.
		+	** The tree can completely disappear. The user has to switch to another module and back.

@@ Line 78: / Line 78: @@
 * AddNode and Reparent should make sure the invalid drag&drop operations are not allowed
 * Allow re-ordering nodes in the tree
-* Add a "reference inspector" widget where these references can be explored and edited (it can be part of the current MRML Node Inspector widget or a separate one)
+* Add a "reference inspector" widget where MRML node references can be explored and edited (it can be part of the current MRML Node Inspector widget or a separate one)
 * Improve visibility controls - multiple 3D and 2D views, volume rendering, etc.
 * Select and drag&drop multiple nodes from the potential list