Difference between revisions of "Documentation/Labs/VTKWidgets"

From Slicer Wiki
Jump to: navigation, search
Line 61: Line 61:
 
*** Slightly more complex port
 
*** Slightly more complex port
 
** Pros:
 
** Pros:
 +
*** full control
 
*** supports modularity (make a widget class first, then the displayable manager can be scripted)
 
*** 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
 
*** can have a custom VTK class in our fork, easy to port back to VTK

Revision as of 22:35, 31 March 2015

Home < Documentation < Labs < VTKWidgets

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
  • 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
  • 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

References