View source for Qt in Slicer3

This page captures the design considerations about moving Slicer3 from KWWidgets to [http://qt.nokia.com/ Qt].  As of August 2009 there are no concrete plans for a switch; however there is significant momentum around Qt as an open source technology and interest in making it available to the Slicer community.

==Background==

When Slicer3 was being designed in 2004 Qt was available only under the GPL license or a commercial (pay) license (See [http://en.wikipedia.org/wiki/Qt_%28toolkit%29 the wikipedia discussion]) and neither license option was acceptable to the community.  In March 2009 Qt 4.5 was released under the LGPL license and became a possible technology for use in Slicer.

Slicer3 is implemented using [http://www.kwwidgets.org KWWidgets] which has proven to be extremely capable and robust.  However, due to the small size of the developer team for KWWidgets Kitware has been clear that it will not be able to compete with the features being added to Qt and is in fact adopting Qt for many of its internal projects (see, for example, [http://paraview.org ParaView] which migrated to Qt over the past several years).

==Experiments==
[[Image:Slicer3.5+Qt+Python-Test-2009-08-27.png|thumb|right|Screenshot from a version of slicer that has Qt accessible from the python console.]]
In August of 2009 several members of the slicer development team have been learning about Qt and reviewing options.  Things that are currently working:
* Qt and KWWidgets can co-exist in same application environment (in different top level windows).
* Qt widgets interfaces can be assembled using the QtDesigner, C++, or python.
* It is feasible to create slicer widgets that use Qt (e.g. a NodeSelector widget).

Overall the experience has been positive but the experiments have shown that there will be a significant amount of programming work to be done for each part of the interface.  Most of the work is probably best characterized as "easy but time consuming".  The net result of converting is expected to be positive but it is likely to be several years for there to be a payoff in terms of overall increased developer productivity and improved functionality of the overall package.

==Development Plan Option for Transition to Qt==

The following is a summary of the work to be done organized in a more-or-less priority order that would allow a transition in-place of functionality from KWW to Qt.

# Configure CPack to include Qt libraries and turn on Qt support by default in nightly builds of slicer
# Create prototype modules built using Qt (these would appear in a distinct top level window from the rest of slicer.  The size and position would be under programatic control to make the two interface somewhat unified).
# Migrate the vtkSlicerViewerWidget, vtkSlicerSliceControllerWidget, and vtkSlicerSliceWidget from KWW to Qt.  This would allow the right side (2D/3D viewers) of the interface to exist in Qt with the left side (module interfaces) to exist in KWWidgets.
# Migrate interfaces from modules and left side functions into Qt
## the menu bar, tool bar, modules menu, module search and history controls
## the CommandLineModuleGUI (so CLI modules will work in Qt)
## the "Manipulate Slice Views" and "Manipulate 3D View" controls
# Transition other dialogs and modules to Qt
## Add Data, Add Volume, Save, Extension Wizard, Application Settings, Cache & Remote I/O Manager, Tcl/Python Interactors, ErrorLog Dialog, Keyboard Shortcuts...
## Core Modules: Colors, Data, Editor, Fiducials, Measurements, Models, ROI, SlicerWelcome, Slices, Transforms, Volume Rendering, Volumes
## Application Modules: Change Tracker, IA_FEMesh, Qdec, FetchMI, Query Atlas, AC/PC Transform, ModelMirror, EMSegment, LabelStatistics, Tractography, Fiber Bundles, NeuroNav, OpenIGTLink IF, ProstateNav, Clip Model, Extract Subvolume ROI, 4D Volume, 4D Analysis.
## Extension Modules and DBP Projects: Perk Station, VMTK Vessel Tools, others...
# Remove KWW from the builds and do a new release.

==Slicer's KWWidgets-based GUI==
===Statistics===
* There are '''3309''' KWWidgets instances created in slicer core and modules (calls to New)
* These calls are from '''123''' different KWWidget classes (including 'pure' KW classes in slicer that only depend on vtkKW and not MRML or other slicer code) 
* '''37''' KKWidgets subclasses are vtkKWMimx classes in the Meshing module
* There are '''105''' classes that subclass from KWWidget classes

See: [[Slicer3:KKWidgets_being_used| this list of KWWidgets being used in Slicer3]].

''Statistics methods:  Calculations based on slicer3 trunk revision 10456 2009-09-10.  This does not include Tcl or Python code or extension modules (they use basically the same widgets).''

 grep -r vtkKW . | grep -v svn | grep New | wc
 grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | wc
 grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | grep Mimx |  wc
 grep -r vtkKW . | grep -v svn | grep public | wc'

==Qt widgets of interest==

Playing with Qt Designer is a good way to explore Qt's core widgets. However, some KWW widgets are fairly complex, or uses Tk canvases pretty heavily; here are a few Qt widgets replacements worth considering. They are either found in the core distribution, or in [http://qt.nokia.com/products/appdev/add-on-products/catalog/4 Qt Solutions Catalog] (LGPL):

* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Thumbwheel]. Qt provides a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtthumbwheel QtThumbWheel]

* KWW's [http://www.kwwidgets.org/Wiki/Image:KWFileBrowserDialogExample.png FileBrowser] set of classes. Qt provides a [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls QFileDialog] class. It uses the native file dialogs on Win32/MacOS, and [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls a different one] on Unix, though it can use the same non-native dialog on all platforms. It can be set to pick directories only; a combination of QFile and QDirView can achieve a [http://doc.trolltech.com/4.5/images/dirview-example.png similar/better result]. ParaView uses a custom (rewritten) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewQtFileDialog.png File Dialog] to handle client-server file browsing.

* KWW's [http://www.kwwidgets.org/Wiki/Image:VtkKWColorPickerDialog_Classes.png Color Picker]. Qt provides a [http://doc.trolltech.com/4.5/qcolordialog.html#details QColorDialog], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorpicker QtColorPicker], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolortriangle QtColorTriangle] and [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorcombobox QtColorComboBox]. It is worth noting that QColorDialog offers basic colors (swatches), custom colors, RGB/HSV sliders on Win32/Unix, but uses a much more elaborate (native?) [http://www.randelshofer.ch/quaqua/guide/images/jcolorchooser.png dialog on Mac].

* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsTransferFunctionEditors.png Transfer Function Editors]. ParaView (BSD) and Maverick share a [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor.png similar transfer function editor] that is not as elaborated as KWW's, though this might do the trick for now. ParaView recently added a second (user-contributed) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png transfer function editor] that provides free-form and gaussian curves.

* KWW's [http://www.slicer.org/slicerWiki/index.php/Modules:MainApplicationGUI-Documentation-3.4#Slicer_Viewers Collapsible Frames]. The first (easiest) solution is to use a [http://doc.trolltech.com/4.5/qgroupbox.html#details QGroupBox] and manually connect the checked SIGNAL with the setVisible SLOT of all the children. You would get the same behavior (a checkbox on the left of the title instead of a cross and arrow on the left). The second solution is to inherit from QGroupBox and change the display (change the mark in the checkbox display to have + and -). [http://wiki.slicer.org/slicerWiki/index.php/File:QGroupBox.png screenshot for both solutions].

* KWW's [http://www.kwwidgets.org/Wiki/Image:EMSegmentationModuleWizardAnimated.gif Wizard] classes. Qt provides sophisticated [http://doc.trolltech.com/4.5/qwizard.html#wizard-look-and-feel QWizard] classes, as well as a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Utilities/qt-state-machine-framework/ Qt State Machine] framework. It is not clear if a Qt Wizard can be embedded inside another widget, since it inherits QDialog.

==Considerations and Open Questions==
# Coding styles and conventions for classes that interface vtk and Qt
## inheritance
## memory management
# a significant number of higher level Qt widgets are required (Ranges, Extents, TransferFunctionEditors, Material Properties...)
# Work needs to be coordinated among developers at multiple sites.  Significant face-to-face time should be planned to keep everyone in sync on the progress.
# It will be inevitable that revisiting some modules will involve redesign and feature improvements even if our focus is specifically on swapping the GUI.
# Difficult bugs will occur somewhere along the process even if the plan appears smooth.
# We should consider training courses or conferences to get us up to speed on best practices for development.  (http://www.ics.com/QuickStart/, http://qt.nokia.com/qtdevdays2009)
# What larger design re-works should be considered at the same time?  I.e. should slicer functionality be re-organized as python packages so we can get away from the monolithic application attributes of the current main program (without a reduction in functionality or usability).

==Development Approaches / Tradeoffs ==
Several development approaches could be taken each of which has pros/cons and risks.

# ''Immediate rewrite:'' this approach would be to start a from scratch to build a new GUI using Qt.  Pros: likely to result in a cleaner architecture.  Cons: all progress stops until new version is ready; current slicer developers are not Qt experts so not ready to build complex application from scratch; Qt does not have all the needed widgets to implement slicer (they need to be built along side slicer).
# ''Wait and see:'' wait until Qt more 3rd party widgets fill in the missing functionality and then do the rewrite.  Cons: any new GUI development in the old framework will seem like a dead end.  Pros: the current framework isn't really broken so why change?
# ''Peaceful coexistence:'' allow both GUI frameworks to be used together and allow people to develop in whichever is most productive for them.  Cons: extra dependencies and potential maintenance issues; may require duplicated code; still need to resolve the architecture issues for mixing vtk and qt.  Pros: removes pressure to do instant port; allows developers to get good at Qt before undertaking a big porting effort; allows development of 3rd party widgets that will make future ports easier.