Difference between revisions of "Slicer4"

From Slicer Wiki
Jump to: navigation, search
Line 2: Line 2:
  
 
== Overview ==
 
== Overview ==
Slicer4 (officially 3D Slicer version 4) will be the next big development in the history of the 3D Slicer project.  It's also an opportunity to adopt some new programming styles and break with a few past traditions.  Overall though it should maintain the same spirit as earlier versions of slicer in a more modern wrapper.
+
Slicer4 (officially 3D Slicer version 4) is the next big development in the history of the 3D Slicer project.  It's also an opportunity to adopt some new programming styles and break with a few past traditions.  Overall though it should maintain the same spirit as earlier versions of slicer in a more modern wrapper.
  
 
== Main Features ==  
 
== Main Features ==  
Line 16: Line 16:
  
 
== Plan ==
 
== Plan ==
* During April and May 2010 a majority of slicer developers will be working on [[Slicer3:3.6Release|the Slicer 3.6 release]].  While 3.6 is being debugged, potentially disruptive code changes (like changes to MRML to support Qt widgets) should be added to [http://viewvc.slicer.org/viewcvs.cgi/branches/Slicer4/ the Slicer4 svn branch]
+
* Work on a patch release [[Slicer3:3.6_Final_Issues|called Slicer 3.6.3]] has resulted in a release in March of 2011.  While 3.6 is i the final stages of being debugged, potentially disruptive code changes (like changes to MRML to support Qt widgets) should be added to [http://viewvc.slicer.org/viewcvs.cgi/branches/Slicer4/ the Slicer4 svn branch]
* Tutorials and breakout sessions will be held at the [http://www.na-mic.org/Wiki/index.php/2010_Summer_Project_Week Summer Project Week] in June.
+
* Bulk of the core developer effort has switched to Slicer4 by early 2011
* Bulk of developer effort will switch to Slicer4 during the last half of 2010
+
* 3D Slicer version 4.0 release date: Jan 2011
* 3D Slicer version 4.0 release date: TBD
 
  
 
== Considerations for Developers ==
 
== Considerations for Developers ==

Revision as of 16:12, 19 March 2011

Home < Slicer4

Back to Slicer 4 Developers

Overview

Slicer4 (officially 3D Slicer version 4) is the next big development in the history of the 3D Slicer project. It's also an opportunity to adopt some new programming styles and break with a few past traditions. Overall though it should maintain the same spirit as earlier versions of slicer in a more modern wrapper.

Main Features

(Note that things will evolve as the project progresses).

Plan

  • Work on a patch release called Slicer 3.6.3 has resulted in a release in March of 2011. While 3.6 is i the final stages of being debugged, potentially disruptive code changes (like changes to MRML to support Qt widgets) should be added to the Slicer4 svn branch
  • Bulk of the core developer effort has switched to Slicer4 by early 2011
  • 3D Slicer version 4.0 release date: Jan 2011

Considerations for Developers

  • Build Instructions: SuperBuild is the evolution of getbuildtest.tcl and genlib.tcl (but with a cooler name!)
  • Slicer 3.6 will be the last KWWidgets based release so all interfaces will need to be ported to Qt. Training and support will be provided to make this as painless as possible.
  • Command Line Modules do not need to change
  • Code in Libs and Base/Logic do not link to KWWidgets and do not need to change
  • Tcl code is expected to run alongside Python code in Slicer4 in a similar manner to the way Python and Tcl coexist in Slicer3
  • Instruction explaining how to setup a dashboard are available here

Sponsorship and Participation

Major support for this effort comes from developers funded by the US National Institutes of Health through the National Alliance for Medical Image Computing, the Neuroimage Analysis Center, the National Center for Image Guided Therapy, and related collaborating efforts. Additional involvement from the research and commercial communities is also welcome and appreciated.

FAQ

What do I gain from the switch to Qt?

  • Performance, performance, performance.
    • Qt is more optimized than KW widgets
  • Community, Community, Community!
    • There's an emerging trend in the research community to adopt Qt as the de facto standard interface. This means a lot of momentum and code sharing, so slicer developers can spend more time and effort performing actual medical image computing research.
  • Better support for integration on the different platforms (e.g. no need for X11 on Mac)
  • Webkit will allow better integration of webcontent

Didn't we just make a big change from Slicer2 to Slicer3 just a few years ago? Why should we change again?

  • Constant re-invention is the nature of research. Slicer3 has served us very well, and we expect the 3.6 release to be stable and in-use for several years. Where the transition from 2->3 was about an 80% rewrite, the transition from 3->4 is expected to be concentrated primarily on the GUI.

Oh no, not another source code repository. What's wrong with svn and why should we use git?

I like Tcl - why emphasize python?

  • This is another de facto standard, just like Qt and git - there's a lot of activity that we'd like to leverage like NiPy. In a lot of ways, our experience with slicer3 has been that tcl and python are really very similar. The way python is integrated in slicer3 proves that the two languages can co-exist and both can fill the need for runtime programmability.

Additional Goals for Slicer4

  • Repository
    • Development history from svn will be migrated to git
    • Remove large binary datasets from repository and instead host them on midas or other web site for download during testing.
    • Adopt 'best practices' for keeping repository organized (use 'topic forks' for developing new code and selectively merge this to the main line of development).
  • Modularity
    • Promote some 'Libs' code to have better utility outside of slicer. Examples such as vtkITK, MRML, and the execution model may be useful in many other programs. Consider migrating to CTK or hosting independent respository.
    • Remove some older modules from default build (make them optional or convert to extensions).