Skip to main content
Jump to: navigation, search

Platform UI/Multi-instance Properties View

< Platform UI
Revision as of 11:47, 8 December 2008 by (Talk | contribs) (Ideas/Use cases/Requirements for multi-instance Properties View (PV) {{bug|248103}}:: Add use cases.)

Brainstorming bug 248103:

  • Pin PV to current selection (stop following selection)
  • Inherit parents settings (For PV org.eclipse.ui.part.WorkbenchPart.getPartProperties() might be an option)
  • Inherit parents input (requires API to get the Input from the parent)
    • Setting parents state/input requires additional API whereas freezing (pinning) the parent and opening a "fresh" PV wouldn't require any additional API
    • The console view for example gets the parents content in org.eclipse.ui.internal.console.ConsoleView.consolesAdded(IConsole[])
  • New one has focus?
  • Open the new view either on the same stack or else where? (If the user wants to compare two objects, a stacked view doesn't fit)
  • Back and forward buttons to navigate between the property view instances
  • Multiple PV instances are still restorable?
    • Only restore the master property view (the first one)?
    • Only restore property view instances which are pinned?
    • Restore all property views
  • Open the properties view from the context menu of the current selection (show in) (Object id might be used for secondary view id).
  • When a second view is opened from the original view, what should happen? Should the original stop following selection or should the second one?

Use cases

  • pinning selection
Allowing a user to pin the view to a given selection provides the user with the capability of see the properties of the given selection while providing them with the freedom to select alternate items. The current 'Properties' view implementation "always" follows the current workbench's selection and prevents the user from multitasking.
  • multiple instances
By letting the user spawn multiple instances of the 'Properties' view, they are now able to compare the properties of N+1 items. This is different from the Compare framework's textual compare as the information provided in the 'Properties' view is defined by the selection's adapted IPropertySource and is often not the textual content of the selection, if the selection even has textual content.
  • secondary instances hidden upon workbench shutdown
Any secondary instances of the 'Properties' view are hidden upon workbench shutdown. Note that other views provided by the SDK currently stay up.
  • spawning instances via the 'Show In' context menu
Users can use the 'Show In' context menu as they are currently familiar with to display the current selection in a 'Properties' view. A new view will be constructed if all current views are set to be pinned or there are no 'Properties' view in the current perspective.
  • constructing new instances from the 'Properties' view itself
A user can also create new instances of the 'Properties' view from an existing one. The existing one will be pinned to the contents it is currently displaying and the new instance will be set to follow the workbench's selection.

Existing behaviour

View Open secondary instance by Inherit parent's content Inherit parent's settings Same "input" opens new view Name new instance


Pin parent and rerun search no no  ? no


Pin and call Team > Show History on a different resource no yes  ? no


"New" button View toolbar  ? yes  ? no


"New ... View" from View menubar yes¹ no n/a yes


"New ... View" from View menubar yes¹ no n/a yes


"New ... View" from View menubar yes¹ no n/a yes


"New ... View" from View menubar yes¹ no n/a yes


Can be opened explicitly yes  ?  ?  ?

¹ Content comes from workspace

Use cases bug 248103#c12

Compare properties of two or more resources in the workbench Prakash's Blog

Back to the top