Difference between revisions of "Qt in Slicer3"
Line 24: | Line 24: | ||
## the menu bar, tool bar, modules menu, module search and history controls | ## the menu bar, tool bar, modules menu, module search and history controls | ||
## the CommandLineModuleGUI (so CLI modules will work in Qt) | ## the CommandLineModuleGUI (so CLI modules will work in Qt) | ||
− | |||
## the "Manipulate Slice Views" and "Manipulate 3D View" controls | ## the "Manipulate Slice Views" and "Manipulate 3D View" controls | ||
# Transition other dialogs and modules to Qt | # Transition other dialogs and modules to Qt |
Revision as of 21:07, 27 August 2009
Home < Qt in Slicer3This page captures the design considerations about moving Slicer3 from KWWidgets to 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 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 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, ParaView which migrated to Qt over the past several years).
Experiments
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).
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 Qt.
- 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.