Documentation/Labs/VTKWidgets
From Slicer Wiki
Home < Documentation < Labs < VTKWidgets
Contents
Motivation
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 changes we would like to ultimately see implemented in the official VTK Widgets.
- It presents Slicer specific implementation acting as a "experimental ground" to better understand how VTK widgets could be updated.
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
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
- Cons:
- 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
- Cons:
- 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
- Cons:
- 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
- Cons:
