Community
Participate
Working Groups
This is a commands version of bug 355497. That defect is tracking the non-commands implementation, this one allows us to defer the work on the commands side...
Note to self: see ContributionItemUpdater in WorkbenchMenuService in 3.x PW
Copying Paul's comment from the original Capabilities defect to the Menu/Commands Capabilities defect. Yesterday I was observing that some menu filtering was, in fact, occurring, but not refresh was being triggered by the change in capabilities. However, once changed, opening new perspectives etc. would tend to show the correct(ish) menu operations. I will be investigating further. (In reply to comment #10) > Paul, there are a number of different API's (various collection filters...) in > the WorkbenchActivityHelper, do you know if any of them are used outside of the > commands code ? The one I'm thinking of in 3.x is in WorkbenchMenuService. ContributionItemUpdater gets an IIdentifier for individual IContributionItems, and then adds itself as an IIdentifierListener. It combines any visibleWhen that applies to that ICI and any activity state as well.
Since, according to Paul's comment, the menu operations are also using IIdentifierListeners, correct menu operation will likely require the fix for bug 359887. Unless menus also only attach one listener to each IIdentifier ... in which case the defect is masked.
Dean, I wondered if you had made any further progress on this. I'm looking to use activities to control the visibility of a set of top-level menus. I can put in some cycles on this, but I'd rather avoid duplicate effort.
No I have not been looking at this recently.
I've pushed an initial set of commits to address activities for menus to the branch 'bdealwis/359778-activities'. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/log/?h=bdealwis/359778-activities My initial case was to get support for menus contributed from extension points. This has not been extensively tested. The implementation is implemented against the E4AP model. It walks the application model (and listens for changes) and adds/removes IIdentifier hooks for menus, toolbars, and perspectives. I've implemented this within the WorkbenchMenuService class although it could (should?) be easily extracted into a standalone bundle; if the activity support was pulled out of org.eclipse.ui, we could bring this into the Eclipse 4 AP. There are three commits. The first is a minor fix and should be adopted. The second works around a problem from how contributed menus are rendered. The third provides the gut of the implementation. commit f77397953f8bbc09f8869296e68731dc98169b32 Ensure menus generated from plugin.xml have appropriate contributorURIs We weren't maintaining contributor info when creating model objects. commit 04138638b7bb438ed7c402818bf0c4038730cf48 Allow contributed menus to have their visibility toggled. Menus contributed from a MMenuContribution are duplicated as part of the rendering process (ContributionRecord#mergeIntoModel()), and thus the toggling visibility on the source menu is ignored. commit e7e8ffbb17cb5c12b8c2c9e8461fdeb4d9bbbc6b A first cut at providing activity support for menus, toolbars, and perspectives. NB: The menuContributionListener has a workaround for bug 364529.
Moving to M5.
this is likely too deep to jamb into M7, no ?
This will have to be deferred to SR1 PW
(In reply to comment #9) > This will have to be deferred to SR1 > PW Too bad. This is a show-stopper for us.
We would very much like to move our product over to 4.2, but cannot yet do this as this feature is quite important for us. If someone could give me some pointers for getting started I would like to contribute a patch.
For the general information, see http://wiki.eclipse.org/Platform_UI/How_to_Contribute Most of the code you are interested in is in http://git.eclipse.org/c/platform/eclipse.platform.ui.git/ If you need EclipseContext and DI projects, they're in http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/ We're working in master in both projects. See http://wiki.eclipse.org/Platform-releng/Git_Workflows#Configuring_the_repo for how we configure our repos (rebase=true on all tracked branches) hints: In 3.x, when menu contribution items were created in the WorkbenchMenuService, their visibleWhen was managed by org.eclipse.ui.internal.menus.WorkbenchMenuService.ContributionItemUpdater which took into account the visibleWhen and the IIdentifier state (activity calculation). In 4.x menu element visibility is calculated starting in the org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRendererFilter.updateElementVisibility(MMenu, MenuManagerRenderer, MenuManager, IEclipseContext, int, boolean) in org.eclipse.e4.ui.workbench.renderers.swt toolbar items visibility is managed in a runAndTrack created in org.eclipse.e4.ui.workbench.renderers.swt.ToolBarManagerRenderer.processAddition(MToolBar, ToolBarManager, MToolBarContribution) When hooking in there, keep in mind that this plugin can't see activities or IIdentifiers. PW
*** Bug 392709 has been marked as a duplicate of this bug. ***
What is the current status of this bug? I feel like it is an important one, but I don't understand the requirements.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
