Slicer3:Developers:Projects:QtSlicer/OpenDiscussions

QtSlicer←

Introduction

This page gathers discussions about code architecture/implementation/design of the Slicer port to Qt. This page is mainly for developers as it concerns the internal/implementation part of Slicer, discussions about the interface design should be listed on the UIDesign wiki page. User feedbacks should be reported on the Usability wiki page.

• Please add your ideas/comments/remarks/feedback/suggestions/problems/... below.
• Points will be discussed during regular TCon meetings , on the Slicer developer list and/or by email.
• Decisions resulting from discussions should be tracked into the Mantis under the category: QtGUI.

Open Issues

Flexible layouts Issue: Improve usability and capability of Slicer visualization views and view layouts. Reporter: Andrey Fedorov Motivation: The current layout configuration is in some ways restricted by not allowing to set arbitrary configuration of slice view/3D view combinations. Additionally, the types of views are restricted to only 2 types (slice or 3D). Suggestion: Evaluate the applicability of the flexible layout framework used in Paraview for adoption in QtSlicer (see the screenshot attached). The nice features observed in Paraview layout framework, which in my opinion are highly applicable to Slicer are: any view can be split vertically or horizontally with just a click of a button in the corner of the view -- very flexible once the view is split, user is given a choice, which view should be created -- simple and intuitive very cool view types that can be created: bar chart, plot, spreadsheet! Bar chart and plot features have been previously requested by Slicer users. Of course, introduction of new types will require re-thinking of the architecture. Decision: TBD Result: TBD Note: TBD

Closed Issues

• Module Logic
  • Issue: Change qSlicerModuleLogic into vtkSlicerModuleLogic
  • Reporter: Alexander Yarmarkovich
  • Motivation: A lot of slicer logics already exist, using qSlicerModuleLogic implies to wrap this logics. Why not directly use the vtkSlicerModuleLogic?
  • Decision: Talked by email and over the phone during the Tuesday TCon (01/26/10). The suggestion has been accepted.
  • Result: The change has been committed on 01/28/10 (r11850, r11852, r11853, r11854)
  • Note: While new module logics must derive from vtkSlicerModuleLogic, logics deriving from vtkSlicerLogic are supported for backward compatibility reasons (the core module logics derive from vtkSlicerLogic).