Bug 103239 - [Perspectives] Closed secondary-id views, when restored do not go to their place-holder folder-layouts
Summary: [Perspectives] Closed secondary-id views, when restored do not go to their pl...
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0.2   Edit
Hardware: All All
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: Wim Jongman CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2005-07-08 20:07 EDT by DC CLA
Modified: 2020-01-03 09:33 EST (History)
7 users (show)

See Also:


Attachments
Test example (11.53 KB, application/x-zip-compressed)
2005-07-09 02:55 EDT, DC CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description DC CLA 2005-07-08 20:07:32 EDT
Hi,

Though the subject says most of it ... here's the problem I am facing.

I have created a IPlaceholderFolderLayout for a view(let's say view1) that can 
appear multiple-times(thru ActivePage.showView(id, second-id, flag) )

When the views(view1) are initially created, they appear correctly in the 
placeholder that I have assigned to them. 

Now, if these views(view1) are closed, then another view(view2) in another 
normal IFolderLayout expands to take up the entire workbench area ... thats 
still okay & normal !

However, if I re-create my first view1(multiple-enabled), they will not go to 
their designated placeholder .. but rather and wrongly to the view2's layout.

This problem does not occur when I am not creating it using secondary-ids. 
However, I cannot then have multiple views :-(

To summerize, multiple enabled view(s) when closed and re-opened later do not 
go to their place-holder.

By the way, I am using 3.0.2. I tried to use 3.1 (I don't know if this problem 
is solved there..) but it required many changes in my code .. which is a bit 
difficult at this moment.

Is there a work-around for this problem on 3.0.2 or have I missed something ?

Many thanks ! 
-dc
Comment 1 DC CLA 2005-07-09 02:55:11 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.
Comment 2 Nick Edgar CLA 2005-07-11 12:52:28 EDT
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)
Comment 3 DC CLA 2005-07-11 13:25:13 EDT
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! 

Comment 4 Douglas Pollock CLA 2005-08-08 11:17:04 EDT
Moving this bug to 3.2 M2. 
Comment 5 Nick Edgar CLA 2005-09-19 11:08:26 EDT
Deferring to M3.
Comment 6 Nick Edgar CLA 2005-10-28 10:09:46 EDT
Deferring to M4.
Eric, can you include this one in your placeholder investigations?
Comment 7 Eric Moffatt CLA 2005-12-13 16:33:29 EST
Deferring to M5...
Comment 8 Eric Moffatt CLA 2006-02-13 14:13:38 EST
Ran out of time...deferring to M6.
Comment 9 Paul Webster CLA 2006-02-14 08:06:41 EST
I've been doing placeholder investigation, I'll take it.

PW
Comment 10 Paul Webster CLA 2006-09-28 15:15:14 EDT
Is this still a problem in 3.3?

PW
Comment 11 Charles Tuckey CLA 2006-09-29 15:21:10 EDT
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?
Comment 12 Paul Webster CLA 2006-09-29 15:34:01 EDT
(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
Comment 13 Wim Jongman CLA 2019-05-11 10:55:31 EDT
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.
Comment 14 Wim Jongman CLA 2019-05-24 16:31:29 EDT
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;
 }
Comment 15 Mickael Istria CLA 2019-08-19 11:29:08 EDT
@Wim: do you still plan to work on this?
Comment 16 Wim Jongman CLA 2019-08-20 10:02:14 EDT
(In reply to Mickael Istria from comment #15)
> @Wim: do you still plan to work on this?

Yes.
Comment 17 Wim Jongman CLA 2020-01-03 09:33:24 EST
Kalyan, can you also take a look at this issue? It is from 2005 but is still a bug today.