Difference between revisions of "Slicer4:SliceViews"

From Slicer Wiki
Jump to: navigation, search
Line 23: Line 23:
  
 
== Development Issues ==
 
== Development Issues ==
 +
 +
This section refers to active development issues during summer/fall 2010:
 +
 +
*

Revision as of 15:50, 26 August 2010

Home < Slicer4:SliceViews

This is a page describing the functionality, architecture and implementation of the Slicer4 slicer4 slice views.

Goals

The overall goal is to provide a full-featured set of 2D slice capability with at least the level of functionality, performance, and accuracy provided in slicer3. This implementation needs to be accomplished by the slicer4 team during the summer/fall 2010 timeframe for delivery to the larger developer community for use during the January 2010 NA-MIC All Hands Meeting.


Approach

Background

Because the slice views include significant interactive components they rely on all parts of slicer. In Slicer3, the slice view depended not only on VTK, but also on the KWWidgets GUI infrastructure to implement much of the event management and display. This code was developed using object oriented scripting (incrTcl) on top of tcl-wrapped VTK and KWWidgets (http://viewvc.slicer.org/viewcvs.cgi/branches/Slicer-3-6/Base/GUI/Tcl/).

Adapter Layer

In slicer4 uses Qt instead of KWWidgets, and python-wrapped VTK so porting the existing code is non-obvious. To address this, a python-in-tcl compatibility layer was added to slicer to allow tcl scripts to run on top of a python-wrapped vtk (this is essentially the inverse of the slicer3 python functionality that allow python scripts to run on top of a tcl-wrapped vtk).

In addition, a number of KWWidgets and Slicer3 helper classes (such as the vtkKWRenderWidget, vtkSlicerApplicationGUI, etc) are not available in slicer4. To address this, a Slicer3Adapters.tcl file contains a set of facade classes that mimic the needed parts of the behavior of slicer3 classes.

Longer Term

Slicer4 has adopted the concept of MRML Displayable Managers as a way to organize interactive components in 2D and 3D views. As time permits, more and more of the behavior will be ported and implemented in this framework. Once functionality parity is achieved, the adapter layer can be phased out.

Development Issues

This section refers to active development issues during summer/fall 2010: