Community
Participate
Working Groups
We need to be able to define keybindings for a set of commands which is not know at development time, but created by the end user. We want to create IDs for commands programmatically, and allow the user to configure the accelerators for the commands using our own UI instead of the current preference page. The scenario is tools displayed in a palette. It should be possible to activate a tool using a user-defined keybinding instead of using the mouse. The keybinding will be set by the user using an existing palette customization dialog, not the Keys preference page. This allows the user to control all aspects of the palette in one place.
*** Bug 84656 has been marked as a duplicate of this bug. ***
Randy: for your case, would the parameter mechanism proposed in the "contributions proposal" (posted to platform-ui-dev) be sufficient? James: Does the same apply for you?
Douglas: I'm not sure, my reporting of this bug got linked into the bug covering the proposal you mention, but Nick asked me to open a separate bug. If it was the case that we could programmatically define commands (which I think we can now - can you confirm this) and programmatically define the keybindings on these commands, then I think it would be adequate.
Following my previous comment, I realise that Commands cannot be programmatically created. Consequently parameterising Commands isn't going to work for us since you would need to know prior to runtime precisely what Commands are required in order to declare them in the plugin.xml. It is a shame that we can't choose to switch off the command manager and allow the interpretation of IAction.setAccelerator(..) to set the key binding (and handle the consequence of conlicting bindings and contexts).
Same for me. Parameters don't help. BTW, I've opened a separate bug about View definitions not getting free command definitions. The workbench know about all defined views, and should programmatically create commands so that the user can assign *ANY* view to a keybinding. A 2.1-based plug-in defining a view should work without modification. If you solve this problem, you've solved mine.
Randy: parameters will solve the "show view" problem. James: Your case is interesting. It could be solved with parameters, but I'm not sure that is an ideal way to approach the situation. We could make it so that advisor can replace (or completely disable) the commands architecture.
How? I thought that all parameter values must be declared in a plugin.xml somewhere.
Randy: No. It will be a callback into code. It's also designed in such a way so that the callback will only be needed if the keys preference page is shown.
(In reply to comment #6) > James: Your case is interesting. It could be solved with parameters, but I'm > not sure that is an ideal way to approach the situation. We could make it so > that advisor can replace (or completely disable) the commands architecture. That would be ideal.
Douglas : Are there any plans for this and (if so) what is the timeline?
I'm not sure if it will be ready for 3.1, though I will be trying. If I set the milestone, then it indicates that I am fairly confident of when it might ready.
Douglas: This is becoming increasingly important to us, to the extent where we may have to allocate internal resources to provide a solution. We will submit any solution as a patch against head for consideration to be included in the release. If there are any pointers you can give us on appropriate solutions then this would be very helpful. (In reply to comment #11) > I'm not sure if it will be ready for 3.1, though I will be trying. If I set the > milestone, then it indicates that I am fairly confident of when it might ready.
The API freeze has passed. This will not appear in 3.1. As a note, parameters do exist. Though I'm still not sure this will address James' issues.
parameters aren't enough for me either since I don't want my keybindings to appear in the global preference page.
Randy: if you want things to not appear in the keys preference page, then use a listener on the widget. *HOWEVER*, this is not a recommended approach. the whole point of key bindings is to have them modifiable by the user.
The keybindings will be modifiable by the user in a preference dialog local the GEF palette. The default preference page for editing keybindings is not appropriate in this case. It doesn't make sense to be able to edit every property for a palette entry except for its keybinding, and to have to go to some other ackward UI with global scope just to change one more property. So, we want to place a "Key Sequence/Name"-like widget in our own preference dialog.
Douglas: Just pinging this bug. Can you let me know your current thoughts on when this might get done? If it is someway down the line then we could potentially look at this internally and submit a patch, however we would probably need some assistance in understanding the internals of the current keybinding architecture.
Parameters are available in 3.1. KeySequenceText is public in JFace in 3.1. I'm not sure what you still might want. Could you be more specific?
(In reply to comment #18) > Could you be more specific? I would like the ability to reimplement the keybinding preference page.
Douglas: I'd not heard of KeySequenceText, but looking at the API this seems only to be applicable to Text widgets (please correct me if I'm wrong). See comment #4 for our issue with parameters. In a nutshell we want to add keybindings to context menus (for example CTRL + 'S'), unfortunately these keybindings are not known to the system until after Eclipse has started. We simply need a programmatic way of doing this.
This would be rather helpful for JDT/UI & Text as well. In certain situations we'd like to temporarily register special handlers for keybindings. For example in the Quick Outline (Ctrl+O), we would like to bind the toggle handler to the keybinding that originally started the action (see bug 54815). Programmatic access to activate keybindings would also open a way to solve bug 115460 by registering the keybindings in a temporary context that is active in the dialog while the text field has focus.
Moving Dougs bugs
Programmatic access to most of the services is available in 3.2 (Commands, Contexts, and Handlers). Descriptions are available on the wiki http://wiki.eclipse.org/index.php/Platform_UI_Command_Design But there are notes in the design that IBindingService is not to provide programmatic addition and removal as general API for performance reasons. I believe it is to specifically prevent adding and removing keybindings in response to some listener. That being said, I believe that there is support in the API for "I'm writing my own keys preference page". Check out the javadocs for IBindingService#savePreferences(Scheme activeScheme, Binding[] bindings). PW
So I think IBindingService#savePreferences(Scheme activeScheme, Binding[] bindings) will address Randy and James. Markus, we'll be looking at the CTRL+O opens the window and then CTRL+O toggles the superclass methods in 3.3M6 PW
Still need to find a solution for CTRL+O and such toggles. PW
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.
