View source for Slicer:Slicer3

<br /> The purpose of this retreat is to review the progress made with the slicer 3 project and plan the work for the upcoming months. In particular, we are planning to have a release by the next AHM in January and we need to make sure we're covering the needed bases.

= Logistics =

Start at 10am going to mid afternoon.

Location Kitware.

Atendees:

* Steve Pieper
* Nicole Aucoin
* Alex Yarmarkovich
* Wendy Plesniak
* Jim Miller
* Bill Lorensen
* Sebastien Barre (Kitware)
* Will Schroeder
* Mathieu Malaterre
* Andy Cedilnik

= Where are we now =

== Current state of the implementation ==

* Review of the [[Media:Slicer3-Core1-2006-05-23.ppt| slides]] used at the Core 1 retreat

=== MRML ===

* Node Types
* Undo/Redo functionality
* Interactions with Logic and Widgets

=== GUI ===

* KWWidget Classes
* SlicerGUI Classes
* VTK 3D Widgets (aka WWidgets)

==== GUI Questions ====

* Inserting menu items before Exit in the File menu<br /><small><nowiki>=>win->GetFileMenu()->InsertCommand(win->GetFileMenuInsertPosition(), ...)</nowiki></small>
* Avoid Slice widget (option menu) resize but allow people to read full name of currently selected node. Maybe with a tooltip of the full name of the widget<br /><small><nowiki>=>Exactly. Each time you select something in that menu, intercept the event and reset the balloon help string of the option menu button with the full name of the data (vtkKWWidget::SetBalloonHelpString)</nowiki></small>
* Getting access to the RenderWindowInteractor from a KWRenderWidget (protected?)<br /><small><nowiki>=> renderwidget->GetRenderWindow()->GetInteractor()</nowiki></small>
* Can the 3D Widgets be made 'hot' so that they highlight on mouse-over events<br /><small><nowiki>=> Check with Will</nowiki></small>
* Good strategy for assessing the resolution of a machine's display, and setting Slicer3 layout parameters in a compatible way<br /><small><nowiki>=> vtkKWTkUtilities::GetScreenSize()</nowiki></small>
* Reformatting the main window to display various view options (lightbox, 3D-only, slice-only, 4-up, tabbed scene view, etc.)
* Typing Alt-F-X too fast can cause the UI to hang (Windows)<small><br /><nowiki>=> Type it slower ;) Slicer is great, why do you want to quit so fast ? Seriously, could not reproduce. My Slicer crashes and burn (leaks + crash) anyway, so I won't exit cleanly in any cases right now</nowiki></small><small><br />sp> This happens before any crashes :) But I can show you the behavior when we are together...</small>
* KWWidgets method to "eventually render" like an 'after idle render' in tcl/tk

==== Slicer widgets and KWWidgets we need to design and build ====

* Window / Level / Threshold Editor (close to being done)
* Better Slice Controller widget; one that manages FG/BG layers but also allows other layers to be defined, with visibility and compositing attributes
* MRML Scene browser (tree widget)
* MRML properties browser/editor
* 3D View navigation widget and Slice Window zoom widget (toggle on mouseover Slice Windows)
* A filebrowser without "motif" look -- which uses the registry to figure out favorite directories, maybe which contains previews of files
* Workflow wizard?
* Ibrowser (but maybe this is a scriptable widget)
* Color palette browser/editor widget

==== Other GUI Issues ====

* Progress on tracing
* Cross platform look and feel (font differences)
** (native mac port worth the effort?) See [http://www.kwwidgets.org/Wiki/KWWidgets/FAQ#Mac_OS_X_with_default_Tcl.2FTk_Aqua Cross-Plaform Issues: Mac OS X with default Tcl/Tk Aqua]
** Tile extension likely to be available?

=== Execution Model ===

* Example applications for Core 1 to use as template
* Build/Pack Environment
* Autodetection by Slicer
* Building the GUIs in KWWidgets

== Report on feedback from Cores 1 and 3 ==

= Lessons learned =

== Implementation Bottlenecks ==

* Efficient coding for fleshing out the GUI (keyboard shortcuts, widget geometry management, clean cross-platform look&feel).
** How to make all this code clean and maintainable
** How to be sure there are enough shoulders on the oars to get the work done

* Building and Launchers
** Path and LD_LIBRARY_PATH management for resources and dependent shared libraries (for Base and for Modules)
** Template CMake framework for Module writers
** More efficient builds?

* Modules
** Example ITK code using the Execution Module framework
** Bundling Modules for distribution

* "Check for Updates" feature
** Use hits on the update website to track usage patterns

== Group Coordination ==

* Standing agenda item to discuss Slicer3 projects during the engineering tcons
* User-feedback sessions on GUI and Functionality
** Randy Gollub
** BWH PNL Users
** Dartmouth Users
** Others

= What are the priorities =

* Core 1 priorities
** They like the execution model

* Core 3 priorities

* How can we focus time at the Project Week to move things ahead?
** Can we give Core 1 examples of using the Execution Model? What help do they need?

<br />

== Best of Breed ==

This is Ron's list of features where we are "best of breed" or close in Slicer 2.x.

It is important that we don't loose ground when moving to Slicer3.

* '''DTI'''<nowiki>: We have a clear advantage compared to almost everybody. </nowiki>
* '''Interactive Editor'''<nowiki>: must-have basic component </nowiki>
* '''IGT'''<nowiki>: Best integrated package: tracker, registration, segmentation and visualization </nowiki>
* '''fMRI'''<nowiki>: one-stop shopping for combination of analysis and visualization/multi-modality </nowiki>
* '''Morphometric Analysis'''<nowiki>: EM is close to the quality achieved by Freesurfer on data for which it was calibrated, but is easier to calibrate and can handle pathology (e.g. WML) </nowiki>

One of the biggest UI challenges today: many of the interface modules were designed by engineers and not sufficiently organized for the needs of end-users.

Another big challenge is that researchers prefer not to learn a "big environment" when they feel they can get their papers published with a small set of tools. Researchers also typically do not write their code for maintainability (or even when they do, they don't ''actually'' maintain it).

== Minutes ==

* Execution Model discussion
** Decision to flesh out examples of the command line modules in preparation for project week
** Decision to work on automatic generation of GUI interface during project week

* Move to ITK 2.8 Monday

* Alex and Steve to rework the GAD module for Bill and Jim to use as template for CLModule

* The next budget year GE and Kitware will allocate resources for Slicer3 development to meet development goals for January NA-MIC AHM.