Community
Participate
Working Groups
Created attachment 237746 [details] Adapted mail template example When upgrading an old RCP application (before e4) to e4 (using compatibility layer), the main toolbar is aligned on the right. This doesn't occur the first time the application is launched, but only when metadata was saved from a previous run (thus clearing metadata fixes the issue). I adapted the RCP mail template example to reproduce the problem. This can be found in attachment.
Thanks ! I'll start looking at this now...
Cedrix, I'm pretty sure that we've addressed this in Luna M4. Could you try it out and comment back ?
M4 is done...
Eric, thanks for the reply. Where can I get Luna M4 ? In the download links, I can only download M3.
(In reply to Cedric Moonen from comment #4) > Eric, thanks for the reply. > Where can I get Luna M4 ? In the download links, I can only download M3. The latest integration build should do it.
facing the same problem, I just updated my target platform using: http://download.eclipse.org/eclipse/updates/4.4-I-builds <unit id="org.eclipse.sdk.ide" version="4.4.0.I20131211-2000"/> <unit id="org.eclipse.equinox.sdk.feature.group" version="3.10.0.v20131211-1531"/> <unit id="org.eclipse.platform.sdk" version="4.4.0.I20131211-2000"/> but the issue remains.
Tried with latest integration build 4.4M4 I20131217-0800. Works fine on first run, then the metadata needs to be cleared each time. I'm guessing it's targeted for M5?
Seeing this problem in N20140112-2000 Will it be fixed in M5?
Seeing the right-aligned toolbar problem in my 3.8 RCP app using the compatibility layer running in Eclipse 4.4 N20140112-2000. In my RCP app, a GEF-based editor adds contributions to the toolbar with a ActionBarContributor. The contributed toolbar always gets added to the right. I notice that the following lines are added to file (workspace).metadata.plugins\org.eclipse.e4.workbench\workbench.xmi <children xsi:type="menu:ToolControl" xmi:id="_frzPUHw5EeODTpTvuym4Ow" elementId="PerspectiveSpacer" contributionURI="bundleclass://org.eclipse.e4.ui.workbench.renderers.swt/org.eclipse.e4.ui.workbench.renderers.swt.LayoutModifierToolControl"> <tags>stretch</tags> </children> <children xsi:type="menu:ToolControl" xmi:id="_frzPUXw5EeODTpTvuym4Ow" elementId="PerspectiveSwitcher" toBeRendered="false" contributionURI="bundleclass://org.eclipse.ui.workbench/org.eclipse.e4.ui.workbench.addons.perspectiveswitcher.PerspectiveSwitcher"> <tags>Draggable</tags> </children> If I manually remove these it works OK.
If you don't clear the workspace each time after this workaround is applied, does it still work? Would these modifications be reflected in an exported RCP App? (In reply to Phillipus B from comment #9) > Seeing the right-aligned toolbar problem in my 3.8 RCP app using the > compatibility layer running in Eclipse 4.4 N20140112-2000. > > In my RCP app, a GEF-based editor adds contributions to the toolbar with a > ActionBarContributor. The contributed toolbar always gets added to the > right. I notice that the following lines are added to file > (workspace).metadata.plugins\org.eclipse.e4.workbench\workbench.xmi > > <children xsi:type="menu:ToolControl" xmi:id="_frzPUHw5EeODTpTvuym4Ow" > elementId="PerspectiveSpacer" > contributionURI="bundleclass://org.eclipse.e4.ui.workbench.renderers.swt/org. > eclipse.e4.ui.workbench.renderers.swt.LayoutModifierToolControl"> > <tags>stretch</tags> > </children> > <children xsi:type="menu:ToolControl" xmi:id="_frzPUXw5EeODTpTvuym4Ow" > elementId="PerspectiveSwitcher" toBeRendered="false" > contributionURI="bundleclass://org.eclipse.ui.workbench/org.eclipse.e4.ui. > workbench.addons.perspectiveswitcher.PerspectiveSwitcher"> > <tags>Draggable</tags> > </children> > > If I manually remove these it works OK.
Issue still exists in 4.4.0.I20140211-1100
*** Bug 428289 has been marked as a duplicate of this bug. ***
Issue still exists in 4.4.0.20140307-2105.
(In reply to Sergey Kuznetsov from comment #13) > Issue still exists in 4.4.0.20140307-2105. With an additional feature. See Bug #429900
I analyzed the problem using the attached application. In the application a custom toolbar is added to main trimbar through the "org.eclipse.ui.menus" extension point: > <extension point="org.eclipse.ui.menus"> > <menuContribution > allPopups="false" > locationURI="toolbar:org.eclipse.ui.main.toolbar?after=additions"> > <toolbar id="org.eclipse.ui.tutorials.rcp.part3.toolbar"> > ... When the application is being started for the first time, the main trimbar is being filled in the following order: 1. The custom toolbar is added 2. PerspectiveSpacer(toBeRendered=true) and PerspectiveSwitcher (toBeRendered=false) are simply appended to the trimbar children list When starting the application for the second time the order is different: 1. PerspectiveSpacer and PerspectiveSwitcher are restored from persisted model 2. The custom toolbar (not stored in the persisted model) is added at the end of the trimbar children list (as a result of after=additions property - which is by the way the default value) Since the PerspectiveSpacer is set to be stretched, the custom toolbar is 'pushed' to right. There are multiple ways to fix this, however in my opinion the PerspectiveSwitcher and PerspectiveSpacer should not be treated as 'additions'. Then, if one wants to add a toolbar after the the perspective switcher, they should explicitly use "after=PerspectiveSwitcher". Review URL: https://git.eclipse.org/r/23612
But, as in Bug #429900, the toolbar contribution is not added through the "org.eclipse.ui.menus" extension point.
I tried to reproduce the problem described in bug 429900 with GEF and I do see the problem with multiple separators, but the toolbars position is correct (left) - even without my fix.
(In reply to Wojciech Sudol from comment #17) > I tried to reproduce the problem described in bug 429900 with GEF and I do > see the problem with multiple separators, but the toolbars position is > correct (left) - even without my fix. Running in Eclipse, you're correct. I'm thinking in a RCP context. I need to provide a better example where a toolbar contribution goes to the right but not through the "org.eclipse.ui.menus" extension point. My RCP app is an example, but not the best for a lightweight case.
I have downloaded Archi code and now I am able to reproduce the bug. Unfortunately my patch does not help. I continue investigation.
(In reply to Wojciech Sudol from comment #19) > I have downloaded Archi code and now I am able to reproduce the bug. > Unfortunately my patch does not help. I continue investigation. Wow, you went beyond the call of duty there! I was going to create a simple RCP app. Thank-you for taking the time to do this!
Regarding problem with right alignment, I see that it is still a problem with positioning of the PerspectiveSpacer and Quick Access. BTW I noticed that in ArchimateEditorActionBarAdvisor.fillCoolBar(ICoolBarManager) you use custom group names (e.g. "toolbar_edit") in places where standard group names (e.g. IWorkbenchActionConstants.GROUP_EDITOR, which is "group.editor") could be used. Why do you prefer to use custom names? If you use the standard names, the problem with right alignment disappears. Of course it is not a solution for this bug, but it could be treated as a temporary workaround.
(In reply to Wojciech Sudol from comment #21) > Regarding problem with right alignment, I see that it is still a problem > with positioning of the PerspectiveSpacer and Quick Access. > > BTW I noticed that in > ArchimateEditorActionBarAdvisor.fillCoolBar(ICoolBarManager) you use custom > group names (e.g. "toolbar_edit") in places where standard group names (e.g. > IWorkbenchActionConstants.GROUP_EDITOR, which is "group.editor") could be > used. > Why do you prefer to use custom names? > If you use the standard names, the problem with right alignment disappears. > Of course it is not a solution for this bug, but it could be treated as a > temporary workaround. I always thought that one could use a custom identifier for a ToolBarContributionItem. It always seems to have functioned correctly in Eclipse 3.x. Unless I misunderstood something about their purpose? These custom identifiers ("toolbar_edit", "toolbar_views") are used by my downstream plugins to add their toolbar contributions by means of the org.eclipse.ui.menus extension point. For example: <extension point="org.eclipse.ui.menus"> <menuContribution allPopups="false" locationURI="toolbar:toolbar_views?after=end"> I took your tip regarding ArchimateEditorActionBarAdvisor.fillCoolBar(ICoolBarManager) and I added an empty toolbar contribution to the end of the declarations: IToolBarManager toolBarViews = new ToolBarManager(SWT.FLAT); coolBarManager.add(new ToolBarContributionItem(toolBarViews, "toolbar_views")); //$NON-NLS-1$ toolBarViews.add(new GroupMarker("start")); toolBarViews.add(fShowModelsView); // etc... toolBarViews.add(new GroupMarker("append")); //$NON-NLS-1$ toolBarViews.add(new GroupMarker("end")); //$NON-NLS-1$ toolBarViews.add(new Separator()); IToolBarManager toolBarEditor = new ToolBarManager(SWT.FLAT); coolBarManager.add(new ToolBarContributionItem(toolBarEditor, IWorkbenchActionConstants.GROUP_EDITOR)); // Nothing is added to toolBarEditor And now when I open an Editor in Archi, the GEF tolbar is correctly appended on the left. Perhaps in e4, additional toobar contributions are looking for the IWorkbenchActionConstants.GROUP_EDITOR marker? But thanks for taking the time to download the app and finding this. :-) As you say, it's a workaround.
For the record, the e4 specific code for this RCP app, "Archi", is here: https://github.com/Phillipus/archi/tree/e4 (The "e4" branch is a development branch where I conduct my e4 experiments and workarounds, including this one).
(In reply to Wojciech Sudol from comment #15) > > Review URL: https://git.eclipse.org/r/23612 I just added a line at the beginning of populateTopTrimContributions(): void populateTopTrimContributions() { getCoolBarManager2().update(true); getCoolBarManager2().add(new GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS)); It does the equivalent work to add a correct model element (and it doesn't re-add the element, so if it was added by the ActionBarAdvisor we do nothing. That was enough to make the attached app work correctly. We shouldn't have to care about the perspective switcher specifically. PW
I just realized that the problem with editor contributions can be solved in the same way: void populateTopTrimContributions() { getCoolBarManager2().update(true); getCoolBarManager2().add(new GroupMarker(IWorkbenchActionConstants.GROUP_EDITOR)); getCoolBarManager2().add(new GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS)); Alternatively the editor group position can be corrected when added in the EditorActionBars.getToolBarManager().
(In reply to Wojciech Sudol from comment #25) > I just realized that the problem with editor contributions can be solved in > the same way: > > void populateTopTrimContributions() { > getCoolBarManager2().update(true); > getCoolBarManager2().add(new > GroupMarker(IWorkbenchActionConstants.GROUP_EDITOR)); > getCoolBarManager2().add(new > GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS)); > > Alternatively the editor group position can be corrected when added in the > EditorActionBars.getToolBarManager(). It's up to the RCP app to add the group markers that it needs for the plugins that it uses. We can add "additions" because that's assumed on every ContributionManager. But we can't add others, because the contribution algorithm doesn't place contributions with specific targets like "after=group.editor" if it can't find that group. The legacy editor contributions have a mode where they "find or create" the group marker, which is why they still appear even if the group marker isn't defined by the ActionBarAdvisor. So is the problem that in 4.x the PerspectiveSwitcher is considered part of the org.eclipse.ui.main.toolbar MTrimBar, but in 3.x it wasn't part of the org.eclipse.ui.main.toolbar Coolbar? PW
Yes, the problem is that if the editor group missing it is added at the end of trimbar - after perspective switcher. So I think that we should simply add the group before the perspective switcher.
(In reply to Wojciech Sudol from comment #27) > Yes, the problem is that if the editor group missing it is added at the end > of trimbar - after perspective switcher. So I think that we should simply > add the group before the perspective switcher. I don't understand why such a Perspective Switcher point is added? What about RCP apps that don't have a use for a Perspective Switcher at all?
What about honouring org.eclipse.ui.application.IWorkbenchWindowConfigurer.getShowPerspectiveBar()? If that's false, we simply don't add any PerspectiveSwitcher stuff to the top trim. PW
I think it is good idea, but it does not solve the problem when the switcher is visible. The same applies to the Quick Access.
(In reply to Paul Webster from comment #29) > What about honouring > org.eclipse.ui.application.IWorkbenchWindowConfigurer. > getShowPerspectiveBar()? We should still honour this as part of the solution. Eric: We're getting into this trouble at least partly because in 3.x the perspective bar is not part of the main coolbar, but in 4.x it's part of the main trim. One possible solution is to place to MTrimBars side by side in the top trim. I'm not sure our model supports it, and I don't think this is a good idea to begin with. Another option is to go back towards Wojtek's original solution, and know something about the PerspectiveSwitcher so the "end" of toolbar:org.eclipse.ui.main.toolbar is before it and its spacer. Eric, does this sound like something to explore? PW
I've just updated the Gerrit patch: - Removed the changes in EditorActionBars - Added code to honor the WindowConfigurer's 'getShowPerspectiveBar' API. Checked this by hacking the existing WorkbenchWindowConfigurer to return 'false'. I'll be amending this further to handle the CoolbarToTrimManager 'adds', ensuring that they're *before* the spacer (if any).
Ok, just pushed another amendment that adds new contributions *before* the PerspectiveSpacer...
I've released Wojtek and Eric's changes as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=78d5f3de253dd16a205d0ebeb6b0a024084c74bc Wojtek, could you test the possible scenarios and report back how close this fix is? PW
The fix looks good to me. I tested it with the attached app and Archi - works as expected.
(In reply to Wojciech Sudol from comment #35) > The fix looks good to me. I tested it with the attached app and Archi - > works as expected. I just wanted to add thanks and appreciation for going beyond the call of duty by testing this in Archi. Thanks!
Thanks Wojtek. PW
Verified in I20140428-2000.
After upgarding form kepler to mars, we are facing issue of text align. In kepler we were using below code to bring text at the bottom of icon. protected void fillCoolBar(ICoolBarManager coolBar) { IToolBarManager toolbar = new ToolBarManager(SWT.FLAT | SWT.BOTTOM); coolBar.add(new ToolBarContributionItem(toolbar, "main")); ActionContributionItem actionContributionItem = new ActionContributionItem(openViewAction); actionContributionItem.setMode(ActionContributionItem.MODE_FORCE_TEXT); toolbar.add(actionContributionItem); } but after upgarding to mars the text align is right side, it should be at bottom. Issue can be reporduce in RCP mail template example.
