[platform-ui-dev] Resolving Key Configuration Clashes

[Thomas Fletcher <ThomasF@xxxxxxx>]

Folks I'm looking for some advice.

Both the JDT and the CDT projects work with "source code" and a large
number of the commands and categories which one project would define, 
the other would like to use and vice versa.  For example:

Command category collisions

Source: 
Refactoring:
 --> Defined in org.eclipse.jdt.ui as 
      org.eclipse.jdt.ui.category.source,
org.eclipse.jdt.ui.category.refactoring
 --> Also desired by CDT (and other languages likely)

Command definition collisions

Source > Format: 
 --> Defined in org.eclipse.jdt.ui as
      org.eclipse.jdt.ui.edit.text.java.format

These are just a couple of examples.  The question I have is that from a
user
perspective they would expect to be able to look at the Source category and 
see all of the Source related items whether it is Java, C/C++, Cobol, 
Smalltalk, etc "source" they are talking about, however since these language
modules can all either be present, or not, each one has to define its own 
command category with different id's (experimentation indicates that
declaring
two categories with the same id/name in different plugins will create two 
different categories, but with the same name).  

The design of the key configuration dialog also leads the user to believe
that
if they go to the Source > Format option they should be able to configure
the
action for any editor/environment they want, when in reality it (in this
case)
only would apply to the Java source/environment and not the C/C++ one.

What is the best way to approach this dilemma?  The current solution from a 
CDT perspective is to have specific named categories (and ids) such as:
  C/C++ Source
  C/C++ Refactoring

and then the user has an indication that when they choose
  C/C++ Source > Format

that they are choosing formatting options for C/C++ code, regardless of
where
you bind the invocation of that action (ie the Java Editor, the C/C++
Editor,
a third party editor like Slick Edit).

If this is the correct approach, then should the "generic" entries be
defined
in org.eclipse.ui and then Java centric items moved to Java prefixed
categories
such as Java Source and Java Refactoring.

If this is not the correct approach, then please let me know so that the CDT
team can do a better (ie cleaner) integration of its commands.

Thanks,
 Thomas