Difference between revisions of "Sept-2009-SlicerWidgetsBrainstorm"

From NAMIC Wiki
Jump to: navigation, search
Line 48: Line 48:
 
=== Open Questions ===
 
=== Open Questions ===
 
* How .ui files mix with CMake and how they are called
 
* How .ui files mix with CMake and how they are called
−
** Seb: This is very easy. Support for Qt in CMake is very strong, as a result of our collaboration with the KDE team a few years ago. KDE relies entirely on Qt and is CMake's largest project (to my knowledge). It goes like this, and this should look very familiar if have worked with VTK wrappers:
+
** Seb: This is very easy. Support for Qt in CMake is very strong, as a result of our collaboration with the KDE team a few years ago. KDE relies entirely on Qt and is CMake's largest project (to my knowledge). Dealing with .ui file goes like this (this should look familiar if you have worked with VTK wrappers):
 
<pre>
 
<pre>
 
   SET(UI_SRCS foo.ui bar.ui)
 
   SET(UI_SRCS foo.ui bar.ui)
Line 55: Line 55:
 
</pre>
 
</pre>
 
* Need CMake to build a visual studio compatible version of Qt
 
* Need CMake to build a visual studio compatible version of Qt
 +
** Seb: not really, no :) Qt is very easy to build (especially the latest LGPL distribution). It's a matter of typing one or two commands (qmake) and you are done (go get a coffee far far away though). We have approached Nokia/Trolltech to see if they would be interested in porting Qt build system to CMake, but they are sticking to qmake for now (to my knowledge). Porting to CMake is, to my opinion, a non-trivial effort, since Qt is so close to the system. I assume they include a lot of code to test if a feature is available at the low-level of the OS; while we are familiar with writing such tests, it takes some time and careful coding to cover all the bases.
 
* Need CPack to bundle Qt libraries with slicer binaries
 
* Need CPack to bundle Qt libraries with slicer binaries
 
* How to adjust the look-and-feel to make an application that includes both KWW and Qt seem coordinated (even if the windows are not nested in the same toplevel window).
 
* How to adjust the look-and-feel to make an application that includes both KWW and Qt seem coordinated (even if the windows are not nested in the same toplevel window).

Revision as of 13:26, 10 September 2009

Home < Sept-2009-SlicerWidgetsBrainstorm

Logistics

  • Tentative date: Wednesday and Thursday, September 16 and 17, 2009
  • Location: 1249 Boylston Street, 2nd floor conference room

Goals

The purpose of this meeting is to discuss development strategies to migrate Slicer to a new GUI layer. For some background and discussion of our experiments with Qt and a possible development plan see this document on Qt and Slicer3.

Important questions to consider at this meeting are:

  • What functionality does the application need to have in order to accomplish the needs of our DBP and clinical collaborations over the next several years?
  • What look and feel should the application have?
  • What capabilities will help us build the community of developers and users
    • Standard tools - well supported with ample documentation, support, etc
    • Flexibility to run in many environments
    • Ease of use and productivity for developers
  • Can we get a realistic estimate of the workload required and what skills are required to do the work?
    • How much work have comparable project required (by people with what skills and experience?)
    • What resources do we have to devote to this project compared with other demands?
  • Are we comfortable that we have considered all the viable alternatives?
    • What are the trends in GUI interface development for applications like ours
    • What are the risks/benefits/complexity trade offs of various approaches

List of Widgets that are needed for the Slicer port


Other Things to Consider

Our current plan is to move to QT. However, there are some alternates which should be looked at as a due diligence:

Javascript family

Note: with Qt's incorporation of WebKit it is possible to run any of the javascript tools natively inside a Qt application to build an alternate GUI.

Demo showing QVTKWidget as a plugin to a webpage with methods callable via JavaScript

Other Cross-platform GUIs

Open Questions

  • How .ui files mix with CMake and how they are called
    • Seb: This is very easy. Support for Qt in CMake is very strong, as a result of our collaboration with the KDE team a few years ago. KDE relies entirely on Qt and is CMake's largest project (to my knowledge). Dealing with .ui file goes like this (this should look familiar if you have worked with VTK wrappers):
  SET(UI_SRCS foo.ui bar.ui)
  QT4_WRAP_UI(UI_CXX ${UI_SRCS})
  ADD_EXECUTABLE(foobar WIN32 ${SRCS} ${UI_CXX} etc.)
  • Need CMake to build a visual studio compatible version of Qt
    • Seb: not really, no :) Qt is very easy to build (especially the latest LGPL distribution). It's a matter of typing one or two commands (qmake) and you are done (go get a coffee far far away though). We have approached Nokia/Trolltech to see if they would be interested in porting Qt build system to CMake, but they are sticking to qmake for now (to my knowledge). Porting to CMake is, to my opinion, a non-trivial effort, since Qt is so close to the system. I assume they include a lot of code to test if a feature is available at the low-level of the OS; while we are familiar with writing such tests, it takes some time and careful coding to cover all the bases.
  • Need CPack to bundle Qt libraries with slicer binaries
  • How to adjust the look-and-feel to make an application that includes both KWW and Qt seem coordinated (even if the windows are not nested in the same toplevel window).
  • Best patterns for mixing Qt and VTK (events/callbacks/signals/slots)

Attendance

  • Open to all self-declared Slicer developers:
  1. Will Schroeder
  2. Steve Pieper
  3. Ron Kikinis
  4. Nicole Aucoin
  5. Alex Yarmarkovich (Wed only)
Retrieved from "https://www.na-mic.org/w/index.php?title=Sept-2009-SlicerWidgetsBrainstorm&oldid=42402"