Summary: | [Perspectives] Closed secondary-id views, when restored do not go to their place-holder folder-layouts | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | DC <mahesh.dc> | ||||
Component: | UI | Assignee: | Wim Jongman <wim.jongman> | ||||
Status: | ASSIGNED --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P5 | CC: | charles, daniel_megert, kalyan_prasad, mistria, n.a.edgar, remy.suen, wim.jongman | ||||
Version: | 3.0.2 | Keywords: | helpwanted | ||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
DC
2005-07-08 20:07:32 EDT
Created attachment 24512 [details]
Test example
Here's an example of what I am trying to do.
Scenario-1:
Create a couple of views by clicking on the button and then close them
both
The FixedView expands to take the entire area
Create another view by clicking on the button, the new view shall come in
the same place as the fixed view, though its placeholder is different
Scenario-2:
The example that I have given does not provide this scenario, but I shall
try and explain what happens.
In this example, the secondary-ids are different for each new view. I
have a case where the secondary-ids could be fixed ...
The first view with multi-support works fine
If you close it and then create a multi-support view with a different
secondary-id it goes to the fixed-view location(same as scenario-1)
In general what I have seen is, if a view with a secondary-id has been
created such that atleast one multi-support view exists in the place-holder
place, and you close and open it ... it goes to the right location.
However if you create a view with a unique secondary-id at a time when no
views exist in the placeholder view, then they would appear in the fixed view
area. The first multi-support view is an exception to this rule.
Will investigate for 3.2 M1. The following invariants should hold: - if there's a placeholder for the view, it should match, with more specific placeholders matching first (e.g. "someView:*" should win over "*") - when a view is closed a placeholder for its specify id and/or secondary id takes its place; so if folder F has placeholder V:*, then view V:1 will be created there, if it's then moved to folder G, then closed, then V:1 will reappear in G if it's reopened, but V:2 will still appear in F - if there is no matching placeholder, the view appears in the folder at bottom right (creating the folder if necessary) 1st point) I am not sure, if I understood it. 2nd) I agree with it 3rd) I have an alternate idea. Is it good idea to have the option of creating a placeholder folder that's always present ? createPlaceHolderFolder (alwayson=true); This can be something like the editor area, which is always on unless explicitely turned off. But when present, all the editors open in this area. The advantage with this is also that, when all the views in the folder are closed, the other folders do not eat-up that area and this folder is always visible! Moving this bug to 3.2 M2. Deferring to M3. Deferring to M4. Eric, can you include this one in your placeholder investigations? Deferring to M5... Ran out of time...deferring to M6. I've been doing placeholder investigation, I'll take it. PW Is this still a problem in 3.3? PW This bug is important to us as it causes our RCP application to look a little on the non-professional side because views don't go where we expect them to. So I need to ask what "RESOLVED REMIND" means? Is there some timeframe where this might be fixed? Also, I am curious as to the reason this bug was put into that state. Is it too hard to fix, will be fixed as part of some other reorganization? Finally, is there a workaround? If not, can you point me to the code that needs to modified or provide some direction on the issues involved in fixing this? (In reply to comment #11) > I need to ask what "RESOLVED REMIND" means? Is there some timeframe where this > might be fixed? These are bugs that have no plan item (and so no one is looking at them). But your interest is enough to "REMIND" and so it will be re-opened. But there is still no one looking at the code in this area. > > Finally, is there a workaround? If not, can you point me to the code that needs > to modified or provide some direction on the issues involved in fixing this? AFAIK, there's no work around. The code that's doing this is around Perspective, PerspectiveHelper, ViewPane, and ViewFactory (all in org.eclipse.ui.workbench). I suspect that the placeholder created in PerspectiveHelper#removePart(*) doesn't contain the correct information, but I'm not sure what's going on there. Feel free to update this report with any findings or questions. PW I'm facing this issue as well. I'm forced to work with 4.4 which still has this bug. I will check but I'm pretty sure it has never been solved. The plan is to solve this following Nick's outline in comment 2. For people facing this issue, this is the workaround I currently use. when your view id is view.id and your secondary id's are SID-0,SID-1,,SID-9 (depending on how many simultaneous parts you expect ("the family")) you can make the following perspective extension: See attachment "extension" Then when you need to open a view you can use something like this. This method searches for an available view in the family. If findview returns null, we know that we have a free spot because the user closed the view. int fSecondaryIdCounter = 0; ViewPart getNewView(){ String viewID = "view.id" IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); if (window != null) { try { IWorkbenchPage page = window.getActivePage(); if (page != null) { // see if primary is available ViewPart view = page.findView(viewID); if (view == null) { return page.showView(viewID); } // find if previous secundaries were closed for (int i = 0; i < fSecondaryIdCounter; i++) { view = page.findView(createViewID(viewID, i)); if (view == null) { return page.showView(createViewID(viewID, i)); } } // next secundary return page.showView(viewID, "SID-" + fSecondaryIdCounter++, IWorkbenchPage.VIEW_ACTIVATE); } } catch (PartInitException e) {} } return null; } private static String createViewID(String viewID, int i) { return viewID + ":" + "SID=" + i; } @Wim: do you still plan to work on this? (In reply to Mickael Istria from comment #15) > @Wim: do you still plan to work on this? Yes. Kalyan, can you also take a look at this issue? It is from 2005 but is still a bug today. |