Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #318715 +++ SDK 4.0 - I20100701-1105. The ordering of the toolbar buttons is completely different than intended by the plug-in developers i.e. as they appear in 3.x. This is a critical usability issue for me.
Still an issue in SDK 4.0 - I20100712-2029.
>The ordering of the toolbar buttons is completely different It looks like each group is backwards.
As it turns out, parts of the toolbars are correct but other parts are applied to early. In 3.x, the JDT action sets were processed and marked "adjunct" and stored for later, then the text action set was processed, then the JDT adjunct action sets that contribute to text.presentation. In 4.0, the action sets are turned into menu contributions in order, first JDT and then text. They're then applied in order, so the 2 text icons aren't added until after the JDT contributions. PW
Created attachment 174749 [details] Adjunct action set processing v01 Primitive adjunct actionSet processing. PW
Ooops, wrong bug. PW
Boris, could you check the code? PW
postProcessing should be a local variable, and what about the case where processed is set to true - do we still need to do the remaining iterations of the innermost loop?
Created attachment 174809 [details] Adjunct action set processing v02 Made changes re: the comments. But the actionSet items are only enabled for the first java editor. If I switch they become disabled, and re-enabled when I switch back to the first editor. Needs more investigation. PW
I've opened bug 320492 to track the enabled problem. PW
Released for today's build (Around 11:30) PW
>Released for today's build (Around 11:30) Is it really in the build? (asking this time before reopening ;-) I just tried I20100721-2056 and there are still some toolbar buttons at the wrong location: - Run Last Tool (should be after Run) - 3 editor actions (Block selection, Whitespace, ...) (should be before the Next/Previous Annotation group) so that all the textual editor actions are at the same spot - Last Edit Location (should be before Back)
(In reply to comment #11) > >Released for today's build (Around 11:30) > Is it really in the build? (asking this time before reopening ;-) Yes, this time :-) The processing I added was to insure that JDT actionSet actions added to text actionSet toolbars would be processed after the text actions, not in plugin id order. > I just tried > I20100721-2056 and there are still some toolbar buttons at the wrong location: > - Run Last Tool (should be after Run) > - Last Edit Location (should be before Back) I can look into these two. > - 3 editor actions (Block selection, Whitespace, ...) (should be before the > Next/Previous Annotation group) so that all the textual editor actions are > at the same spot toolbars should be processed in the same order as actionSets (plugin id order) but we have some handling around Normal/Presentation. PW
There's 2 levels or ordering that we don't address. When an actionSet toolbar is created, it appears to be inserted in alphabetical order by id. When an adjunct actionSet's actions are contributed to an existing actionSet toolbar, the items are inserted before items from a different actionSet (also sorted by actionSet id). Remy and I are looking at this now, but if we don't find a safe solution be the end of the day I would recommend deferring this to 4.1 PW
It looks like we need a new position processing instruction to allow insertion from point A in alphabetical order, and to allow special processing of items by contribution (as opposed to by their IDs). Deferred until 4.1 PW
Created attachment 190792 [details] Run/Debug/External tool launch actionSets v01 First set of tests to compare results against. PW
Created attachment 190916 [details] Run/Debug/External tool launch actionSets v02 Removing extraneous separator, and (failing) test for the order of Debug/Run/Profile PW
We are "sniff-testing" WTP with Platform 4.2 M1 and I am observing the same problem in the Java EE perspective - the order of the buttons in the toolbar sections is reversed.
Created attachment 203072 [details] ActionSet patch v1 This patch will invert the processing of action sets for toolbars so that they come up in the same order as 3.x. (In reply to comment #17) > We are "sniff-testing" WTP with Platform 4.2 M1 and I am observing the same > problem in the Java EE perspective - the order of the buttons in the toolbar > sections is reversed. Hi Kaloyan, thank you for testing Eclipse 4.2. For the toolbars that are in the wrong order, how were they contributed there? Are they contributed through org.eclipse.ui.actionSets or org.eclipse.ui.menus?
The one I am referring to is a contribution to the org.eclipse.ui.actionSets extension point.
ping! 4.1.1 has left the station already.
I'm working on this in eclipse.platform.ui.git pwebster/legacyActions. Initial creation of actionSets is done and seems fine (Nav toolbar is back in order). Visibility is wonky (after 2 or 3 active part changes actionSets don't disappear any more). PW
much better. text presentation is now visible while you have an open text editor and disappears when you close all text editors. PW
Remy, I've pushed my change to a new topic branch, pwebster/legacyActionSets Could you review the change and test some of your scenarios? I see it includes my ContextService/WorkbenchWindow changes. We backed those out of master, so we might have to remove them from this change as well. PW
(In reply to comment #23) > Remy, I've pushed my change to a new topic branch, pwebster/legacyActionSets > > Could you review the change and test some of your scenarios? If I switch to the 'Debug' perspective and then back, the debug tool items (resume, pause, etc.) are still in the main tool bar. Are you seeing this?
(In reply to comment #23) > Could you review the change and test some of your scenarios? The 'Back' and 'Forward' buttons look like they're on the wrong place on my computer.
(In reply to comment #24) > If I switch to the 'Debug' perspective and then back, the debug tool items > (resume, pause, etc.) are still in the main tool bar. Are you seeing this? Same happens for the 'Checkout from CVS' tool item from the 'CVS Repository Exploring' perspective. Seems like a general problem. Could be related to 12377a9baddb3696ed87e39e0ca8bfa20039e19b that we pulled out in master.
Created attachment 212384 [details] Screenshot depicting the problem in question. We seem to be missing a separator in the C/C++ perspective. I didn't check to see if it's actually an action set or not though.
(In reply to comment #26) > Could be related to 12377a9baddb3696ed87e39e0ca8bfa20039e19b that we pulled out > in master. I reverted those changes but the tool bar problems with switching perspectives appear to persist.
If I turn on the Java project tool item by customizing my perspective, resetting doesn't seem to hide it back. It works in my outer though.
(In reply to comment #29) > If I turn on the Java project tool item by customizing my perspective, > resetting doesn't seem to hide it back. It works in my outer though. If I uncomment back the resetItemOrder() call in resetPerspective() then this case works again.
In the 'Debug' perspective, the debug actions should appear after the launch actions in the toolbar. The 'Skip All Breakpoints' also seems to be in the wrong spot.
(In reply to comment #30) > If I uncomment back the resetItemOrder() call in resetPerspective() then this > case works again. I've added that fix in pwebster/legacyActionSets PW
1. Window > Open Perspective > Other... > CVS Repository Exploring > OK 2. Window > Customize Perspective... 3. Turn off 'CVS' in the 'Tool Bar Visibility' tab > OK 4. Window > Reset Perspective... > Yes 5. Nothing happens (see comment 29). 6. Window > Close Perspective 7. Window > Open Perspective > Other... > CVS Repository Exploring > OK 8. The perspective is now even showing _less_ tool items than what it showed after step 3.
Perspective customization is not required. The reset is the problem. 1. Window > Open Perspective > Other... > CVS Repository Exploring > OK 2. Window > Reset Perspective... > Yes 3. Switch back to the 'Java' perspective. 4. Switch back to the 'CVS Repository Exploring' perspective. 5. Same problem.
(In reply to comment #34) > 1. Window > Open Perspective > Other... > CVS Repository Exploring > OK > 2. Window > Reset Perspective... > Yes > 3. Switch back to the 'Java' perspective. > 4. Switch back to the 'CVS Repository Exploring' perspective. > 5. Same problem. Fix pushed to pwebster/legacyActionSets. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5296a6087818f539c9cfc66b57875bfe99e13965
(In reply to comment #27) > Created attachment 212384 [details] > Screenshot depicting the problem in question. > > We seem to be missing a separator in the C/C++ perspective. I didn't check to > see if it's actually an action set or not though. Not CDT related, my mistake. Just turn off auto builds and resize the window to get the tool item to show up.
This bug is now fixed, and other problems will be opened in other bugs. bug 374773 PW
The order is still wrong (as of 4.2-N20120415-2015), especially the Debug contributions are bad and are missing a separator. The additional buttons that are added in the Debug perspective are placed in front instead of added behind the "normal" Run/Debug buttons. The editor actions are also placed differently, but that's less a problem than the Debug buttons.
Created attachment 214044 [details] Picture showing differences
(In reply to comment #39) > Created attachment 214044 [details] > Picture showing differences That goes away on restart. Opened bug 376896 PW
(In reply to comment #38) > The order is still wrong (as of 4.2-N20120415-2015), especially the Debug > contributions are bad and are missing a separator. The additional buttons that > are added in the Debug perspective are placed in front instead of added behind > the "normal" Run/Debug buttons. > > The editor actions are also placed differently, but that's less a problem than > the Debug buttons. The debug contributions are now correct. The Run + Debug toolbar actions were accidentally placed in the wrong place - the cause of bug 317182. See 3.7.x to confirm.
Verified in: Version: 4.2.0 Build id: I20120430-1800 Also verified bug 376896 is still a problem.
