Community
Participate
Working Groups
ActionFactory should expose actionDefinitionIDs of retargetable actions. When clients want to register an action via actionBars.setGlobalActionHandler(ActionFactory.XXX.getId(), fXXXAction); , they need to set the actionDefinitionID of the given fXXXAction to the same actionDefinitionID as the RetargetAction created by the ActionFactory in order to see keybindings when the same action is shown in the context menu. Since the actionDefinitionID cannot be changed without breaking clients, it would be best to expose it. Today, clients have to look at the initializer of the ActionFactory constant and copy-paste the actionDefinitionID from there (or look at the command id in some plugin.xml, but that's always the same).
*** Bug 74569 has been marked as a duplicate of this bug. ***
Any plans to address this issue in 3.2?
No plans at the moment.
The action factory actions set their own actionDefinitionId (either in the factory, or the action itself). It may still make sense to document these so that clients can define their own key binding extensions without having to grovel for the constant.
Some of the constants are available in IWorkbenchActionDefinitionIds, but some are missing there (refresh), have another name (find/replace), or are different (revert vs. revert to saved).
Moving Dougs bugs
This is interesting in that we definitely should be publishing command ids that are API, especially for the global retargetable actions like COPY, PASTE, etc. ActionFactory is probably not the place to do it... with the changes in 3.3 it will return a CommandAction that has no action definition ID at all. Later, PW
> ActionFactory is probably not the place to do it... with the changes in 3.3 it > will return a CommandAction that has no action definition ID at all. I don't care too much where the command IDs are defined. However, making ActionFactory return an Action without an actionDefinitionID would be a breaking change (e.g. for clients using the workaround from bug 74569).
Sigh ... I won't pull the rug out. PW
Could this please be fixed in 3.4?
I'd like to publish a list of commands that the platform supports, so lets do it in 3.4. PW
Adapting summary, since there should be API for all non-internal actionDefinitionIDs / commandIDs defined by a plug-in. A good new example of why we really need this is the proliferation of "org.eclipse.ui.navigate.linkWithEditor" manifest strings to support bug 79581.
> Target Milestone: 3.4 Shouldn't we try to get APIs done for M5?
(In reply to comment #13) > > Target Milestone: 3.4 > Shouldn't we try to get APIs done for M5? yes, but other more important API has pushed this down the list. PW
Paul, M6 is API freeze, so what should tagging this to M7 tell us? ;-)
I'm currently working an an Eclipse corner article (bug 223445) about the command framework. In this article I encourage people to re-use built-in commands (e.g. "org.eclipse.ui.edit.delete"). For registering local handlers you need the command ids -- constants would be great! I wrote a little script to extract all command ids from the org.eclipse.ui plugin and created an HTML table for the article (see attachment).
Created attachment 95831 [details] EclipseUI3.4M6.html
Using the same script I generated the file IWorkbenchCommandConstants.java containing all commands defined in org.eclipse.ui. See attachment.
Created attachment 95834 [details] IWorkbenchCommandConstants.java
Released an initial cut to HEAD >20090302 More constants can be added (some in the next 4 days, others in 3.6 :-) PW
Hi Paul, thanks for adopting the constants to the API. In your latest commit you removed some of the global command ids again -- which would have been be useful to register local handlers for view specific implementations, some examples: * org.eclipse.ui.edit.findReplace E.g. custom local finders, to search an entry in a long table or an element in a graphical editor. * org.eclipse.ui.navigate.goInto * org.eclipse.ui.navigate.up Usefull also to navigate in custom tree views. In my current project we make heavy use of these and other predefined commands. Having them in the API would be great! -marc
(In reply to comment #21) > Hi Paul, Hi Marc, If you have those 3 specific ones that you need, I can add them back. I didn't see a usecase for the navigate ones and thought that findReplace was tied to a more framework type action (as opposed to a retarget action). PW
Hi Paul, yes, these are the ones our application has a use case for. On the other hand command ids are used in different places within the Eclipse platform code itself, for example org.eclipse.ui.fieldassist.ContentAssistCommandAdapter.CONTENT_PROPOSAL_COMMAND If there is a central constants class for command ids, maybe all constants should move there replacing such private definitions. -marc
In I20090310-0100 PW
