Community
Participate
Working Groups
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...
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....
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.
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).
Created attachment 171539 [details] Patch to allow close/reset of perspective
Committed in >2010009. Applied the patch.
(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.
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.
Should this be moved under bug 385547 ?
*** This bug has been marked as a duplicate of bug 385547 ***
