Community
Participate
Working Groups
I created a toolbar with three commands. When I add an activeWhen extension to the toolbar using a 'with activePartId equals myView' it does not disable the commands when myView looses focus. If I put the extension on each command individually it works fine.
Please include your menuContribution definitions. Thanx, PW
Created attachment 77271 [details] Full Plugin XML showing the problem
By "does not disable the commands" I assume you mean does not make the toolbar invisible. PW
(In reply to comment #3) > By "does not disable the commands" I assume you mean does not make the toolbar > invisible. > > PW > Your assumptions are correct.
I am unable to get the visibleWhen tag to work on a contribution to the trim. I am trying to show a control only when a certain perspective is open and have created a property tester to enable this, however, the visibleWhen doesn't seem to be working. Below is an example of the xml, using a systemTest instead of a property test, and it seems to have no effect regardless of the permutations. <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="toolbar:org.eclipse.ui.trim.status" <toolbar id="MyPlugin.CompanyWebLink"> <control class="org.view.CompanyWebLink" id="MyPlugin.CompanyWebLink.Control"> </control> <visibleWhen> <systemTest property="os.name" value="GobblyDeGook"> </systemTest> </visibleWhen> </toolbar> </menuContribution> </extension>
Eric, this is one I was talking about earlier. PW
(In reply to comment #5) > to be working. Below is an example of the xml, using a systemTest instead of a > property test, and it seems to have no effect regardless of the permutations. Does it work if you tie it to a known variable, like: <with variable="activePartId"> <equals value="org.eclipse.ui.views.ContentOutline"/> </with> System properties don't get re-evaluated when they change (and there was no way to do this for property testers before 3.4, either) PW
Since controls inside toolbars of the trim are not getting their visibility set properly from the visibleWhen tag, I am getting an issue which prevents any sort of lazy loading of a plugin which uses a control in the status bar. Any ideas for a workaround until this behavior is fixed?
(In reply to comment #8) > Since controls inside toolbars of the trim are not getting their visibility set > properly from the visibleWhen tag, Pleases provide a simple plugin example. AFAIK the control correctly has its visibility set. This bug is about the toolbar itself not respecting visibleWhen. Are you saying the control element does not honour visibleWhen? As an aside, there is no lazy-loading implemented for a control contribution. As soon as it is populated into a piece of trim (even if invisible) then it will load that plugin. PW
I think I mis-worded my original comment. I'm setting visibility on the toolbar but the control is inside the toolbar so one would expect that the visibility applies to the control also. I suspect that the second half of your reply means I am going to have to use a command here instead of a control if I want lazy-loading to work. Here's my code: <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="toolbar:org.eclipse.ui.trim.status" <toolbar id="my.company.pluginName.ui.trimToolbar"> <control class="my.company.pluginName.ui.MyWorkbenchWindowControlContribution" id="my.company.pluginName.ui.trimToolbarControl"> </control> <visibleWhen> <reference definitionId="my.company.pluginName.ui.myPerspectiveIsActive"> </reference> </visibleWhen> </toolbar> </menuContribution> </extension> <extension point="org.eclipse.core.expressions.definitions"> <definition id="my.company.pluginName.ui.myPerspectiveIsActive"> <with variable="activeContexts"> <iterate operator="or"> <equals value="my.company.pluginName.ui.SomeActionSetId"> </equals> </iterate> </with> </definition> </extension>
(In reply to comment #10) > I think I mis-worded my original comment. I'm setting visibility on the > toolbar but the control is inside the toolbar so one would expect that the > visibility applies to the control also. Right, so when this bug is fixed we'll make the toolbar disappear (which will make the control disappear). > > I suspect that the second half of your reply means I am going to have to use a > command here instead of a control if I want lazy-loading to work. To show a control we had to instantiate it (there was no other way). An optimization that could be added is that we proxy the control contribution so that we don't load the plugin as long as nothing ever calls fill(*). That won't make it into 3.4, however, and would need to be requested in a new bug. PW
Equivalent partId definition: <extension point="org.eclipse.core.expressions.definitions"> <definition id="my.company.pluginName.ui.myPerspectiveIsActive"> <with variable="activePartId"> <equals value="org.eclipse.ui.views.ContentOutline"/> </with> </definition> </extension>
Why is this still marked 3.4 RC2?
Maybe we should consider for 3.4.1 PW
+1 for me. I'd have done it now except I was concerned about introducing regressions (to me, this code is 'baroque...;-).
+1 for me. My case is to show a toolbar under the condition that a specific perspective is active. This bug still exists in the final release of 3.4.
+1 from me, assuming comment 9 also affects how dynamic menu contributions are handled.
We should try and get this in early in 3.5 bug 246999 is for making the dynamic contribution proxied to delay plugin loading. PW
Moving to triage (for now), this should be re-targeted to 3.6 when it becomes available...
+1 from me. Run into this problem again today.
Is there a viable workaround for this bug? I can make the controls within the toolbar respond correctly to the visibleWhen property tester, but the toolbar itself remains visible, consuming space on the trim. Any way to directly set the visibility of the toolbar from the property tester?
Created attachment 153008 [details] Current work for this defect This patch *almost* fixes the problems but there are still arifacts on the first startup (before the Welcome goes away) as well as some spurious issues. I'm capturing this for a second pass later.
*** Bug 297193 has been marked as a duplicate of this bug. ***
Out of time...
(In reply to comment #24) > Out of time... Is it working in 3.6 or 3.7?
Still reproducible on 3.7.
I bet 4.x will net get it, due to new application model?
(In reply to comment #21) > Is there a viable workaround for this bug? I can make the controls within the > toolbar respond correctly to the visibleWhen property tester, but the toolbar > itself remains visible, consuming space on the trim. Any way to directly set > the visibility of the toolbar from the property tester? This creates a significant problem for anyone who wants to contribute trims that can be hidden on both 4.x and 3.x. You can contribute the trims using the extension point and setting visibleWhen on the controls, and this seems to work fine on 4.x (excepting that there seems to be no support for vertical trims anymore?), but on 3.x, when the controls are hidden, the empty toolbar remains, which makes hiding the trims a bit pointless. If the trim is the only toolbar on that side of the workbench, then it is quite annoying for the user to have a big empty bar when the controls are hidden. Is there any workaround for this, or any plans to fix this issue? The only possible workaround I can see is to contribute the trims dynamically using ITrimManager on 3.x, and contribute them using the extension point on 4.x, but then I think you would need have the XML to contribute the extension in a separate bundle that is not installed on 3.x, otherwise 3.x users would get two copies of the trim.
We used to have code in Mylyn which set visibility on the parent control directly and then forced a re-layout. I haven't checked if this works in combination with the <visibleWhen/> specification for contributions but we could try that as a work-around on 3.x.
+1 for me. I'm adding visibleWhen to each and every item on my toolbars.
(In reply to comment #29) > We used to have code in Mylyn which set visibility on the parent control > directly and then forced a re-layout. I haven't checked if this works in > combination with the <visibleWhen/> specification for contributions but we could > try that as a work-around on 3.x. It looks like something like this will work.
Any further word on this? I'm seeing this problem now as well.
(In reply to comment #32) > Any further word on this? I'm seeing this problem now as well. No one is looking at this ATM. PW
By adding visibleWhen on each command, toolbar is automatically getting disappeared if there are no visible elements. This works!
Why is this one still open ? Is there work expected ?
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
In eclipse 4.5.1 a toolbar with no visible items is being rendered. It is just an empty space a few pixels wide but if there are several toolbars next to eachother it leads to a noticeable gap. Setting visibleWhen on all the items is no longer a good workaround in 4.5.1.
This appears to be a design flaw or implementation oversight. 1. MenuAdditionCacheEntry a.processTrimChildren fails to add visibleWhen expressions to MToolBar model elements. i. item.setVisibleWhen(MenuHelper.getVisibleWhen(toolbar)); 2. ToolBarContributionRecord fails to account for MToolBar visibleWhen attribute a. collectInfo i. ContributionsAnalyzer.collectInfo(info, toolbarModel.getVisibleWhen()); b. anyVisibleWhen i. if (toolbarModel.getVisibleWhen() != null) return true; c. updateVisibility i. if (MCoreExpression.class.isInstance(toolbarModel.getVisibleWhen())) { boolean currentVisibility = ContributionsAnalyzer.isVisible((MCoreExpression)toolbarModel.getVisibleWhen(), exprContext); if (currentVisibility != toolbarModel.isVisible()) { toolbarModel.setVisible(currentVisibility); } } ii. if (toolbarModel.getVisibleWhen() == null) Stream.of(managerForModel.getItems()).filter(i -> i.isVisible()).findFirst().ifPresent((i) -> toolbarModel.setVisible(true)); 3. CoolBarToTrimManager unilaterally sets MToolBarElement parent MToolBar visible attribute a. fill(MToolBar container, IContributionManager manager) i. if (container.getVisibleWhen() == null) container.setVisible(true); 4. TrimBarLayout likewise unilaterally sets MToolBarElement parent MToolBar visible attribute a. hideManagedTB(MTrimElement te) i. boolean barVisible = te.getVisibleWhen() != null ? te.isVisible() : ((ToolBar) kids[0]).getItemCount() > 0; Peculiarly, MToolBarContribution has a VisibleWhen attribute. This is not congruent with the org.eclipse.ui.menus XML schema. I.e. menuContribution does not have an immediate visibleWhen child element whereas toolbar does.
Created attachment 273345 [details] Comment 38 diff Comment 38 diff
Gerrit patches are welcome.
(In reply to Lars Vogel from comment #40) > Gerrit patches are welcome. That's what I hear. I submitted two early last month that are dying on the vine.
(In reply to darrel karisch from comment #41) > That's what I hear. I submitted two early last month that are dying on the > vine. In platform? Please provide the links.
Bug 530628 - PartActivationHistory and EPartService.ACTIVE_ON_CLOSE_TAG https://git.eclipse.org/r/116630 Bug 522450 Minimized views lost permanently in Detached Window https://git.eclipse.org/r/116796
(In reply to darrel karisch from comment #43) > Bug 530628 - PartActivationHistory and EPartService.ACTIVE_ON_CLOSE_TAG > https://git.eclipse.org/r/116630 > > Bug 522450 Minimized views lost permanently in Detached Window > https://git.eclipse.org/r/116796 Both had fast feedback, https://git.eclipse.org/r/#/c/116630/ still waiting for your feedback and in https://git.eclipse.org/r/#/c/116796/ it would have been helpful if you gave written feedback after my review, like "Done".
New Gerrit change created: https://git.eclipse.org/r/120384
Created attachment 273739 [details] Example e4 RCP project with toolitems using core and imperative expressions (In reply to Eclipse Genie from comment #45) > New Gerrit change created: https://git.eclipse.org/r/120384 I tested with an small e4 RCP application and this change did not hide the toolitem entries, neither with core expressions nor with imperative expressions. Darrel, can you have a look? The "Not hidden by imperative expression" and the "Not hidden by core expressions" toolitems are the relevant ones. The same expressions work fine for menu items.
(In reply to Lars Vogel from comment #46) I neglected to test in an e4 app. I used eclipse.platform ui org.eclipse.ui.examples.contributions plugin to test. I moved org.eclipse.ui.examples.contributions.editor.toolbar visibleWhen from the command to the toolbar. I also added the same visibleWhen to org.eclipse.ui.examples.contributions.group.file toolbar. Appears this was not sufficient. I will look at your suggestions from the CR.
(In reply to darrel karisch from comment #47) > (In reply to Lars Vogel from comment #46) > Appears this was not sufficient. I will look at your suggestions from the > CR. They interesting part is that is already works for Toolbar Contributions. It only checks visibility in processAdditions (called only for contributions). I believe the correct fix is to move this check out into a method and after the additions are processed run this check on all contributions. I played around with it a bit today, see my notes here: https://git.eclipse.org/r/#/c/121658/
Darrel was on the right track, but might have missed some code paths. I have been looking around into visibility of tool and menu items, and came to the following two observations: 1. In general, visibility attributes are not added and evaluated for 'root' elements. They are only added and evaluated for children. See also Bug 372508. 2. To correctly handle visibility, the following three attributes must resolve to true for an element to be visible: a. isVisible() attribute; b. getVisibleWhen() attribute; for core and imperative expressions c. getPersistedState().get(MenuManagerRenderer.VISIBILITY_IDENTIFIER) attribute; for activity based filtering, see Bug 407166. Any place in code where a tool/menu (item) is created, that does not consider all attributes is incorrect. (For some cases, non of the attributes are considered.) Any place in code that forwards model visibility to UI elements that does not consider all attributes is incorrect. (In some cases visibility is not considered at all.) Note that there are (too) many code paths involved: e4, legacy contributions, factories, etc. There are probably a dozen open bugs related to the two observations.
Rolf, could you revive your work here for 4.15?
(In reply to Lars Vogel from comment #50) > Rolf, could you revive your work here for 4.15? I have to really see how to balance the limited time I can spend on Eclipse platform. And some issues are way more time consuming than anticipated (e.g. removing of menu items). So I cannot commit that I will work on it for 4.15.
*** Bug 512790 has been marked as a duplicate of this bug. ***
