Community
Participate
Working Groups
I20070208-2030 We need a better enablement story for ShowIn targets. Currently, ShowIn targets are either defined - per perspective via extension point org.eclipse.ui.perspectiveExtensions, element <showInPart> => leads to problems such as bug 169684 and bug 150008 or - per part via IShowInTargetList => part must enlist all targets Both approaches don't scale and don't work in situations where source and target don't know each other, but show the same kind of elements. A good example of this problem is the Synchronize view, which shows elements (e.g. IResources) for which Show In > Package Explorer makes sense. Here's a way to resolve the problem: - Deprecate the <showInPart> of perspectiveExtensions - Add a new extension point (e.g. "org.eclipse.ui.showIn") that allows adding ShowIn targets declaratively, based on the current ShowInContext. The showIn extension point should support the extensible expression language on a <visibility> element (similar to org.eclipse.ui.popupMenus's objectContribution, but showIn should also declare a variable "input" in addition to "selection"). ContributionItemFactory.VIEWS_SHOW_IN should read and evaluate the contributions before the ShowIn menu is shown.
We are considering simply providing this via menu contributions. It would consist of a couple of parts. A well defined menu id for the showIn menu (currently, it's showIn in most places). A "legacy" contribution to the showIn menu ... that will include all of the items that are currently created. A showInTarget command that takes an optional view id (the target id). This can be used in your own menuContributions to add targets to the showIn menu. They can be added using visibleWhen ... still some question as to whether they can just use the selection variable, or if they should be using activeMenuSelection and activeMenuInput. But this will make these show in targets simply tied to the selection or equivalent through core expressions, instead of the perspective. Adding the showIn menu itself can be done declaratively by adding the menu element in a menuContribution ... need to make sure that window/view/popup menus all work. Also, perhaps adding a general menu contribution QuickMenu command that takes the menu location that needs to be popped up. That way you can declaratively create the showIn menu -> Shift+Alt+W keybinding. BTW, as of 3.3 you can create a perspectiveExtension with a target of "*" so you can add your showInPart to all perspectives without knowing them up front. PW
Created attachment 91566 [details] Show In v02 draft patch for safekeeping. This is heading in the direction outlined by Comment #1 Show in> can be included using a menu contribution like: <dynamic class="org.eclipse.ui.internal.ShowInMenuContribution" id="org.eclipse.ui.menus.dynamicShowInMenu"> </dynamic> The Show In menu generated includes both the legacy show in menu contributions plus anything contributed to popup:org.eclipse.ui.menus.showInMenu It includes a command that can be used to contribute new show in targets: <command commandId="org.eclipse.ui.menus.showIn"> <parameter name="org.eclipse.ui.menus.showIn.targetId" value="org.eclipse.ui.examples.contributions.view"> </parameter> </command> Things that need (much) more work: 1) make sure anything needed is published API (declared as a constant) 2) The Show In> menu needs to be either a dynamic contribution item (as it is now) or a set of dynamic contributions (so including the menu with the correct ID will include the correct dynamic contributions). Both are useful, although not supply the MenuManager (the alternative implementation) allows the popup quick menu (like ALT+SHIFT+W) to be easily generated. 3) the selection/activeMenuSelection/activeMenuEditorInput tends to be less accurate than the IShowInSource. That makes the org.eclipse.ui.menus.showIn command visibleWhen either very complicated or not handling all cases very well. It'll investigate using <with variable="activePart"> <adapt type="org.eclipse.ui.part.IShowInSource"> <test property="o.e.u.p.showInContext .../> </adapt> </with> or providing some kind of showInContext variable(s) to the core expressions themselves. PW
Created attachment 92585 [details] Show In v03 OK, the shape is solidifying, although this hasn't had the final "turn everything into API" pass. Using org.eclipse.ui.actions.ContributionItemFactory.VIEWS_SHOW_IN.create(window) will pick up the new contributions as well as the old ones. As a declarative menu contribution, it will be useable as: <menu id="org.eclipse.ui.ide.markers.showInMenu" label="%menu.showIn.label" mnemonic="%menu.showIn.mnemonic"> <dynamic class="org.eclipse.ui.internal.ShowInMenu" id="org.eclipse.ui.menus.dynamicShowInMenu"/> </menu> org.eclipse.ui.internal.ShowInMenu will probably be replaced with an org.eclipse.ui.ExtensionFactory call. This also means there is no need to follow a menu id naming convention (with one restriction ... no one will be able to use the popup:org.eclipse.ui.menus.showInMenu id :-) Adding a new showIn target can be done using popup:org.eclipse.ui.menus.showInMenu and the org.eclipse.ui.menus.showIn command <menuContribution locationURI="popup:org.eclipse.ui.menus.showInMenu"> <command commandId="org.eclipse.ui.menus.showIn" style="push"> <parameter name="org.eclipse.ui.menus.showIn.targetId" value="org.eclipse.ui.views.ProgressView"> </parameter> <visibleWhen checkEnabled="false"> <or> <with variable="showInSelection"> <count value="1" /> <iterate ifEmpty="false"> <adapt type="org.eclipse.core.resources.IResource" /> </iterate> </with> <with variable="showInInput"> <adapt type="org.eclipse.core.resources.IResource" /> </with> </or> </visibleWhen> </command> </menuContribution> Expressions will have access to 2 new variables, showInSelection and showInInput (that mirror the ShowInContext variables). They are only updated on part activation and when the ShowInMenu contribution is building its menu. They are updated in the same way as for the old ShowInMenu (if the active part adapts to IShowInSource they come from the ShowInContext, if not they are the selection and an input if available) The target view specified in org.eclipse.ui.menus.showIn.targetId still needs to adapt to IShowInTarget. Outstanding issues: 1) How to easily specify the menu element so it picks up label and keybinding. Menu elements don't currently look for keybindings themselves, maybe MenuManager needs to be updated to support this functionality. Comments? PW
Created attachment 92824 [details] Show In v04 The same behaviour as v03, this also includes a way to associate a quick menu command id with a MenuManager (without anonymous subclassing). PW
Created attachment 92847 [details] Show In v05 Get the Contribution through public API of ExtensionFactory PW
Released to HEAD >20080319 PW
in I20080325-0100
*** Bug 281630 has been marked as a duplicate of this bug. ***
*** Bug 54861 has been marked as a duplicate of this bug. ***
