Community
Participate
Working Groups
Build 20011219 From EC post "can I add to Navigator's open context menu?" by Dave Carlson (dcarlson@ontogenics.com). Is it possible to add a new menu item within the"open" section of the ResourceNavigator's context menu? I'd like to add a new item following the "Open With..." submenu, not within it. Is it also possible to add an item within Open With... ? The only menu extension I find is "additions" in the last menu subsection. I thought I remembered seeing this question a few weeks ago, but can't find anything related when seaching the archives. NE replies: The Open With... submenu contains items corresponding to the editors with which the file can be opened. Are you defining your own kind of editor? If so, you should get this for free by specifying the appropriate file extensions in the editor extension XML. If you're not defining your own editor, it is not currently possible to add to Open With submenu since it does not have an ID which can be referred to in the action contribution's path. DC replies: Thanks, Nick. I am creating a menu item for "Open UML Model" that is applicable to project files containing UML models represented in XML format (i.e. the XMI standard). When I open that file, I create a tree viewer of the model, which is then used to open other editors. So it's kind of a hybrid case. Although, logically, it seems to make more sense for this menu choice to appear with other Open choices. But this seems to be impossible. The association of an editor with a file extension is proving to be problematic. The extension .xml is so overloaded that it's not possible to associate it with exactly one editor. You need to look at the first few lines to determine its content type. At best you can list several possible editors and/or viewers, some of which will fail to open the file (unless it's fully specified, like "plugin.xml"). I looked through the code for the Navigator and only found a menu ID for "additions". Are there any others? NE replies: Some of the actions have their own ids. See OpenAction.ID, which is org.eclipse.ui.OpenFileAction. So you could add your action after "Open". Unfortunately there's no published list of these currently, but most actions used by the Navigator can be found in package org.eclipse.ui.actions. In general you can rely on any action IDs which are declared in public fields of public classes in non-internal packages. Any others are subject to change.
From the e-mail discussion we had... The draft UI guideline document is recommending the use general categories for editor/view menus. We should update the standard workbench views to make use of these categories (once agreed upon) and also publish a pre/post group id for each category so other plug-ins can contribute to them. We should also update the guideline document to recomment plug-in developers of views/editors to not only adopt the categories but also the pre/post group ids
From Simon Arsenault Saw the posting on the newsgroup and the replies. Here some additional info we should look into also... In the UI guidelines written by David, Greg, Jin, and Julian, there is some talk about recommended mwnu categories for editors and views. For example, it is recommended that each view's context menu should have the following categories: New Open Navigate & Show In Cut, copy, paste Delete Additions Properties We should think about recommending that the view/editors to provide group ids for these categories so other plug-ins can add to them (this would help solve the problem posted in the newsgroup). Maybe it could be a pre and post group id for each category? (i.e preOpenGroup, postOpenGroup, etc) If we decide to recommend this, the guideline should be updated. We should also recommend that new categories added by the view should have a pre/post group ids.
In build >20020115 There are 4 other places that are predefined by Eclipse for addition of an action to the popup menu of the Navigator view. goto - added after the GoTo menu open - after the Open With... entry refactor - after the Add Bookmark (for files) or Delete (for other resources) entry workbenchstate - after the Refresh From Local entry
I see a few remaining issues that we should address (maybe I should be opening a new PR but all the relevant info is in this one already). 1) The new group names do not all match the categories specified in the proposed UI guideline. We should stay consistent otherwise it is just confusing to the user. I would wait until this categories section of the ui guideline is approved, then add in the necessary groups 2) We need to apply this to all of the standard views (bookmark, outline, task, properties, etc) 3) The code to add the group is not quite correct. Currently, its action of category M action of category M action of catefory M ... group of category M group_end of category M instead, it should be group of category M action of category M action of category M action of category M ... group_end of category M that way you can add at the beginning or end of a category. There maybe an exception for the Properties category, where we always want Properties action at the end so maybe in this case the group_end category is before? Anyway, we should think this thru and come up with a consistent approach for all views (and how views from other plugins will need to change to be consistent)
Rollback on the additions pending discussions on this as there are knock on effects on existing views.
Consider doing this as a post 2.0 enhancement.
Still waiting on decision on this from usuability team.
There is more to this than just adding groups to the menu. The original reporter wants different Open actions for different kinds of XML files. Another scenario is allowing a file to be opened in an external editor. We want to be able to override or extend what the default open / double-click action does. For example, if the user choose Open With / {my special XML editor} or Open With / External Emacs, then the workbench should remember this (as it does for eclipse and system editors) and do this by default the next time the file is opened using double click. Should investigate whether mime types provide any help here for distinguishing between different kinds of XML files.
There is another PR (maybe even 2-3) that deal with determining what editor to use to edit a file. Mime types was one option. Some system use the first X bytes to determine the editor (have a DB file to editor associations). There are other options. When a file is created in eclipse, the wizard can set a property on the file which indicates the editor to use. Unfortunately, it is not persisted, so when the file is checked out on another machine, the editor association is gone. I think we could address a lot of problems if there was a way to persist this info.
Editor management issue - moving to owner of that work.
We do not plan on fixing this problem directly although the new menu story should help with the item placement when it is finished. We can now handle different types of XML content via content types. Marking the remainder as WONTFIX.
