Community
Participate
Working Groups
The use case for this is that I have two views that I want to have stacked on the left hand side of the workbench. The two views are provided by different plugins and one of them might not be available in certain installations (but could be installed later). So, I have: ViewA (VIEW_SERVER_ADMIN below) - Always available in the base framework ViewB - Only available if installed - Added to perspective via perspective extension Case 1 - Both views available - Initial perspective only shows ViewB by default via perspective extension. ViewA can be made visible by menu bar action. Case 2 - Only ViewA is available - ViewA is visible by default. The perspective code I'm using for this is: public void createInitialLayout(IPageLayout layout) { layout.setEditorAreaVisible(true); IFolderLayout explorersFolder = layout.createFolder( ID_EXPLORERS_FOLDER, IPageLayout.LEFT, 0.30f, IPageLayout.ID_EDITOR_AREA); layout.addView( IPageLayout.ID_PROP_SHEET, IPageLayout.BOTTOM, 0.75f, ID_EXPLORERS_FOLDER); if (!isContentExplorerAvailable()) { explorersFolder.addView(ICommonViewIdentifiers.VIEW_SERVER_ADMIN); } else { explorersFolder.addPlaceholder(ICommonViewIdentifiers.VIEW_SERVER_ADMIN); } } The bug appears in Case 1 when the menu bar action is run to make ViewA visible. In this case, the above code would have created a placeholder in the folder to make sure the the view is opened up stacked along with ViewB. In this case, the action calls IWorkbenchPage#showView to open or raise the view to the top. The #showView call doesn't do anything. After tracking through the code, it appears that this fails in PerspectiveHelper#addPart because the call to PartPlaceholder#getContainer is returning null. This does not cause a NPE. On line 286 of PerspectiveHelper (in 3.1) there is a call to get the container. On the next line, the container is checked and if it is null, the part is not added. It is unclear to me at what point the container should have been set into the PartPlaceholder instance, but since this is entirely out of control of my code it seems like there is a bug somewhere. Although I think this usecase should work and is currently broken, I would appreciate workaround ideas. I need to get this use case going on Eclipse 3.1.
private static final String ID_EXPLORERS_FOLDER = "ID_EXPLORER"; public void createInitialLayout(IPageLayout layout) { layout.setEditorAreaVisible(true); IFolderLayout explorersFolder = layout.createFolder( ID_EXPLORERS_FOLDER, IPageLayout.LEFT, 0.30f, IPageLayout.ID_EDITOR_AREA); layout.addView(IPageLayout.ID_PROP_SHEET, IPageLayout.BOTTOM, 0.75f, ID_EXPLORERS_FOLDER); explorersFolder .addPlaceholder(IPageLayout.ID_BOOKMARKS); } I ran scenario 2 with the above code as a PerspectiveFactory (i.e. a new perspective). It creates a screen where A is an empty folder with a placeholder for Bookmarks, B is the properties sheet, and C is the empty editor area. ------- |A|C | | | | --- | |B| | ------- If I use Window>Show View>Other...>General>Bookmarks, A get's replaced with the bookmark view. Is your createInitialView() part of a perspective extension? If so, an extension on which perspective? PW
The createInitialLayout is implemented in an implementation of IPerspectiveFactory. The part that your example is missing is that there is another view (call it X) that is added to the folder via a perspective extension. <perspectiveExtension targetID="com.spss.mgmt.common.ui.defaultManagementPerspective"> <view id="com.spss.mgmt.content.ui.views.RepositoryView" relationship="stack" relative="com.spss.mgmt.common.ui.explorersFolder" visible="true"/> </perspectiveExtension> If this plugin is available, then this view will always be showing by default in the folder.
Let me recap my test scenario to make sure it's correct. 1. I create a perspective with a folder and in the folder a placeholder for BOOKMARKS. 2. I create a perspective extension that stacks TASKS on the folder with the placeholder. Question: should I stack on the folder or stack on BOOKMARKS? 3. I open the perspective, and then Show View>BOOKMARKS. I'll attach a patch of my test scenario (it can be done from one plugin), and do some testing on 3.1.1 next week. On 3.2, I can't even open the perspective in this scenario, it destroys my presentation. I'm guessing that this needs further investigation :-) PW
Created attachment 31412 [details] Perspective added to tests This adds the perspective and perspective extension to the org.eclipse.ui.tests plugin. If you load the test plugins and self-host, you can select the perspective and demonstrate (for 3.2) the presentation problem. PW
Is this still a problem in 3.3? PW
I'm no longer working on the product that had this problem. I'm not sure if it is still a problem in 3.3.
Oh, this is the standard "can't stack in a folder" problem. PW
*** Bug 156482 has been marked as a duplicate of this bug. ***
I don't understand how you meant that with "the standard "can't stack in a folder" problem". Unfortunate for me, this is exactly what I used to do with 3.1 and which is what I can't seem to do anymore in 3.2 and 3.3. (I refer to the bug that you marked as duplicate: id=156482) Since 3.2, I can no longer create my layout using empty folders, and then stack on these folders in perspective extensions. In 3.1, we used to do that excessively :) Is it the designs idea, that I need to place a view (or at least a placeholder) into each folder, so that I stack on the folders?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
