Community
Participate
Working Groups
Seen while verifying bug 387606: Steps to reproduce: 1) Start Eclipse. 2) Close all perspectives 3) Restart Eclipse. 4) Open the default perspective (e.g. Java Perspective) The resulting layout of toolbars is unpredictable. Sometimes they layout after the perspective chooser, sometimes not. Sometimes the order differs from the correct order. Restarting Eclipse a second time renders the toolbars in the correct location, as does opening another workbench window. Reproduced on Windows (32-bit & 64 bit), and on Mac (64-bit) in 4.3-I20130128-2000.
I see similar issue by opening a new perspective, i.e from Java to Debug. As long as the workbench window is small enough, you see the toolbar items are added after the perspective chooser. I am using 4.3M5, on Windows7.
Patrick, could you attach a screen shot of the issue you are seeing ? I've seen Paul's issue but I'm unsure that what you're seeing is the same thing... My suspicion here is that the 'fixZOrder' code isn't triggered during the rendering of the MToolbars, causing a mismatch between the SWT order and the model's...
*** Bug 407455 has been marked as a duplicate of this bug. ***
Created attachment 231604 [details] screenshot Problem persists in I20130516-2200 Not all toolbars are affected.
(In reply to comment #4) I was able to isolate the problem. It is related to the global debug toolbar. When the Debug perspective is opened and I shutdown and restart Eclipse the global debug toolbar (and some other toolbars) appear right of the perspective chooser. If I switch then the perspective the global debug toolbar is still visible (although it should only be visible in the Debug perspective!). When I now shutdown and restart Eclipse (w/o doing anything else) the toolbars are located all correctly and the global debug toolbar only appears in the Debug perspective.
This is really annoying, I'll mark it for release in the first service pack... The problem is most likely that the PartRenderingEnging is not handling toolbars in its 'fixZOrder' code. This code is supposed to ensure that newly rendered elements (i.e. a toolbar just appearing for the first time) are properly placed in the containing composite's collection of 'child' controls...
Created attachment 232490 [details] Naive patch I've noticed that when Toolbars/Trimbars hit the fixZOrder ordering loop they had no widget (kit.getWidget() returned null), so I've relaxed one if condition, which in effect restarts the ordering prevCtrl each time a null widget is found. It works because we are not stuck with prevCtrl (which could be wrong if kid.getWidget returns null) and we use moveAbove rather than moveBelow(invalid reference). I'd really appreciate a comment, as I'm new to this part of Eclipse.
Created attachment 232491 [details] mylyn/context/zip
Thanks Krzysztof, I'll take a look at this once Kepler goes out and we're back to development mode.
Eric, any chance for a review?
Krzysztof, this fix doesn't work for me. Here's how I'm testing... 1) Start Fresh, close Welcome and then the Java Perspective 2) Restart 3) Open the *Debug* perspective (I think that the problem occurs now only if there are new toolbars being added to the model so it's necessary to open a perspective that's never been opened yet...at least if I re-open the perspective I closed before the restart it doesn't exhibit the issue for me). With your proposed patch I still see TB's appear after the perspective switcher... Also, by inspection the fix won't work; the goal is to ensure that the SWT Z-order matches the order of the entries in the model. It's quite possible that there may be rendered toolbars (i.e. widget is non-null) followed by elements whose TBR is false (i.e. widget is null). In this case your patch would incorrectly reset 'prevCtrl' to null meaning that the element would be moved to the *beginning* of the SWT z-order. I've just tracked the z-order we set for the 'launchActionSet' toolbar (which is the one mis-placed after the open and it *seems* to be being placed ocrrectly. I'm starting to wonder if I'm mis-placing the MToolControls defining the search and perspective switchers...
Eric, Ok, I spent some time investigating this issue and it is not related to debug toolbar. Static contributions are wrong, too, if only perspective is closed and reopened. This symptom is partially explained by the fact that quick access and perspective chooser are created programatically at application workbench window creation. If the model is right, then the problem would be model rendering - note that items in the debug toolbar also change their positions - so it is quite possibly that there is a for(Object o : list) used where it should not be. Where should I look further?
Now things got weird: I got debug toolbar before the quick access, and launch menu and java search after perspective chooser. It looks like a race on windows initialization. Where are MToolControls put for search and perspective switchers? I'd like to check that place, too.
(In reply to comment #13) > > Where are MToolControls put for search and perspective switchers? I'd like > to check that place, too. They're created in org.eclipse.ui.internal.WorkbenchWindow.populateTopTrimContributions() PW
*** Bug 394812 has been marked as a duplicate of this bug. ***
*** Bug 414929 has been marked as a duplicate of this bug. ***
How i can see in Debug the problem with control positioning caused by next situation: If toolbar that has the previous position from anchor (parameter of "after=" in locationURI) is invisible the fixZOrder method try to position new toolbar after it by Control.moveAbove method but cannot do it because this (invisible) control is not presented in main toolbar composite. Thus the new toolbar became the last positioned (after PerspectiveSwitcher)
after the fix that described in Bug 414929 the problem disappears
Patch https://git.eclipse.org/r/15401 based on bug 414929 comment 1.
Evgeniy, it would be good if you had signed CLA and created gerrit account. I'd ammend then the patch to list you as an author of the patch.
Krzyzstof, I did it just now
(In reply to comment #21) > Krzyzstof, I did it just now Still no gerrit user
What should I do for it?
(In reply to comment #23) My bad :-). Here is the properly attributed patch https://git.eclipse.org/r/#/c/15401/ Eric, I can't reproduce the bug with the patch applied, and the patch itself makes a lot of sense. Could you double-check it?
Sweet ! This has really been bugging me, thanks a lot ! Committed (to master, I've changed the target milestone to match) http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a4a242259ce53cceb328b4715abd73da23550ce6 Works like a charm :)
Verified in the build: I20130916-2330
