Jump to: navigation, search

Difference between revisions of "Platform UI Design Discussion"

(Thoughts)
(Thoughts)
Line 34: Line 34:
 
   Editor
 
   Editor
  
Implement 'Minimized View Bar' support? These would be slightly different in that selecting a view from the bar would restore that part site for the view (or its stack?) and that this would stay until the bar was used again to 'collapse' it (as opposed to the more immediate mode of fast views). Are these simply new PartSites for a ViewStack?
+
Implement 'Minimized View Bar' support? These would be slightly different in that selecting a view from the bar would restore that part site for the view (or its stack?) and that this would stay until the bar was used again to 'collapse' it (as opposed to the more immediate mode of fast views).
 +
 
 +
Are these simply new PartSites for a ViewStack? If so and we can also that the Fast View Bar is a PartSite then we may be able to simplify some of the current issues in the presentation layer as well since both Fast Views and DetachedWindows are currently treated as 'special' elements in the structure.
  
 
Implement 'auto minimize bars' It would be possible to convert existing view stacks into 'Minimize View bars' in the trim when the editor  (EditorArea?) is maximized.
 
Implement 'auto minimize bars' It would be possible to convert existing view stacks into 'Minimize View bars' in the trim when the editor  (EditorArea?) is maximized.

Revision as of 15:08, 12 June 2006

A discussion about generalizing and simplifying core Workbench concepts.

Discussion Areas

  • grouping
  • appearance
  • connections
  • nesting
  • fixing the broken minimize
  • fast views, multiple fast view bars

Use Cases

  • Debugging client and server at the same time (each with its own Debug view, Variables view, etc)
  • Maximizing the editor area, not just one editor
  • Easily minimize everything except the editor area and the outline view

Separation of Concerns

Overall it seems that there are two concerns that we would like to separate:

  • How are the pieces that make up the workbench (window, views, editors, trim, ...) composed, and how are they connected?
    For this, we focus on questions like:
    • Which services (selection, key binding, etc.) does a piece need, and where does it get it from?
    • What does a piece (mostly: view, editor) contribute in terms of menus, toolbar items, context menu, trim items?
    • etc
  • How are the pieces presented, using a common layout, based on policy decisions for their placement?
    Here we answer questions like:
    • Where in the UI do the pieces show up? Where do contributed items show up?
    • Which pieces can be rearranged and moved by the user, and in which way?

Thoughts

Eventually, we need a story for getting back the old behaviour. Let's not worry about that too much for now.

Why does trim not show up in the class hierarchy for views and editors, e.g. as in:

Piece
 Trim
 Part
  View
  Editor

Implement 'Minimized View Bar' support? These would be slightly different in that selecting a view from the bar would restore that part site for the view (or its stack?) and that this would stay until the bar was used again to 'collapse' it (as opposed to the more immediate mode of fast views).

Are these simply new PartSites for a ViewStack? If so and we can also that the Fast View Bar is a PartSite then we may be able to simplify some of the current issues in the presentation layer as well since both Fast Views and DetachedWindows are currently treated as 'special' elements in the structure.

Implement 'auto minimize bars' It would be possible to convert existing view stacks into 'Minimize View bars' in the trim when the editor (EditorArea?) is maximized.

Should we integrate the View/Stack dragging capability to extend to dragging a View/Stack directly into the trim areas (as we now support for Fast View Bar)? Dropping into the Trim Area would create a 'Minimized View Bar' as described above.

Should the maximize for editors apply to the editor specifically or to the EditorArea as a whole? There's some merit in the latter because you cannot currently use this functionality to see two ediors at once (folks using tiled editors are even more likely to want to maximize since eash editor gets less screen real estate).