Jump to: navigation, search

Difference between revisions of "Platform UI Design Discussion"

(Separation of Concerns)
(Separation of Concerns: Update)
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{Platform UI}}
 
A discussion about generalizing and simplifying core Workbench concepts.
 
A discussion about generalizing and simplifying core Workbench concepts.
  
Line 6: Line 7:
 
* connections
 
* connections
 
* nesting
 
* nesting
* fixing the broken minimize
+
* MarkersViews [[Platform_UI_MarkersView]]
* fast views, multiple fast view bars
+
  
 
= Use Cases =
 
= Use Cases =
 
* Debugging client and server at the same time (each with its own Debug view, Variables view, etc)
 
* 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
 
 
* Define an eclipse presentation suitable for a Cell Phone (ensures presentation generality)
 
* Define an eclipse presentation suitable for a Cell Phone (ensures presentation generality)
  
 
= Separation of Concerns =
 
= Separation of Concerns =
 
Overall it seems that there are two concerns that we would like to separate:
 
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?<br>For this, we focus on questions like:
+
* How are the pieces that make up the workbench (window, views, editors, trim, ...) composed, and how are they connected?<br  
 +
/>For this, we focus on questions like:
 
** Which services (selection, key binding, etc.) does a piece need, and where does it get it from?
 
** Which services (selection, key binding, etc.) does a piece need, and where does it get it from?
 
*** Menus - programmatically through the site and IActionBars
 
*** Menus - programmatically through the site and IActionBars
Line 27: Line 26:
 
*** Keybindings (sorta) - programmatically through the site and IBindingService (or the old IKeybindingService)
 
*** Keybindings (sorta) - programmatically through the site and IBindingService (or the old IKeybindingService)
 
** What does a piece (mostly: view, editor) contribute in terms of menus, toolbar items, context menu, trim items?
 
** What does a piece (mostly: view, editor) contribute in terms of menus, toolbar items, context menu, trim items?
** etc
+
** etc.
* How are the pieces presented, using a common layout, based on policy decisions for their placement?<br>Here we answer questions like:
+
* How are the pieces presented, using a common layout, based on policy decisions for their placement?<br  
 +
/>Here we answer questions like:
 
** Where in the UI do the pieces show up? Where do contributed items show up?
 
** 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?
 
** Which pieces can be rearranged and moved by the user, and in which way?
Line 36: Line 36:
 
**** Location can be changed using the "Dock On" entry in its context menu
 
**** Location can be changed using the "Dock On" entry in its context menu
 
**** Drag the perspective entries to rearrange them
 
**** Drag the perspective entries to rearrange them
**** Drag an entry outside the workbench window to create a new window showing that perspective
+
**** Drag an entry outside the workbench window to create a new window showing that perspective <small>(not true in version 3.6 or possibly earlier)</small>
 
*** Trim:
 
*** Trim:
 
**** Drag the trim element to any trim area
 
**** Drag the trim element to any trim area
 
*** View Stacks:
 
*** View Stacks:
**** Drag a view/stack to another stack merge the two
+
**** Drag a view/stack to another stack to merge the two
**** Drag a view a 'new' site to create a new stack containing the view (dragging a view ''stack'' this way is a rearrangement since the old stack will disappear once all the views have been moved to the new one).
+
**** Drag a view to a 'new' site to create a new stack containing the view (dragging a view ''stack'' this way is a rearrangement since the old stack will disappear once all the views have been moved to the new one).
 
**** Drag a view/stack outside the workbench to create a Detached Window (only on platforms that support reparenting)
 
**** Drag a view/stack outside the workbench to create a Detached Window (only on platforms that support reparenting)
 
**** Drag a view/stack to the Fast View Bar (FVB) to make all the views in the stack fast views The entries are added at the drop insertion point (i.e. you can drop between two existing icons in the FVB)
 
**** Drag a view/stack to the Fast View Bar (FVB) to make all the views in the stack fast views The entries are added at the drop insertion point (i.e. you can drop between two existing icons in the FVB)
Line 51: Line 51:
 
* org.eclipse.ui.viewActions
 
* org.eclipse.ui.viewActions
 
* org.eclipse.ui.popupMenus
 
* org.eclipse.ui.popupMenus
 +
* org.eclipse.ui.menus <small>(this is destined to replace all four of the above)</small>
  
 
= Thoughts =
 
= 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:
 
Why does trim not show up in the class hierarchy for views and editors, e.g. as in:
 
  Piece
 
  Piece
Line 61: Line 60:
 
   View
 
   View
 
   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? 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).
 
  
 
We should look at the persistence life-cycle. Currently we're in a state where the trim order gets read and applied '''after''' we've already loaded and arranged the trim in its default location. This is clearly non-optimal and leaves us open to flashing etc. Ensuring that all cached info is read and used during the workbench's initial construction might be better.
 
We should look at the persistence life-cycle. Currently we're in a state where the trim order gets read and applied '''after''' we've already loaded and arranged the trim in its default location. This is clearly non-optimal and leaves us open to flashing etc. Ensuring that all cached info is read and used during the workbench's initial construction might be better.
 +
[[Category:Platform UI]]

Latest revision as of 13:11, 25 September 2009

A discussion about generalizing and simplifying core Workbench concepts.

Discussion Areas

Use Cases

  • Debugging client and server at the same time (each with its own Debug view, Variables view, etc)
  • Define an eclipse presentation suitable for a Cell Phone (ensures presentation generality)

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?
      • Menus - programmatically through the site and IActionBars
      • Context menus - programmatically through the site and IActionBars
      • Toolbar items - programmitcally through the site and IActionBars
      • Command handlers - programmatically through the site and IHandlerService
      • Selection service - programmatically through the site and/or workbench page/window
      • Part service - programmatically through the workbench page/window
      • Keybindings (sorta) - programmatically through the site and IBindingService (or the old IKeybindingService)
    • 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?
      • CoolBar:
        • Rearrange groups by dragging (within the CoolBar only)
      • Perspective Switcher:
        • Location can be changed using the "Dock On" entry in its context menu
        • Drag the perspective entries to rearrange them
        • Drag an entry outside the workbench window to create a new window showing that perspective (not true in version 3.6 or possibly earlier)
      • Trim:
        • Drag the trim element to any trim area
      • View Stacks:
        • Drag a view/stack to another stack to merge the two
        • Drag a view to a 'new' site to create a new stack containing the view (dragging a view stack this way is a rearrangement since the old stack will disappear once all the views have been moved to the new one).
        • Drag a view/stack outside the workbench to create a Detached Window (only on platforms that support reparenting)
        • Drag a view/stack to the Fast View Bar (FVB) to make all the views in the stack fast views The entries are added at the drop insertion point (i.e. you can drop between two existing icons in the FVB)
        • Drag a single view icon within the FVB to rearrange. Dragging outside the FVB acts like any other view drag

Things like menus, context menus, and toolbar items are also contributed declaratively through:

  • org.eclipse.ui.actionSets
  • org.eclipse.ui.editorActions
  • org.eclipse.ui.viewActions
  • org.eclipse.ui.popupMenus
  • org.eclipse.ui.menus (this is destined to replace all four of the above)

Thoughts

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

Piece
 Trim
 Part
  View
  Editor

We should look at the persistence life-cycle. Currently we're in a state where the trim order gets read and applied after we've already loaded and arranged the trim in its default location. This is clearly non-optimal and leaves us open to flashing etc. Ensuring that all cached info is read and used during the workbench's initial construction might be better.