Community
Participate
Working Groups
Do the accelerator ids really need to be qualified with the plugin id. For example, given the following from the UI plugin.xml <acceleratorSet scopeId="org.eclipse.ui.globalScope" configurationId="org.eclipse.ui.defaultAcceleratorConfiguration"> <accelerator key="Ctrl+F4" id="org.eclipse.ui.file.close"> </accelerator> would an accelerator id of "close" rather than "org.eclipse.ui.file.close" be acceptable? It may seem minor but the long names just bulk up the memory usage. Further question, would the be more aptly maintained in the prefrences store or as a properties file?
In general you want to disambiguate them by plugin. But perhaps the workbench actions could be special and not have the prefix. Moving to Chris to comment on the ids. We need to use the registry here to get translatable names for action definitions. For configurations, there should be no human-readable strings, so we could consider other mechanisms. However, multiple plugins can contribute to a particular configuration/scope, and the registry's support for mixing in contributions here is a big help.
i believe all ids need to be unique, this method guarantees that they are provided the individual plugin developer doesn't make a mistake. personally, i don't understand why the registry couldn't prepend the plugin id to the partially qualified values of all id attributes during load time. this would reduce the bulk in the plugin.xml and it is something that could be accomplished at least eclipse wide - the registry could prepend the plugin id for plugins whose id begins with "org.eclipse", it would take a concerted effort among us, but wouldn't break external plugins. maybe introduce an escape sequence to represent 'replace with plugin id'. on the other hand, perhaps my ignorance has made me a little skeptical that reducing string sizes in the plugin.xml is a performance-increasing path we should be heading down in the first place. i thought perhaps we should be thinking of something bigger, like preparsed dom tree or a stand alone startup class file..
The platform does not know about plugin.xml elements below <extension>. These are defined by the relevant <extension-point>. This makes it impossible for Eclipse to prepend anything to attributes which happen to be called "id". The observations about this direction are apt except that these ids are used pervasively by the UI code regardless or what the registry does with them. Future versions of the registry may be able to reduce the redundancy but will likely not be able to eliminate it. Basically the observation here is that strings are not free so anything we can do to reduce their use is good.
Defer
It should be possible to automatically prepend the plug-in identifier in this case.
I've thought about this some more, and I find it difficult to find a way to do this in a backwards-compatible way. If I have a key binding with id = "foo.bar", how do I know whether to prepend the plug-in id? There is no requirement that the plug-in id prefix every identifier. There is also no requirement that id only contain one dot after the plug-in id. In fact, you could even structure them as "commands.org.eclipse.ui.commandName", if you wanted. Any ids that already exist are API and can be referenced from code. This leads to similar inconsistencies as described in an email thread you were paty to (subject: "ltk.ui plug-in and related changes"). I'm going to close this bug as "WONTFIX".
