Community
Participate
Working Groups
The use case is as follows: Create a perspective using the addContribution method of the IExtensionRegistry interface. Save the perspective state when the platform is shutdown. Restart the platform, load the perspective and try to reset it. The reset does not change the UI back to the original definition. The problem is because the reset code needs to re-create the IPerspectiveFactory object and it never does because the configElement for the PerspectiveDescriptor is always null. This is because the original perspective was created using a dynamic extension and is not persisted across restarts. One possible solution would be to include the following in the PerspectiveDescriptor code: public IPerspectiveFactory createFactory() throws CoreException { // if there is an originalId, then use that descriptor instead if (originalId != null) { // Get the original descriptor to create the factory. If the // original is gone then nothing can be done. IPerspectiveDescriptor target = ((PerspectiveRegistry) WorkbenchPlugin .getDefault().getPerspectiveRegistry()) .findPerspectiveWithId(originalId); return target == null ? null : ((PerspectiveDescriptor) target) .createFactory(); } /***************************************************************** * Code that could be added to attempt to find a matching config * element for the perspective id. ****************************************************************/ if (configElement == null) { IExtensionRegistry registry = RegistryFactory.getRegistry( ); IConfigurationElement[] elements = registry.getConfigurationElementsFor("org.eclipse.ui.perspectives"); for (int idx = 0; idx < elements.length; idx++) { String perspId = elements[idx].getAttribute("id"); if (perspId != null && perspId.equals(this.id)) { configElement = elements[idx]; break; } } } // otherwise try to create the executable extension if (configElement != null) try { return (IPerspectiveFactory) configElement .createExecutableExtension(IWorkbenchRegistryConstants.ATT_CLASS); } catch (CoreException e) { // do nothing } return null; } The other issue is the inability to determine if a perspective has a custom definition without using the internal API. It would be beneficial to make public the hasCustomDefinition method in order to know whether or not this is a saved perspective descriptor and whether or not the consumer needs to delete it. Since dynamic extensions are not persisted, every time the platform loads, a new perspective descriptor needs to be created for that perspective if we are not using the saved state.
Marking down from critical as this is not going to get into 3.2 - we are too far into the final release cycle and this is a potentially dangerous change that we would need to have around for a while to make sure it has no unforseen side effects. However we should look at a solution for 3.2.1. Chuck I suggest that you run with a patched version of the workbench to be sure that all of the cases you are concerned about are covered by your changes. When you are satisfied if you could attach a patch to this bug we can look at any possible implications for 3.2.1.
Chuck have you tried running with a patched version of the workbench jar? We need to be sure that this is the last issue in this space before we proceed.
So basically, I have been able to solve most of our issues using the savePerspectiveAs method and clonePerspective. The only problem now is the ability to completely rebuild a perspective at runtime. So, in other words, we need the ability to have the createInitialLayout for the perspective class to be invoked again and have the descriptor replaced. I thought that resetPerspective would have done this, but it doesn't. revertPerspective doesn't work on a custom perspective which is what this is. It seems like we would need an additional api like rebuildPerspective which just completely rebuilds the perspective from the factory.
Chuck is it possible for you to whip a something that creates a perspective using the addContribution that demonstrates your case so that we can look at it here on our side. The API freeze was M6 so we are not going to do anything like that for 3.2 and will try to do an absolute minimum of them for 3.2.1.
Removing 3.2.1 milestone as we are going to need some more input before we can go ahead on this.
Chuck I am still awaiting a response on this (since June 6).
(In reply to comment #6) > Chuck I am still awaiting a response on this (since June 6). Hi Todd, I cameup with a way to do it. In the future, it would be great to just have an api that forces a perspective refresh. Basically I did this by closing it, deleting it, then re-opening it.
Please attach a patch with your suggested changes should you still need this
(In reply to comment #7) > (In reply to comment #6) > > Chuck I am still awaiting a response on this (since June 6). > > Hi Todd, > > I cameup with a way to do it. In the future, it would be great to just have an > api that forces a perspective refresh. Basically I did this by closing it, > deleting it, then re-opening it. > Sounds like the only remaining issue left in this bug was refreshing a perspective. Based on the availability of a workaround and the age of this bug, I'm going to close as WORKSFORME.