Tip: Suppressing Keybindings

Tip: Suppressing Keybindings

I was helping a colleague today with a key binding issue that I think is fairly common. To illustrate the problem, let’s look at what happens when you press CMD+N in the RCP mail sample:

What!? New Project Wizard? That’s not what I wanted! In this case, I actually wanted a ‘New Message’ to pop up instead of that new wizard. I don’t want any of my end-users ever seeing this dialog! What’s the problem here? Well, in simple terms, Eclipse is using its own default key configuration scheme if you don’t set one. So by default, you may get strange results like above or even conflicts with existing key bindings.

What’s the solution?

Well, there are a few ways to go about this but I think the simplest one for most people is to simply create your own key configuration scheme and instruct Eclipse to use it. To do this, you first need to create your own scheme:
[sourcecode language=’xml’]




[/sourcecode]

After that, make sure your bindings are instructed to use this scheme:
[sourcecode language=’xml’]








[/sourcecode]

Finally, you need to create a plugin_customization.ini if you don’t have one already for your application and put this in there:

org.eclipse.ui/KEY_CONFIGURATION_ID=mail.scheme

That’s it. Once you do that, you should have key binding bliss:

Thanks for listening and let me know if this helps. Here is the sample project for reference.

16 Comments
  • Nicolas Bihan
    Posted at 1:44 pm, July 18, 2008

    Hey, thanks for the tip 🙂

    I was struggling from 2 p.m. because I forgot the plugin_customization.ini thing ! You’re tip is just right in time ! 🙂

    By the way, I still don’t understand why a new RCP application get all theses Keybindings by default.

    Nicolas

  • Pascal
    Posted at 5:13 pm, July 18, 2008

    In addition to this, crafting the target or the launch configuration such that the right plug-ins are included would also help. After all if the wizard was not included pressing the key would do nothing.

  • Tom Seidel
    Posted at 4:53 am, July 19, 2008

    For such issues, I prefer Equinox Transformer Hooks with a XSLT Transformation of the key-binding contributing plugin.xml… I really look forward for the related SoC project.

  • jman
    Posted at 11:55 pm, July 18, 2008

    You’re the man! You’ve saved my life. 😉

  • Lars Vogel
    Posted at 6:59 am, July 19, 2008

    Very nice and helpful tip. Thank you.

  • Matthias
    Posted at 3:13 am, July 19, 2008

    Thanks Chris for this wonderfult tip!

  • zx
    Posted at 7:42 am, July 19, 2008

    So Pascal, your case would be ideal but when you have things that are in a plug-in that you need, you’re kind of stuck. You can manually choose to edit the plugin.xml or like Tom said, you can use Equinox Transforms. The reason I didn’t point out Equinox Transforms is that it’s a more advanced topic and for the majority of people that hit this specific problem, the approach I outlined is good enough.

    Tom, Bartosz is making some good progress on the project so hopefully we should see something in PDE around the 3.5M2 time frame.

  • Randy Hudson
    Posted at 1:29 pm, August 1, 2008

    This solution doesn’t really *remove* the “New…” action from the RCP app. CTRL+3 would still find it. But wait, since you’ve defined an empty keybinding configuration, many otherwise useful keybindings like CTRL+3 may be missing now.

    If you can’t get rid of the IDE plug-in, another way to take control of CTRL+N is to declare a more specific context which extends the context associated with the existing CTRL+N binding. Maybe “my.mail.application” which extends “windowsAndDialogs”. Your app window then enables that context, and your keybinding for “New Message” should take precedence over the one for “File->New…”, since it is more specific.

  • zx
    Posted at 9:15 am, August 4, 2008

    @Randy, correct, that is a downfall with this approach. Setting a parent maybe a nicer way of doing this. However, most people wouldn’t care if it appeared in Ctrl+3 as Ctrl+3 shouldn’t be active with a blank key configuration.

  • Corey Straub
    Posted at 1:07 pm, October 7, 2008

    I am trying to do what you described above and having some trouble. I have created my own scheme and key bindings using that scheme but cannot switch over to the scheme. I have created the plugin_customization.ini file as well but not sure if i am adding it to my project properly. All i am doing is creating it and drag and dropping it on the on the project in eclipse to add it. Is there anything else that needs to be done to get the .ini file to used? Otherwise i am not sure what my error is.

  • zx
    Posted at 7:31 am, October 9, 2008

    @Corey, did you figure it out yet ;)?

    Make sure when you export that you remember to include the plugin_customization.ini file at the root of your application.

    Another route is to set this preference while your application is starting up. For example in your WorkbenchWindowAdvisor class.

  • Amos
    Posted at 11:43 pm, January 18, 2009

    Is there any way to get this to work with RetargetActions? I’ve got a retarget action programmatically defined, I’m calling setActionDefinitionId() for it and using the same commandId as on a declaratively defined (plugin.xml) command, and I’d like to bind that command to the F5 key (refresh).

    Key bindings for “normal” declaratively defined actions and commands work just fine using the method you described (thanks btw!), but my retarget action (which is only shown on the toolbar when an appropriate editor is open) won’t respond to F5. I’m reluctant to make it a “normal” action, and I haven’t been able to get declaratively defined retarget actions to work the way I want.

    Any hint would be greatly appreciated 🙂

  • Amos
    Posted at 12:32 am, January 20, 2009

    Found a suitable alternative – instead of a RetargetAction, which I’d wanted to use mainly because I wanted the icon to appear on the coolbar only when the relevant editor type was open, I’m now using the extension point org.eclipse.ui.editorActions and simply linking my editorContribution to my target editor type. The binding for F5 works fine with that, using the tips in this blog. Cheers 🙂

  • jon
    Posted at 11:20 am, February 19, 2009

    What’s this plugin_customization.ini thing? Where is it documented? Why wasn’t it a part of the RCP Mail Template, since omitting it means that template is practically bugged?

  • Lars Vogel
    Posted at 8:36 am, April 17, 2009

    Chris, I tried to use WorkbenchWindowAdvisor to set the key binding scheme with the following code in the ApplicationWorkbenchWindowAdvisor and ApplicationWorkbenchAdvisor constructor.

    IPreferenceStore store = PlatformUI.getPreferenceStore();
    store.setDefault(IWorkbenchPreferenceConstants.KEY_CONFIGURATION_ID,”myscheme”);

    ————-
    Quote from you: Another route is to set this preference while your application is starting up. For example in your WorkbenchWindowAdvisor class.
    ————-

    I also posted to the o.e.rcp newsgroup.