Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313771

Summary: perspective switcher - pure model manipulation vs. compatibility layer
Product: [Eclipse Project] e4 Reporter: Susan McCourt <susan>
Component: UIAssignee: Project Inbox <e4.ui-inbox>
Status: CLOSED DUPLICATE QA Contact: Eric Moffatt <emoffatt>
Severity: normal    
Priority: P3 CC: elias, emoffatt, jdsalingerjr, pwebster, remy.suen
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
Patch to allow close/reset of perspective none

Description Susan McCourt CLA 2010-05-20 13:01:59 EDT 
in bug 308102 we now have a bare bones perspective switcher. 
I am looking at adding more functionality to it, similar to the menus available on perspectives in 3.6.  Closing, resetting, customizing, etc....

As it is now, switching between perspectives can happen in a "pure e4 model" way...we change the selected element in the perspective's parent.

But the more advanced things are current implemented in the compatibility layer using the old perspective registry and IPerspectiveDescriptor.

It's not even clear to me where to get the perspective's icon besides IPerspectiveDescriptor.

The choices I see are:
- move the switcher to the compatibility layer and use old/familiar code to populate the switcher, manipulate the perspectives, etc.
- separate the switching UI part of the UI from the ability to add actions to it.  It still means, though, that the compat code would have to know which IPerspectiveDescriptor is in question (rather than MPerspective).  And it's still not clear to me how the UI-only part would get the icons

I haven't studied how the perspective code on the model side integrates in the compatibility layer...
Comment 1 Susan McCourt CLA 2010-05-20 21:21:23 EDT 
The changes I released for bug 308102 are really reachy, hacky, and for the most part random.  Hacks include:

- there are assumptions that there is only one perspective stack
- reaching all over workbench internals to get necessary parameters like the current workbench page, etc.  
- casting to internal classes, etc.
- using a SelectPerspectiveDialog directly to implement the "open" behavior on the perspective switcher.  We probably should be doing something different, perhaps the 3.6 behavior where there is a menu with the current shortcuts.

Basically, similar kind of hacks and internal code to that found in WorkbenchPage.  So we need to decide where all this compatibility should live and whether we should factor a helper or something for both the page and the switcher to use.

Note also that I did a small reorg of WorkbenchPage to move perspective tagging to a separate class so that my switcher could use it rather than copying that whole wad....
Comment 2 Eric Moffatt CLA 2010-05-21 14:01:38 EDT 
Committed in >20100521. Commented out the code for 'Reset' and 'Close' since they were leaving the model in a corrupt state.

Fixed a layout issue when switching the 'show text' option.
Comment 3 Susan McCourt CLA 2010-05-21 17:18:36 EDT 
not directly related to model/compat issues, but since is really about "cleanup" of the switcher...

the menu code in the M6 switcher creates a menu on every menu detect and disposes it on dismissal.  need to decide if this makes sense.  (the menu is different depending on whether the persp is the selected one or not, but we could decide to cache the menu for each tool item and clear it if the selection state for the toolitem changes so that it will be recomputed).
Comment 4 Eric Moffatt CLA 2010-06-09 11:16:36 EDT 
Created attachment 171539 [details]
Patch to allow close/reset of perspective
Comment 5 Eric Moffatt CLA 2010-06-09 11:17:55 EDT 
Committed in >2010009. Applied the patch.
Comment 6 Eric Moffatt CLA 2010-06-09 11:21:50 EDT 
(In reply to comment #3)
> could decide to cache the menu for each tool item and clear it if the selection
> state for the toolitem changes so that it will be recomputed).

Susan, the only reason to cache would be if reconstruction was expensive. In this case it's well under a millisec so I don't think it's an issue.
Comment 7 Eric Moffatt CLA 2010-06-21 11:21:02 EDT 
For now we'll go with the 'compatibility only' story. We can always whip up a model-only version for e4 RCP apps.

I'm somewhat tempted to rig up some helper classes for the different types of events we handle from the UI Model but that would be post-release.
Comment 8 Joseph Carroll CLA 2012-07-19 16:25:12 EDT 
Should this be moved under bug 385547 ?
Comment 9 Paul Webster CLA 2012-07-20 10:00:59 EDT 

*** This bug has been marked as a duplicate of bug 385547 ***