Community
Participate
Working Groups
Launch a new workspace with latest 4.3.2 build (M20140117-0910). Exit, and then launch the same workspace with 4.4 (I20140120-2000). => Two Quick Access fields are shown in the window toolbar, and they are both on the right of the perspective switcher. The perspective switcher can be moved to the right again, but I didn't find a way to remove the duplicate Quick Access.
> I didn't find a way to remove the duplicate Quick Access. Found a workaround: Window > New Window. This even works after I saved the perspective in the old window -- this keeps view positions, but removes the second Quick Access.
Most likely this was introduced with bug 411821
(In reply to Thomas Schindl from comment #2) > Most likely this was introduced with bug 411821 Yes, that's where it came from. I can't reproduce it on linux, but I'll try Mac when I get into the office. PW
(In reply to Markus Keller from comment #0) Sorry, I reversed the steps in the original bug description. I'm actually going back to an earlier Eclipse version. I know this is unsupported, but I also know our users regularly do this. Correct steps to reproduce: - Launch a new workspace with I20140120-2000 (4.4 I-build). - Exit, and then launch the same workspace with M20140117-0910 (4.3.2 M-build)
I've implemented Bug 411821 and I had this problem at the beginning of the development and so I've added the method: WorkbenchWindow#cleanLegacyQuickAccessContribution() which should clean the legacy QuickAccess related fields. It could either be that the EModelService#find() doesn't find the legacy elements or their id's have changed. I will try to reproduce it, but if it's a Mac related problem somebody else has to check it.
(In reply to René Brandstetter from comment #5) > > I will try to reproduce it, but if it's a Mac related problem somebody else > has to check it. The problem is in going from 4.4 back to 4.3.2 (which doesn't have any related changes). It might be that we patch back a simple change into 4.3.2 so that it can detect and existing field and not contribute a second one. We have until next Tuesday to decide what to do with it. PW
(In reply to Paul Webster from comment #6) > (In reply to René Brandstetter from comment #5) > > > > I will try to reproduce it, but if it's a Mac related problem somebody else > > has to check it. > > The problem is in going from 4.4 back to 4.3.2 (which doesn't have any > related changes). > > It might be that we patch back a simple change into 4.3.2 so that it can > detect and existing field and not contribute a second one. > > We have until next Tuesday to decide what to do with it. > > PW Sorry, I didn't catch this. What exactly causes this problem? I've tried it with the latest source on my machine and it worked. I did exactly the same procedure as described by Markus with creating a new workspace with a Kepler (Service Release 1 Build id: 20130919-0819) build and opened this new workbench with the latest 4.4 and I didn't get second QuickAccess.
See comment #4 The steps are open a new workspace with 4.4 (Luna). Then close that and open the workspace with one of our Kepler SR2 candidates. PW
(In reply to Paul Webster from comment #8) > See comment #4 > > The steps are open a new workspace with 4.4 (Luna). Then close that and > open the workspace with one of our Kepler SR2 candidates. > > PW Oh now I see, the duplicate QuickAccess happens not from a 4.3 -> 4.4 switch it's the other way round 4.4 -> 4.3. Sorry it took a while for me to get this. There are two possible workarounds for this: * either remove the ".metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi" file form the workspace you want to open * or open the ".metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi" file and remove the 3 child nodes with the elementId "Spacer Glue", "SearchField", and "Search-PS Glue" (<<this is the more surgical solution and will not rest any other settings) After you have chosen one solution open the workbench with the 4.3 and the second QuickAccess element is gone.
Will there be a new service pack for 4.3 into which I can build a rollback step? The Rollback would do the above explained surgical remove. If not we could use a new name for the luna workbench.xmi which will only be used in luna (copied on the first startup of luna) and doesn't touch the kepler file anymore. This solution could be re-used for other problems which are caused by new/switched configurations.
We have about 1 week to contribute a fix to a 4.3.2 service release, on R4_3_maintenance. PW
I will create fix for this and provide the gerrit commit to this bug. René
I've provided a solution for the R4_3_maintenance and it can be reviewed under: https://git.eclipse.org/r/#/c/20970/ I've tested a couple of 4.4 -> 4.3 -> 4.4 switches and wasn't able to find any double QuickAccess elements anymore.
(In reply to René Brandstetter from comment #13) > I've provided a solution for the R4_3_maintenance and it can be reviewed > under: > > https://git.eclipse.org/r/#/c/20970/ Is you patch good for R4_3_maintenance? The review says master. If it was built on R4_3_maintenance and you just accidentally pushed to refs/for/master could you just re-push the review to refs/for/R4_3_maintenance? PW
(In reply to Paul Webster from comment #14) > (In reply to René Brandstetter from comment #13) > > I've provided a solution for the R4_3_maintenance and it can be reviewed > > under: > > > > https://git.eclipse.org/r/#/c/20970/ > > Is you patch good for R4_3_maintenance? The review says master. > > If it was built on R4_3_maintenance and you just accidentally pushed to > refs/for/master could you just re-push the review to > refs/for/R4_3_maintenance? > > PW Hi, I used the R4_3_maintenance branch to build my patch and with https://git.eclipse.org/r/#/c/20974/ it is based on the R4_3_maintenance. Sorry for that. René
The fix should also work if I go back to 4.3 or 4.3.1 or even 4.4 M4.
(In reply to Dani Megert from comment #16) > The fix should also work if I go back to 4.3 or 4.3.1 or even 4.4 M4. This fix won't. The previous build need to be the one looking for the extra model information, so this is targetted at 4.3.2 only. I have another idea I can try. If that doesn't work, I still think it's worth making sure the problem doesn't happen between Luna and Kepler SR2. PW
(In reply to Paul Webster from comment #17) > (In reply to Dani Megert from comment #16) > > The fix should also work if I go back to 4.3 or 4.3.1 or even 4.4 M4. > > This fix won't. The previous build need to be the one looking for the extra > model information, so this is targetted at 4.3.2 only. > > I have another idea I can try. If that doesn't work, I still think it's > worth making sure the problem doesn't happen between Luna and Kepler SR2. > > PW The backward compatibility to the other 4.3.x version was the reason why I made the suggestion in Comment #9 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=426224#c9 --> use a new workbench.xmi for Luna)
(In reply to René Brandstetter from comment #18) > The backward compatibility to the other 4.3.x version was the reason why I > made the suggestion in Comment #9 > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=426224#c9 --> use a new > workbench.xmi for Luna) That's a pretty heavy hammer for a single widget. We probably wouldn't go that way unless we *really* had to. PW
Here's another option that only effects M5. https://git.eclipse.org/r/21002 We set TBR on the contribution to false when we save out the model, but make sure it's true when M5 is running. That way when opened by 4.3.x although the model contribution is there, it won't be available to be used. PW
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=64ca662186334d3d8093d8f09532a6045e7f1a93 PW
If I create a workspace with 4.4.0.I20140123-1600 and then open it with 4.3.1, I get 1 QuickAccess control. But to the right of the perspective switcher. This can be fixed by dragging the perspective switcher back to the right-most control. Once it's fixed it stays fixed. Given that we don't support downgrading workspaces, I think that this is a reasonable "bump". It's also as much as I can do without changing code in previous versions, which still wouldn't fix 4.3.1 or 4.3.0 PW
(In reply to Paul Webster from comment #22) > If I create a workspace with 4.4.0.I20140123-1600 and then open it with > 4.3.1, I get 1 QuickAccess control. But to the right of the perspective > switcher. This can be fixed by dragging the perspective switcher back to > the right-most control. Once it's fixed it stays fixed. > > Given that we don't support downgrading workspaces, I think that this is a > reasonable "bump". It's also as much as I can do without changing code in > previous versions, which still wouldn't fix 4.3.1 or 4.3.0 > > PW That's a good compromise and I like your approach, its far better than mine. BTW if you also want to fix the ordering: Remove the element with the ID "PerspectiveSwitcher" from the model in the Workbench#cleanUpCopy(MApplication appCopy, IEclipseContext context) method. This element will be created anyhow on startup in the WorkbenchWindow#populateTopTrimContributions() method. René
(In reply to Paul Webster from comment #22) > If I create a workspace with 4.4.0.I20140123-1600 and then open it with > 4.3.1, I get 1 QuickAccess control. But to the right of the perspective > switcher. This can be fixed by dragging the perspective switcher back to > the right-most control. Once it's fixed it stays fixed. > > Given that we don't support downgrading workspaces, I think that this is a > reasonable "bump". It's also as much as I can do without changing code in > previous versions, which still wouldn't fix 4.3.1 or 4.3.0 > > PW +1.
