Community
Participate
Working Groups
3.0 The keys preference page is not yet API (see bug 73510) but when it is there are problems using it with RCP applications. There are two ways for an RCP application to define key bindings for commands: 1. define then in the default key configuration, with the caveat that there are many keys already assigned by org.eclipse.ui 2. define a new key configuration and assign all key bindings for your application to the new configuration. The problem will be that although the keys are assigned to a configuration, essentially scoping them, the keys preference page shows ALL commands as possibly key bindable. This is because the workbench has no concept of command namespaces, or command configurations. It becomes confusing because all RCP applications inherit org.eclipse.ui commands and dialog or pages that simply display all commands are useless in a RCP applications because the listed commands may not make sense in that application.
Here is the complete scenario I gave to Nick: Scenario: Configuring key bindings in an RCP application Bug 73795 [RCP] activeKeyConfiguration extension point doesn't work Bug 73510 [RCP] keys preference page not available in non-ide applications Bug 77286 [RCP] RCP friendly keys preference page User: Luke is running an Eclipsilla, the eclipse based web browser client. We wants to add a key binding to the "mark as read" action. He goes to the keys preference page and tries to find the "mark as read" command, but he finds it difficult because there are many commands that don't seem to apply to his application such as "Close all perspectives", "Customize perspective". He has never seen that term used in Eclipsilla. Developers: There are two ways an RCP developer have of defining key bindings: (1) define then in the default key configuration, with the caveat that there are many keys already assigned by org.eclipse.ui, or (2) define a new key configuration and assign all key bindings for your application to the new configuration. The problem will be that although the keys are assigned to a configuration, essentially scoping them, the keys preference page shows ALL commands as possibly key bindable. This is because the workbench has no concept of command namespaces, or command configurations. It becomes confusing because all RCP applications inherit org.eclipse.ui commands and dialog or pages that simply display all commands are useless in a RCP applications because the listed commands may not make sense in that application. Issues: It may be possible to use activities to filter commands, but the activity definition may filter out more than the developer wanted, they will apply to all UI elements. The activity definitions could also become complicated if the RCP application uses some of the workbench commands, such as Delete, Undo, Copy, Paste. Maybe contexts could be used, a developer could group existing commands into contexts and the keys preference page could be shown based on a predefined context. Commands shouldn't be defined in a context, but instead they can be added to contexts some other way.
This is an interesting problem. As mentioned above, it's independent of key bindings. It really has to do with the visibility of commands themselves, whether or not they have keybindings. Would could introduce command -> product bindings so that commands would only appear if associated with the current product. Need to ensure that this would not break our story for optional components.
The keys pref page can now be included using API (wsee bug 73510). No further work planned here for 3.1.
If an action is not registered with the key binding service, then the key binding still misleadingly shows up on menus, and it also still shows up in the Keys preference page - yet any key binding won't actually work. Is it possible that this requested RCP friendliness could be achieved by making sure that only commands with properly registered actions are shown in the preference page(and likewise also not showing them in menus, although that's not an RCP issue). I still don't fully get the key binding approach - in particular the fact that an action is associated to a command rather than the other way around. I had a quick look at the KeysPreferencePage code and saw Command.isEnabled() and wondered if that might help, but it didn't - I've now seen that commands mostly don't have handlers at that point. I poked around a bit more and it's far from obvious whether there is a reasonable way for KeysPreferencePage to know whether a command's associated action(s?) is properly registered for key binding. I guess I also don't know whether a lot of those org.eclipse.ui commands are in fact already registered, in which case this approach wouldn't help. But I'm guessing they're not registered, because I had to explicitly register actions such as the CLOSE_PERSPECTIVE action myself. Basically, I would like commands(and any associated bindings) to be invisible if they have not been "registered" in some way, as Nick suggests; however, since there is already a key binding registration process that must be followed, it seems that that might be able to be used, and be sufficient, rather than having to implement a whole approach for command->product mapping(and thus be doable for 3.1?).
A workaround is: Create a new configuration, assign only the commands you need, set preferenceCustomization property on your product, create the needed file, add org.eclipse.ui/KEY_CONFIGURATION_ID to that file: @@ plugin.xml @@ <extension point="org.eclipse.ui.bindings"> <scheme name="NewConfiguration" id="newAcceleratorConfiguration"/> <key commandId="org.eclipse.ui.file.close" sequence="M1+W" schemeId="newAcceleratorConfiguration" /> ... </extension> <extension id="product" point="org.eclipse.core.runtime.products"> <product application="de.application" name="Sample"> ... <property name="preferenceCustomization" value="plugin_customization.ini"/> </product> </extension> @@@ plugin_customization.ini @@@ org.eclipse.ui/KEY_CONFIGURATION_ID=newAcceleratorConfiguration
I agree with comment 4 that only actions contributed via XML or registered in ActionBarAdvisor should have active (visible) keybindings. While we're at it ... is there a way to hide contributed preference pages? Let's say that I want to use org.eclipse.help.ui but not have it's pref pages show up in my preference dialog. I could remove the pref page definitions from the plugin.xml's before deploying to a customer, but that feels quit "hackish" :D
Thanks for clarifying how to use schemes in place of keyConfigurations. Unfortunately, users will still get confused about the proliferation of unusable commands, but a real problem occurs because I want commands with names and categories similar to or identical to ones defined by org.eclipse.ui but which I don't use.
Ian: See also Bug 32189.
Doug, are commands filtered by activity? If so it would be possible to create a hidden, disabled activity to filter out unwanted commands.
Reassigning bugs in component areas that are changing ownership.
Ben, didn't you file a bug similar to this?
Commands are defined in a global namespace, and at least partly by design. Having a view step forward with its view-scoped copy command (as opposed to supplying a handler) would lead to all sorts of unpleasantness. In 3.3 the keys preference page added filters. The first few were hard-coded into NewKeysPreferencePage, but if extended that might allow an RCP app to choose which commands to display. PW
In theory the product customization support could address this: http://wiki.eclipse.org/index.php/Product_Customization <-- general overview http://wiki.eclipse.org/index.php/Equinox_Transforms <-- getting started with the equinox incubator transform plugins Another possibility could be a single file with keybindings that would be consulted at the product level, overriding all others. It'd be work to construct but would provide the "buck stops here" control.
(In reply to comment #11) > Ben, didn't you file a bug similar to this? > Did you mean Bug 133407 ?
Yes, that's the one I meant.
Prakash is now responsible for watching bugs in the [RCP] component area.
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.
