Difference between revisions of "Slicer4:ViewerDesign"

From Slicer Wiki
Jump to: navigation, search
Line 29: Line 29:
  
 
* (from Wen) A first suggestion for how to color-code and ID viewers -- straw man for discussion:
 
* (from Wen) A first suggestion for how to color-code and ID viewers -- straw man for discussion:
[[image:SlicerViewers0.png | Viewer type color coding and ID ]]
+
[[image:SlicerViewers0.png |thumb|px400| Mock-up from 8/02: Viewer type color coding and ID]]
 +
 
 
** Keep Slicer Axi/Sag/Cor color coding, and all other individual slice viewers are grey
 
** Keep Slicer Axi/Sag/Cor color coding, and all other individual slice viewers are grey
 
** Keep Compare Viewers Orange
 
** Keep Compare Viewers Orange
Line 38: Line 39:
 
** Helper code to create a viewer frame with same appearance & behavior
 
** Helper code to create a viewer frame with same appearance & behavior
  
[[image:SlicerViewers-Hi1.png | Active Viewer Color = White for all viewer types ]]
+
[[image:SlicerViewers-Hi1.png |thumb|px400| Mock-up from 8/02: Active Viewer Color = White for all viewer types (need to revise this with new roll-over color bar)]]
  
 
** Question: Will we have more than one active viewer?
 
** Question: Will we have more than one active viewer?
  
[[image:SlicerViewers-Hi2.png | Active Viewer Color = White ]]
+
[[image:SlicerViewers-Hi2.png |thumb|px400| Mock-up from 8/02: Active Viewer Color = White for all viewer types (need to revise this with new roll-over color bar)]]
 +
 
  
 
** Lighten display up: if GUI panels are collapsed by default, and only expose on rollover, then we don't need to tie the image viewer to the color bar with a hairline of the same color. We can just use a just-noticeable grey divider which turns white on highlight. This may clean up the overall appearance a bit.
 
** Lighten display up: if GUI panels are collapsed by default, and only expose on rollover, then we don't need to tie the image viewer to the color bar with a hairline of the same color. We can just use a just-noticeable grey divider which turns white on highlight. This may clean up the overall appearance a bit.
 
+
[[image:SlicerViewers-Hi3.png |thumb|px400| Mock-up from 8/02: Cleaner viewer appearance (need to revise this with new roll-over color bar)]]
[[image:SliceViewers-Hi3.png | cleaner viewer appearance]]
 
 
 
  
 
** Draft palette for viewer colors against which developers register (still working on this guy...)
 
** Draft palette for viewer colors against which developers register (still working on this guy...)
  
[[image:SlicerViewerColors.png | Draft Palette ]]
+
[[image:SlicerViewerColors.png | thumb|px400| Draft Palette ]]
  
 
* '''Summary from tcon discussion 8/2/2011:''' Three types of "colors" in Slicer4
 
* '''Summary from tcon discussion 8/2/2011:''' Three types of "colors" in Slicer4
Line 61: Line 61:
 
Question remains on which category color-styling of vtk widgets falls under (e.g. colors of widget handles and highlights.
 
Question remains on which category color-styling of vtk widgets falls under (e.g. colors of widget handles and highlights.
 
(more notes to come...)
 
(more notes to come...)
 
  
 
= Guidelines for Developers of New Viewers =
 
= Guidelines for Developers of New Viewers =

Revision as of 15:42, 5 August 2011

Home < Slicer4:ViewerDesign

Back to Slicer 4 Developer Projects

Project Description

Ron would like to see a scalable architecture for the visual appearance of Slicer viewers as we add more types of elements and more of them. This architecture will also need to be able to accommodate new types of viewers such as graphs and tables.

We would also like to prepare a guide for developers of new types of viewers:

  • that ensures that all viewers have a consistent visual and interaction design,
  • and that makes it simpler for a developer to implement their viewer.

Notebook for Slicer 4 Presentation Layer Design

Notes & Sketches (Chronologically listed)

On Color-coding viewers & Qt Colors

Slicer default appearance as of 7-32: Slim-line color bars with sliders and pop up
  • (from Jim) Many of the viewers we are using colors from the Qt palette. The viewer "name" is color alias that is recognized by Qt. But it doesn't need to be this way. We could always go through a lookup to map viewers with nonstandard color names as the viewer name to a RGB triple. We'll just need to slip in that mapping in the appropriate places. Qt accepts "named colors" from the SVG color keywords. See http://www.w3.org/TR/SVG/types.html#ColorKeywords. Qt can also take ANY color specified as RGB, HSV, etc. components.
  • (from Julien) There are 2 kinds of palettes:
    • a general "Qt application GUI" palette (color of the background, buttons, text, shadings, highlight color). This is QPalette.
    • a Slicer/MRML specific palette: color of the slice views, renderer background color of the 3D view, highlight of current view (slice or 3D). For now there is no placeholder for such a palette. I somewhat started to gather them in qMRMLColors.h/cxx. However, I believe it should be a VTK/MRML palette. Where MRML could provide a default palette, that can be extended/replaced by a Slicer palette.
  • (from Julien) I've noticed there has been some work done in the past to allow such kind of feature: Slicer4\Modules\Meshing\BuildingBlock\vtkSlicerColor.h/cxx. I'm not sure in what extend we could reuse/generalize that work. For information, vtkMRMLViewNode already hardcodes the light blue background color.
  • (question from Julien) Shall we make such a palette a singleton in MRML, or should it be a vtkMRMLScene member, other ideas ?
  • (from Jim) The colors for the various viewers feels more like "application settings" or "look and feel" than MRML. I don't feel strongly about this but I wonder if the colors just need to be accessible from the Application object. I guess since we store things like the layout in MRML, it would make sense for the available colors to decorate the UI also be established in MRML.


  • (from Wen) A first suggestion for how to color-code and ID viewers -- straw man for discussion:
Mock-up from 8/02: Viewer type color coding and ID
    • Keep Slicer Axi/Sag/Cor color coding, and all other individual slice viewers are grey
    • Keep Compare Viewers Orange
    • Make 3D viewers blue (better shade than in mockup!)
    • darken down the hairline frame around all viewers so "active" viewer is more apparent.
    • Multiple viewers of same viewer-type get a numerical ID
    • Create list of colors that developers register new viewer types to...
    • Helper code to create a viewer frame with same appearance & behavior
Mock-up from 8/02: Active Viewer Color = White for all viewer types (need to revise this with new roll-over color bar)
    • Question: Will we have more than one active viewer?
Mock-up from 8/02: Active Viewer Color = White for all viewer types (need to revise this with new roll-over color bar)


    • Lighten display up: if GUI panels are collapsed by default, and only expose on rollover, then we don't need to tie the image viewer to the color bar with a hairline of the same color. We can just use a just-noticeable grey divider which turns white on highlight. This may clean up the overall appearance a bit.
Mock-up from 8/02: Cleaner viewer appearance (need to revise this with new roll-over color bar)
    • Draft palette for viewer colors against which developers register (still working on this guy...)
Draft Palette
  • Summary from tcon discussion 8/2/2011: Three types of "colors" in Slicer4
    • Qt application "skin" which can be selected through an Application Settings interface. This includes background, buttons, text, shadings etc. This is a QPalette.
    • Slicer reserved colors that should-not be adjusted by the user.
      • Colors of the roll-over bar on specific viewer types (Slice Red, Yellow, Green for example) should not change. This permits all Slicer users to discuss presentation of data in a consistent way, independent of how Slicer's presentation layer is styled.
    • MRML-specific colors that are restored with the scene. This includes 3D view background color, Fiducial color, etc.

Question remains on which category color-styling of vtk widgets falls under (e.g. colors of widget handles and highlights. (more notes to come...)

Guidelines for Developers of New Viewers