Documentation/Labs/VTKWidgets - Revision history

Lasso: Replaced content with "Content of this page was merged into Documentation/Labs/Improving_Markups"

2019-03-04T19:40:42Z

Replaced content with "Content of this page was merged into Documentation/Labs/Improving_Markups"

Max.smolens: /* vtkAnnotationROIWidget/vtkAnnotationROIRepresentation */

2015-10-06T23:07:26Z

vtkAnnotationROIWidget/vtkAnnotationROIRepresentation

Max.smolens: /* Design and Implementation */

2015-10-06T22:22:21Z

Design and Implementation

Pieper: /* Motivation */

2015-04-01T14:36:33Z

Motivation

Nicole: /* Design and Implementation */

2015-03-31T22:36:18Z

Design and Implementation

Nicole: /* Design and Implementation */

2015-03-31T22:35:27Z

Design and Implementation

Nicole: /* Design and Implementation */

2015-03-31T22:33:40Z

Design and Implementation

Nicole: /* Design and Implementation */

2015-03-31T22:30:54Z

Design and Implementation

Nicole: /* Design and Implementation */

2015-03-31T22:29:05Z

Design and Implementation

Nicole: /* Features */

2015-03-31T22:22:36Z

Features

← Older revision		Revision as of 19:40, 4 March 2019
Line 1:		Line 1:
−	~~=Motivation=~~	+	Content of this page was merged into [[Documentation/Labs/Improving_Markups]]
−
−	~~This page has the following purposes:~~
−	* It documents the user and developer features we wish to support in Slicer
−	* It documents the changes could be considered in the official VTK Widgets.
−	* It presents Slicer specific implementation acting as an alternative to VTK widgets.
−	* It evaluates the VTK widgets in terms of the appropriateness of their current design and implementation for efficiently addressing the needed use cases in Slicer.
−
−	~~=Features Missing in 4.4=~~
−
−	~~==For Users==~~
−
−	* Control L to make a new fiducial list
−	* Control I for persistent place toggle
−	* Control M to make a ruler between last two placed fiducials
−	* back tick and control/shift back tick to jump slices to fiducials
−	* delete or backspace (or 'd') to delete fiducial under mouse
−	* 'p' to place fiducial without having to click in window to grab focus
−	* Right click context menu (allow all operations currently supported in the table widget in the Markups GUI)
−	* modifier key to move fiducials between slices in 2D
−	* scaling issues (2D widget is scaled down by 300x compared to 3D)
−	* restrict to surface (found issues with the point placer wrt how it would be used in Slicer)
−	* rubber band placement for rulers
−
−	~~==For Developers==~~
−
−	* A start/end and moving event with seed number
−	* A start/end and hover event
−	* near widget vs near handle events
−	* A 2D version of ~~the oriented handle widget~~
−	* consistent widget interfaces for click to place as well as programatic placement (vs them being added with zero size and having to be manipulated)
−	* consistent distribution of settings from the widget to all handles (process events on/off, visibility, display properties).
−	* expanded WidgetState settings that can be queried and maybe set
−
−	~~=Design and Implementation=~~
−
−	~~==Fiducials==~~
−	For the fiducials, we are currently using a vtkSeedWidget in both 2D and 3D. With the oriented polygonal handle representation being the only option to show a glyph and text together, and it being a 3D widget, it introduces some quirks in the 2D viewers. The Markups displayable managers have already been split into 2D and 3D versions to deal with this.
−
−	~~Some approaches:~~
−
−	* subclass the seed widget and representation and handles and create Slicer specific implementations
−	** Cons:
−	***not easy to feed back into VTK
−	** Pros:
−	***full control
−	***did something similar already with the ROI widget
−	* modify the Slicer specific VTK github fork to implement the features we need in C++, then migrate them back via gerrit
−	** Cons:
−	*** Still constrained by the VTK implementation as a starting point
−	** Pros:
−	*** more freedom to experiment/customise
−	*** easy to feed back into VTK
−	* Port the Slicer3 Tcl implmentation of the 2D fiducials to Python for Slicer4
−	** Cons:
−	*** issues with the reloadability of the scripted displayable managers
−	*** not easy to feed back into ~~VTK~~
−	*** not quite as modular as we might end up with the widget type code embedded in the displayable manager
−	** Pros:
−	*** full control
−	*** nominally easier as that version supported many of our missing use cases
−	* Port the Slicer3 Tcl implementation of the 2D fiducials into C++ for Slicer4
−	** Cons:
−	*** Slightly more complex port
−	** Pros:
−	*** full control
−	*** supports modularity (make a widget class first, then the displayable manager can be scripted)
−	*** can have a custom VTK class in our fork, easy to port back to VTK
−
−	~~==vtkAnnotationROIWidget/vtkAnnotationROIRepresentation==~~
−
−	vtkAnnotationROIWidget/vtkAnnotationROIRepresentation are clones of vtkBoxWidget2/vtkBoxRepresentation that have been modified and extended. Ideally the necessary changes will be integrated back into the VTK classes. The changes are:
−	* Commented out face picking, and therefore rotation by dragging on faces. The VTK classes now offer this control.
−	* Added control over the color of individual handles. The only concern would be maintaining a backwards compatible API.
−	* Added members and getters related to handling when the MRML node has a parent transform. For example, [https://github.com/Slicer/Slicer/blob/30a89fefc61f45e0fe770f99be48addc0a9bf4f9/Modules/Loadable/Annotations/VTKWidgets/vtkAnnotationROIRepresentation.cxx#L320-L321 WorldToLocalMatrix], GetExtents(), GetCenter(), and GetActors().
−
−	The transform-related additions seem intended to either simplify or optimize how vtkMRMLAnnotationROIDisplayableManager synchronizes the MRML node and the widget. For example, instead of calling SetTransform() on the widget, which would rebuild the representation, the displayable manager sets the UserMatrix on all the vtkActors. Another example is how GetExtents() and GetCenter() return computations based directly on the point data, which are now always in local coordinates, whereas calling GetBounds() would return world coordinates.
−
−	Reworking the displayable manager to not use these extra functions seems possible. One concern would be that doing so would affect performance, because likely the extra functions allow optimization by avoiding excessive transforming of the points and rebuilding of the widget representation. Another concern would be verifying that the proper coordinate frames are used in the reworked the display manager, since the code is currently not well-documented and some method calls to convert coordinate frames are simply commented out.
−
−	Some picking might need to be reworked. In the test branch I can't pick handles on the back of the cube. See topic [https://github.com/msmolens/Slicer/tree/sync-vtkAnnotationROIWidget-with-vtkBoxWidget2 sync-vtkAnnotationROIWidget-with-vtkBoxWidget2].
−
−	~~=References=~~
−
−	* [http://slicer-devel.65872.n3.nabble.com/interactive-contour-editing-td4032633i20.html#a4033779 Interactive Contour Editing thread on slicer-dev (2015)]
−	* [http://www.na-mic.org/Wiki/index.php/Projects:ARRA:SlicerAM:vtkWidgets ARRA grant widget notes (2010)]
−	* [~~http://www.slicer.org/slicerWiki/index.php/~~Documentation/~~Nightly~~/~~SlicerApplication/MouseandKeyboardShortcuts Mouse and Keyboard Shortcuts (nightly)~~]
−	* [http://viewvc.slicer.org/viewvc.cgi/Slicer3/trunk/Base/GUI/Tcl/ Slicer3 Tcl SWidget, SeedSWidget, FiducialsSWidget]

← Older revision		Revision as of 23:07, 6 October 2015
Line 78:		Line 78:

	Reworking the displayable manager to not use these extra functions seems possible. One concern would be that doing so would affect performance, because likely the extra functions allow optimization by avoiding excessive transforming of the points and rebuilding of the widget representation. Another concern would be verifying that the proper coordinate frames are used in the reworked the display manager, since the code is currently not well-documented and some method calls to convert coordinate frames are simply commented out.		Reworking the displayable manager to not use these extra functions seems possible. One concern would be that doing so would affect performance, because likely the extra functions allow optimization by avoiding excessive transforming of the points and rebuilding of the widget representation. Another concern would be verifying that the proper coordinate frames are used in the reworked the display manager, since the code is currently not well-documented and some method calls to convert coordinate frames are simply commented out.
		+
		+	Some picking might need to be reworked. In the test branch I can't pick handles on the back of the cube. See topic [https://github.com/msmolens/Slicer/tree/sync-vtkAnnotationROIWidget-with-vtkBoxWidget2 sync-vtkAnnotationROIWidget-with-vtkBoxWidget2].

	=References=		=References=

@@ Line 35: / Line 35: @@
 =Design and Implementation=
 For the fiducials, we are currently using a vtkSeedWidget in both 2D and 3D. With the oriented polygonal handle representation being the only option to show a glyph and text together, and it being a 3D widget, it introduces some quirks in the 2D viewers. The Markups displayable managers have already been split into 2D and 3D versions to deal with this.
@@ Line 66: / Line 67: @@
 *** supports modularity (make a widget class first, then the displayable manager can be scripted)
 *** can have a custom VTK class in our fork, easy to port back to VTK
 =References=

@@ Line 2: / Line 2: @@
 This page has the following purposes:
-* It documents the user and developer features we wish to support in Slicer's version of the VTK Widgets
+* It documents the user and developer features we wish to support in Slicer
-* It documents the changes we would like to ultimately see implemented in the official VTK Widgets.
+* It documents the changes could be considered in the official VTK Widgets.
-* It presents Slicer specific implementation acting as a "experimental ground" to better understand how VTK widgets could be updated.
+* It presents Slicer specific implementation acting as an alternative to VTK widgets.
 =Features Missing in 4.4=

@@ Line 54: / Line 54: @@
 *** issues with the reloadability of the scripted displayable managers
 *** not easy to feed back into VTK
 ** Pros:
 *** full control

@@ Line 43: / Line 43: @@
 ** Pros:
 ***full control
 * modify the Slicer specific VTK github fork to implement the features we need in C++, then migrate them back via gerrit
 ** Cons:

← Older revision		Revision as of 22:29, 31 March 2015
Line 33:		Line 33:

	=Design and Implementation=		=Design and Implementation=
		+
		+	For the fiducials, we are currently using a vtkSeedWidget in both 2D and 3D. With the oriented polygonal handle representation being the only option to show a glyph and text together, and it being a 3D widget, it introduces some quirks in the 2D viewers. The Markups displayable managers have already been split into 2D and 3D versions to deal with this.
		+
		+	Some approaches:
		+
		+	* subclass the seed widget and representation and handles and create Slicer specific implementations
		+	** Cons:
		+	***not easy to feed back into VTK
		+	** Pros:
		+	***full control
		+	* modify the Slicer specific VTK github fork to implement the features we need in C++, then migrate them back via gerrit
		+	** Cons:
		+	*** Still constrained by the VTK implementation as a starting point
		+	** Pros:
		+	*** more freedom to experiment/customise
		+	*** easy to feed back into VTK
		+	* Port the Slicer3 Tcl implmentation of the 2D fiducials to Python for Slicer4
		+	** Cons:
		+	*** issues with the reloadability of the scripted displayable managers
		+	*** not easy to feed back into VTK
		+	** Pros:
		+	*** full control
		+	*** nominally easier as that version supported many of our missing use cases

	=References=		=References=

@@ Line 6: / Line 6: @@
 * It presents Slicer specific implementation acting as a "experimental ground" to better understand how VTK widgets could be updated.
-=Features=
+=Features Missing in 4.4=
 ==For Users==
 ==For Developers==
 =Design and Implementation=