Community
Participate
Working Groups
I20040310 I need to define (retarget) an existing command but don't want to inherit all other commands. Currently I can either get all commands (see registerForKeyBindings) or only the ones for text editing. The problem can be seen easily when using the debugger's new inspect pop-ups: if you press Ctrl+H it opens the Search dialog because Ctrl+H is in the global context. Note: I don't like to define a new key binding context since the user should be able to invoke the command with its predefined key sequence and should not be forced to redefine the same key sequence for the same command but in a different context.
Is this covered by bug 31731 which is targeted for 3.0 M8? I guess even if I define a new context it will automatically inherit from global, right? So the question is: how can I disable the global context?
*** Bug 55349 has been marked as a duplicate of this bug. ***
Chris, can you give us an ETA for this? If it doesn't make it into M8 then we need to take out the key binding support for the Quick Outline (Ctrl+F10 to show the view menu) due to bug 55349.
The new key binding code released for I20040322 broke the existing support to open the view menu using Ctrl+F10. For now I removed all corresponding code.
I don't feel like I have a complete understanding of what you're doing, but the following might work. If it doesn't, can you provide more details? Thanks.... 1.) Define a context for your key binding to exist in. 2.) Make a submission through WorkbenchContextSupport binding the context to your shell, as well as in whatever other situations you need (?) it. 3.) Define a handler, and submit the handler through WorkbenchCommandSupport. It is currently not possible to restrict a handler to a particular shell, though I'm considering that support for M9. If it is important for you, please say so. You can also try messaging me on Sametime or IRC (irc.freenode.net#eclipse-dev) -- IRC is preferred.
Concrete use case: I want to hook an action to the show view menu command I didn't want to define a new context (at least not visible to the user). Let's say someone defines a command X in some context and the user configured a key sequence for it. Let's assume I have no influence over that context i.e. I cannot ask to change the context(s) for command X. Now, I would still like to use that command and its sequence in my dialog without giving the user the burden to know about some special "QuickControl" context.
(In reply to comment #6) > I didn't want to define a new context (at least not visible to the user). > Let's say someone defines a command X in some context and the user > configured a key sequence for it. Let's assume I have no influence over that > context i.e. I cannot ask to change the context(s) for command X. Now, I > would still like to use that command and its sequence in my dialog without > giving the user the burden to know about some special "QuickControl" > context. This does make sense to me. Commands are not defined in a context. Bindings are defined in contexts. You always have influence over contexts: anyone can activate and deactive contexts. In your dialog, activate the context containing the binding you wish to use.
(In reply to comment #7) > In your dialog, activate the context containing the binding you wish to use. That's exactly the point of this bug. The binding looks like this: <key sequence="M1+O" contextId="org.eclipse.jdt.ui.javaEditorScope" commandId="org.eclipse.jdt.ui.edit.text.java.show.outline" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"/> Now, when the dialog is active, we don't wan't to activate all commands from the javaEditorScope (which would not work anyway, since it inherits org.eclipse.ui.contexts.window and not dialogAndWindow (bug 115460 comment 4)). We only want to activate the particular command "org.eclipse.jdt.ui.edit.text.java.show.outline" with the keybinding it has in javaEditorScope.
The way to do this is to do the following: <key sequence="M1+O" contextId="org.eclipse.ui.contexts.dialogAndWindow" commandId="org.eclipse.jdt.ui.edit.text.java.show.outline" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration" />
Moving Dougs bugs
Is this still a problem in 3.3? PW
> Is this still a problem in 3.3? Yes.
(In reply to comment #9) > The way to do this is to do the following: > > <key > sequence="M1+O" > contextId="org.eclipse.ui.contexts.dialogAndWindow" > commandId="org.eclipse.jdt.ui.edit.text.java.show.outline" > schemeId="org.eclipse.ui.defaultAcceleratorConfiguration" /> > If I read Doug's reply correctly, there's no way to use the javaEditorScope keybindings individually in a dialog. He's suggesting just moving your keybinding into dialogAndWindow. For finer control, you could create a javaCommonScope context (probably parented off of org.eclipse.ui.contexts.dialogAndWindow) and place the common keybindings you want in there ... then activating that context with the java editor and your dialog would allow them to continue working. PW
Dani, is that an option?
Paul, I tried that: > <key > sequence="M1+O" > contextId="org.eclipse.ui.contexts.dialogAndWindow" > commandId="org.eclipse.jdt.ui.edit.text.java.show.outline" > schemeId="org.eclipse.ui.defaultAcceleratorConfiguration" /> and as you remember I also tried your patch from bug 126044, comment 7 and see also bug 126342. For some strange reason the context for Ctrl+O's shell is still the java editor scope and even if I do this: IContextService contextService= (IContextService)site.getService(IContextService.class); contextService.activateContext(IContextService.CONTEXT_ID_WINDOW); IHandlerService service= (IHandlerService)site.getService(IHandlerService.class); service.activateHandler(invokingCommandId, getToggleHandler(invokingCommandId)); service.activateHandler(fShowViewMenuAction.getActionDefinitionId(), new org.eclipse.jface.commands.ActionHandler(fShowViewMenuAction)); Neither F10 or Ctrl+O work in the dialog. So - any help to make this work is really appreciated i.e. I don't absolutely require this bug to get resolved but a solution to remove the deprecated code out of AbstractInformationControl and its subclasses.
Hi Dani, I'm investigating. Which dialog class are you working with right now? And you want CTRL+F10 to be fShowViewMenuAction for the dialog, and CTRL+O to be "org.eclipse.jdt.ui.edit.text.java.show.outline" for the dialog? Is it InspectPopupDialog? PW
>Which dialog class are you working with right now? The concrete class is JavaOutlineInformationControl which extends AbstractInformationControl (used in JDT UI for the Quick views) extends PopupDialog from Platform UI (JFace). >and you want CTRL+F10 to be >fShowViewMenuAction for the dialog, Correct. > and CTRL+O to be "org.eclipse.jdt.ui.edit.text.java.show.outline" for the > dialog? It does two things: - while editor is active it opens the Quick Outline - while Quick Outline is active it toggles its input >Is it InspectPopupDialog? No, that's from Debug.
There are no plans to provide other scoping options in keybindings. There are either the hierarchical set of contexts and/or the selected scheme and its parent schemes. PW
