Logistics

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 wiki page about 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

List of Widgets that are needed for the Slicer port

Ideally there will be a community-driven process to develop higher-level Qt widgets in a reusable library, possibly as part of the newly forming Common Toolkit (CTK) effort. Wherever possible, widgets developed for slicer should be written in a reusable fashion. As always, the slicer code will be offered with a BSD-style license for re-use in other projects.

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 quite 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 files goes like this (this should look familiar if you have worked with VTK wrappers):

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 (mainly Bill H.) have approached Nokia/Trolltech to see if they would be interested in porting the 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, considering the sheer size of the Qt distribution and how close to the system it is. I assume they include a lot of code to test if such or such 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.

Steve: actually not so easy to build for visual studio - Qt comes with a configure.exe that can create build files for various back-ends like msvc2008 etc, but there are a lot of issues reported (mvsc2008 worked, but msvc2005 had some build errors for webkit and others). Presumably this is something that will sort out over time.

Need CPack to bundle Qt libraries with slicer binaries

Seb: we have experience with this, we deliver turn-key applications bundled with Qt (ParaView3 to name one, and other internal commercial projects).

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).

Seb: the trick with Slicer is that you are actually trying *not* to be consistent with the look&feel of the platform, but consistent "across" all the platforms, by using the theming framework I added a few years ago to KWW. On the other hand, Qt is definitely trying to look very close to the native UI it is running on. For Qt to look like Slicer running KWW, you would have to dig inside Qt Theming and Style Sheets (see this article from 2007) and shoehorn Qt to Slicer's branding. This is do-able, but is definitely considered an "advanced" topic; my opinion is that there is already a good deal to learn before. While I'm a big fan of branding and Wendy's fantastic UI work, I would also suggest reconsidering theming Slicer so heavily, I think it looks very alien on platforms like MacOS; maybe this doesn't bother users as much as I think, you guys have a survey? Definitely keep the beautiful icons, but let Qt do his job with the layout. KWW allows the user to bend the layout almost to the pixel, but I think going so close to the metal has been the source of a lot of frustrations and weird glitches in the layout, still to this day.

J2: the Motif style seems the closer to the look-and-feel of Slicer. If it's not good enough, as Seb said, one can still create css-style sheets (and make it as similar as possible). A compromise between look-and-feel similarity and time to spend must be found ( i.e. how much time are we willing to spend to have a qt scrollbar to look exactly the same as the original Slicer scrollbar).

J2: Note: vtkEventQtSlotConnect is only taking care of the VTK->Qt connection

Attendance

Open to all self-declared Slicer developers:

Will Schroeder

Steve Pieper

Ron Kikinis

Nicole Aucoin

Alex Yarmarkovich (Wed only)

Sebastien Barre

JC Fillion

Katie Hayes

Andriy Fedorov

Junichi Tokuda (Thu only)

Results

Much fruitful discussion and interesting demonstrations. Overall feeling was that the task seems achievable and will provide positive benefits to the slicer developer and user communities. There will be a major disruption of development activities but the participants felt that the Qt port is worth the effort and should be undertaken.