Community
Participate
Working Groups
I declared commands using org.eclipse.ui.commands and binding with org.eclipse.ui.bindings. These bindings appears in the Eclipse Preference Page, but : - they don't work - they don't appear in the menus, on the right of the action These commands and binding work with Eclipse 3.7 and 3.8, but not with Juno 4.2
Please attach and example command/handler/binding definition that doesn't work. PW
I created an example and its works fine... Sorry for the bug. I'm looking for the error in my project.
if something works in 3.8 it is supposed to work in 4.2 as well so: a) you are doing something illegal that only works by chance in 3.8 b) the compat layer is buggy
After investigating, I found that that my keybinding was declared on a "parentContext". My editor contexts is declared as a children of this parentContext using parentId in the plugin.xml. It seems me that the inheritance between the 2 contexts is not correctly managed. My binding works only when I active the editor context and the parentContext for my editor.
It seems that I have some problems with my declared commands under Juno. These are the command & key binding I declared: <extension point="org.eclipse.ui.commands"> <command name="Choose Target" defaultHandler="com.github.quick.launcher.ui.LaunchChooseAction" description="Choose Target" categoryId="org.eclipse.ui.category.views" id="com.github.quick.launcher.ui.chooseaction"> </command> </extension> <extension point="org.eclipse.ui.bindings"> <key sequence="CTRL+ALT+L" commandId="com.github.quick.launcher.ui.chooseaction" contextId="org.eclipse.ui.contexts.window" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"> </key> </extension> That works fine under Juno if I use the eclipse rcp bundle. But if I install my plugin under the "eclipse for java developers" the command does not show up in the preferences. Everthing worked fine in eclipse 3.7.
Sorry for my comment yesterday, I still don't know what causes the problems for my commands to work under Juno, but in a simple sample project I got it running under Juno. So it seems there is something different going wrong and has nothing to do with the command extension point.
Seems like I have a similar situation with keybindings not appearing in Juno. All my custom key-bindings are not bound when I start the runtime-workbench. I am guessing that I am confirming the same issue. 1. Unbound keys would be the ones that are not normally bound by the Eclipse Workbench such as F6, or F3. Ctrl+V and standard keys however binds fine to my custom actions. 2. I do notice that if I switch perspective they will show up and work correctly, so I suspect there's a problem with the initialization of the workbench and restoring the perspective. 3. Also same behavior with Eclipse RCP and my plugins installed. Have not tested other Eclipse packages. My download is Build id: 20120614-1722, for 32-bit Windows, JDK 1.6. 4. Additional... When I opened my perspective for first time after installing the plugins, then imported a project so that the keybindings would come into effect, then they were not bound. After closing and reopening the perspective they work ok again. 5. There's nothing in the logs that indicates a problem.
Per, I need you to open a new bug with the description of your problem please. Vincent has a problem where activating a child context doesn't take the parent context into consideration in 4.2. PW
Bug 384799 Submitted for my case...
(In reply to comment #8) > Per, I need you to open a new bug with the description of your problem > please. Vincent has a problem where activating a child context doesn't take > the parent context into consideration in 4.2. > > PW It sounds like I've got a similar problem: {{bugzilla|387951}}
I believe what we are seeing is described in this blog post: http://techblog.ralph-schuster.eu/2013/10/13/eclipsee4-problem-with-key-bindings/comment-page-1/ Basically org.eclipse.ui.workbench throws away keybindings with certain contexts. I.e. org.eclipse.ui.contexts.window. If I create a new context inheriting from "org.eclipse.ui.contexts.window" the keybinding will work as expected.
PS: I'm still seeing this issue on Eclipse 4.5
I have the same problem as described in comment 4 with Eclipse 4.6.1. Bindings defined in a parentContext don't work. Here is an example: <extension point="org.eclipse.ui.contexts"> <context id="context.parent" name="Parent Context" parentId="org.eclipse.ui.contexts.window"> </context> <context id="context.child1" name="Child 1 Context" parentId="context.parent"> </context> <context id="context.child2" name="Child 2 Context" parentId="context.child1"> </context> </extension> <extension point="org.eclipse.ui.bindings"> <key commandId="example.command" contextId="context.parent" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration" sequence="M1+1"> </key> </extension> If 'contexts.child1' or 'contexts.child2' is activated the key binding doesn't work, only if 'contexts.parent' is active it works. After debugging the code I think the method org.eclipse.e4.ui.bindings.internal.BindingTableManager.getSequencesFor(...) must be changed. It ignores the parentContexts. Something like that should be added: String parentId = c.getParentId(); if (parentId != null) { table = callee.getTable(parentId); if (table != null) { Collection<Binding> sequences = table.getSequencesFor(parameterizedCommand); if (sequences != null) { bindings.addAll(sequences); } } } But with this it only works with contexts.child1 activated, not with contexts.child2. All parents must be found.
*** Bug 532009 has been marked as a duplicate of this bug. ***
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
