Community
Participate
Working Groups
User Story: ----------- As a user of a large product built on Eclipse, with many plug-ins, I'm often lost in large context menus with 30 or more items in them. I need smaller context menus which adapt to my current workflow or context, such that I can operate the product more efficiently. Provider Story: --------------- As a company building an IDE on top of Eclipse, with many plugins partially proprietary and partially Open Source, I need a way to design context menus that fit my intended user audience such that I can design usability as needed. Technical Requirement: ---------------------- Capabilities / Activities exist as a mechanism to design the user experience for perspectives, views, shortcuts, buttons and toplevel menus; but no common mechanism exists today for tailoring context menus. Part of the problem is that only few context menus are implemented with the Eclipse Command Framework - many existing plug-ins use IMenuManager directly to make contributions. We have found a way filtering context menus by registering a MenuListener, but that feels like a hack. We are looking for an official guidance and API from the Eclipse Platform to design usability into Context Menus properly.
Technical implementation (Eclipse 3.8.x): For Common Navigator based views (Project Explorer), we have registered a action provider with a very high priority. Once the action provider is asked to fill the content into the menu, we can register a menu listener to the menu manager which is cleaning up the menu for us. For non Common Navigator based views, the current ability to cleanup the menus depend on the ability to access the menu managers used by the view. In case of the debug view this is possible because the menu manager are accessible through the view API. The listener is registered via a part listener activating the menu listener once the debug view is shown. For views not revealing the menu manager, there is no chance to cleanup the context menu at this point of time.
Based on our experiences with Uwe's approach so far, our acceptance criteria for a solution include: 1. We need a way to filter the "Editor" context menu which is the most overloaded of all context menus we've seen so far. 2. We need a way to filter-out items from context menus without changing the ordering of the remaining menus. 3. We need an official, supported way of doing this. For the records, the approach that we're currently looking at for giving the end user access to the context menu items that we filter-out is providing an "Other..." submenu at the end of the filtered-menu that would hold those items that we've filtered out. That way, we make sure that we're not making any workflows impossible and that the filtered-out items are still discoverable when needed. Could the Platform team come up with any ideas how to move forward on this ? We're open to contributing code to the Platform when there is some guidance on where to start and what approach to take.
Based on our initial experiments with Uwe's approach from comment 1, we are seeing some issues: - There are race conditions, the ordering of menu items becomes timing dependent when our menu listener starts removing some items - In some cases the listener doesn't get its turn and the full menu is shown again We'd really like to get input on how a mechanism for context menu filtering could potentially work - either now or in the not too distant future. To me, this is a key usability factor for Eclipse as a Platform, and one reason why our users - at least partially - don't like Eclipse as their IDE - editor context menus with 40 or more menu items are just not acceptable.
3.x Investigation: Activities/Capabilities can hide commands and org.eclipse.ui.popupMenus/objectContributions using the pattern plugin.id/action.id. For actions that were contributed directly/programmatically, we don't have anything today. But, there is a mechanism that doesn't involve changing the contribution items in the MenuManager. We use IContributionManagerOverrides. For example, we use this in the workbench window to support per-perspective hidden menu items. Spitballing an implementation: 1) a context menu override would be added in the PopupMenuExtender or in the call to PartSite.registerContextMenu(*) which creates PME. Since we don't own that MenuManager, we would have to be careful to delegate to an existing one as well without just replacing it. 2) for a given item that's not already covered by activities (o.e.ui.popupMenus or o.e.ui.menus) it could put it in the namespace context.menu.id/contribution.id 3) the getVisible(*) can use that information to return false without changing the menu ordering and that should make the menu item disappear. What do you guys think? That'll help with the problem that of programmatically added contribution items. PW
After investigation I found that Activities/Capabilities do not allow to specifically remove Actions (contributed via actionProviders). E.g. the action provider can be filtered, not specific actions this provider adds. This might be very useful in some cases.
I've just made an interesting observation, which might actually relate to what Paul said in comment 4. What I found was that - org.eclipse.team.ui defines a popupMenus/objectContribution with id "team.main" - org.eclipse.egit.ui overrides that with a menuContribution with id "team.main" - A CapabilityFilter on "org\.eclipse\.egit\.ui/.*" happened to hide the context menu (both the egit one as well as the underlying team.ui one). In my case, hiding the team.ui contribution had been accidental and undesired, but maybe this obeservation opens the door to hiding context menu contributions. See also bug 405237 for the spectific egit case. Paul, was that what you were referring to - overriding a dynamic / programmatic context menu contribution with a declarative one somewhere else, thus giving the declarative contribution the option to hide itself as well as the contributor that it overrides ? Related to what Hans said, maybe the "menuContribution" handling of capability definitions is more fine grained than the popupMenu handling ?
(In reply to comment #6) > I've just made an interesting observation, which might actually relate to > what Paul said in comment 4. > > What I found was that > - org.eclipse.team.ui defines a popupMenus/objectContribution with id > "team.main" > - org.eclipse.egit.ui overrides that with a menuContribution with id > "team.main" > - A CapabilityFilter on "org\.eclipse\.egit\.ui/.*" happened to hide the > context menu (both the egit one as well as the underlying team.ui one). This has to do with the fact that objectContribution menus are merged on top of menuContribution menus so that 1) you only have one menu (Team in this example) and 2) to provide a migration path from actions to commands so you don't have to convert them all to commands at once. The order of operations for menus and toolbars are 1) programmatic contributions applied first, then 2) menuContributions, then 3) any action contributions like objectContributions. one implication of this is that objectContributions can see menuContributions, but not the other way around. > Paul, was that what you were referring to - overriding a dynamic / > programmatic context menu contribution with a declarative one somewhere > else, thus giving the declarative contribution the option to hide itself as > well as the contributor that it overrides ? I meant that one option in 3.x would be to supply a org.eclipse.jface.action.IContributionManagerOverrides to the MenuManager in question. When calculating visibility the contribution managers ask overrides.getVisible(contributionItem); This would allow even programmatic contribution items to be marked as invisible without changing their data or removing the ICI. To tie it into activities in the getVisible(*) method a programmatic contribution would need to be identified somehow, and that's why I suggested using context.menu.id/contribution.id. It can still lead to a problem if the contribution or containing menu doesn't set an ID at all, I'm not sure what to do in this case (use the label without the mnemonic as the ID?) > Related to what Hans said, maybe the "menuContribution" handling of > capability definitions is more fine grained than the popupMenu handling ? actionProviders are probably related to the CommonNavigator/ProjectExplorer. PW
CQ:WIND00409098
The issue of being unable to filter some context menus has come up again for us recently. IMO in the context of making Eclipse more easy to use, filtering context menus in a product-specific way is very important - so this may relate to the "Platform Vision" as Wayne explained it in the AC call recently https://wiki.eclipse.org/Architecture_Council/Meetings/January_8_2015#Wayne:_Platform_Vision_Work As we have fully migrated to Eclipse 4.4 by now, I am wondering if the new menu managers in Eclipse 4 provide any means of filtering context menus ... that would ideally allow us to also filter-out objectContributions or programmatic contributions which the Capability filter doesn't cover ? We'd appreciate any hints, and we'd be willing to contribute filtering functionality towards Mars if it doesn't exist yet (but we'd probably need some guidance / help). Thanks! Martin
