Community
Participate
Working Groups
Many plugins/Eclipse based applications can have many common actions/menues that are not present in the Eclipse workbench. Examples can be such menus like view and tools. While it is obviously not possible to find all such items but some could be found (namely the view menu) and corresponding constants could be added to the workbench (i.e. to the IWorkbenchActionConstants). This will facilitate integration between plugins from different vendors (i.e. there won't be two top menus named Tools). Initial list can be created by quering the newsgroup.
See IWorkbenchActionConstants, ActionFactory, ContributionItemFactory, and IDEActionFactory for relevant existing ids. I understand that this is a request for the Workbench to define some menu ids that are somehow common across all (or most) RCP apps though.
Undeprecating the M_VIEW in an IWorkbenchActionConstants could be a good start :)
It's unclear whether adding such ids to the generic workbench is the right approach. The workbench itself should not define any particular menu layout. The menu layout is defined by the product, in its WorkbenchAdvisor's fillActionBars method. This is then augmented by particular actions sets, defined either by the product's plug-ins, or by other plug-ins that extend the product. If a component is designed to be reused across different products, it cannot make any assumptions about the menu structure. Any such dependencies would have to get factored into a product-specific plug-in. Currently, the workbench extension points do not facilitate this, since an extension typically both defines the thing being added, and also describes where it goes in the UI. For example, an action set not only defines the available actions in that set, but also places them in the UI using a specific menubarPath or toolBarPath. Likewise for preference pages, where a preference page extension not only defines the page, but also specifies the category under which it appears (unless it's a top-level page). Allowing the declaration of an extension to be specified separately from its UI placement is something we're planning on addressing for 3.1. So rather than having the workbench define some set of well-known menu ids, I'd like to take a hard-line approach and say that the workbench should not define any such ids, and that all such ids are product-specific. This will then push on the real limitations that are encountered when trying to design reusable components, and we can look at how best to address those limitations. It would help us if you could provide some concrete examples of where you run into these id dependencies. Once concrete example that we see in the SDK is the dependency between org.eclipse.ui.ide and org.eclipse.update.ui. Previously in 2.1, org.eclipse.update.ui defined an action set providing the Help > Software Updates submenu and items. Since this made assumptions about the menu layout, we pulled this action set out of org.eclipse.update.ui and moved it to org.eclipse.ui.ide. However, that meant that we had to add a dependency on org.eclipse.update.ui from org.eclipse.ui.ide. This tightly couples the IDE to a particular update manager, which we'd like to avoid. It should be possible to ship the IDE without any update manager, or to plug in a different one (e.g. Tivoli). A better way of factoring this would be to have org.eclipse.update.ui as the reusable component, with no menu structure dependencies or other product-specific dependencies, and then have an org.eclipse.update.ui.ide plug-in that provides the IDE-product-specific extensions. In this case, it would be nice to be able to declare the reusable actions in org.eclipse.update.ui, but provide define their UI placement in org.eclipse.update.ui.ide.
*** Bug 78836 has been marked as a duplicate of this bug. ***
Deferring. No changes were made here for 3.1, but will reassess in 3.2.
Either we should make RCP entirely application-agnostic and deprecate all the menu constants in IWorkbenchActionConstants, or come up with some minimal set of "standard" menus that we can expose as API. The problem is that that set is platform-specific -- each platform has its own UI guidelines for what menus should do what.
Didn't mean to mark as WONTFIX.
It's even clearer to me now that RCP apps are being used in a great variety of contexts, with a great variety of menu structures. The RCP base should not encourage any particular menu structure.
