Community
Participate
Working Groups
Open the Keys preference page and show unbound commands. Sort by command. You'll see many, many commands called Show View (View: XXXXXXX) and many, many commands called Preferences (Preference Page: XXXXX). I assume that these are all parameterized commands (if not, they should be). Such unbound commands should only show up once in the Keys page, and should have elipsis. For example, the preferences command should show up as "Show Preference Page..." and the Show View command should be "Show View...". When the user creates a binding to the Show View... command, they should be shown a dialog that lets them pick a view to bind to. The plugin that contributed the handler for the command can also contribute the contents of that dialog, much like JDT's classpath containers. After the key is bound, it can be shown in the list of bindings as it is now (with the elipsis replaced by the actual arguments to the command). This should significantly reduce the number of entries in the keys page and will allow plugins to provide additional guidance in the UI for creating bindings.
> Such unbound commands should only show up once in the Keys page, and should > have elipsis. Note that some parameterized commands also work without a parameter, e.g. Show View (parameterless) opens the Show View dialog. Furthermore, I think parameterizations should also be found if they match the filter. E.g. when I filter for JUnit today, I find the "Show View (View: JUnit)" command (plus the old Views > JUnit, but that will go away with bug 90959). Either the filter would have to be made smarter, or the parametrization could be added as child elements of the unparameterized command in the table (->tree).
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
