Community
Participate
Working Groups
20031111 I'm working on a dialog that works similar to the 'CycleEditorAction'. A key sequence (configured in by the keybinding support) opens a (lightweight) dialog. Pressing the same key sequence again toggles the view in the dialog. I mimic'ed the code in CyclePartAction.addKeyListener, line 300. The transformation of key events to KeySequence uses an internal class KeySupport. So here is my questions: - Is there a different way for me to compare incomimg events with a KeySequence that I got from the command manager? - Is it planed for KeySupport to become public API? - Is that what I do recommended? Should I process events myself or would platform offer an infrastructure that does that (so that Emacs style key bindings would be supported) and I only work with KeySequence?
KeySupport is now API, but because we want our Keys API to work standalone if necessary with someone using just SWT. What your doing will work for now, but ideally you are waiting for support from keybindings in dialogs so you don't have to do anything special. Currently, we are controlling all key events in the top level shell and automatically executing the associated action. Soon, keybindings will work in other shells as well, and via your shell you will have the ability to register handlers for commands you want active in that shell, and we will process the key automatically for you and call your handler. CyclePartAction is working in a hacky way right now until this support is available. I am going to pass this to Doug to attach to his bugs in the area of 'keybindings in dialogs and other shells'
Are you using KeySupport right now, or may I rename it to SWTSupport?
You can rename it. I copied the funcionality so I'm not referening anything internal.
Should this now work with the new key binding support for dialogs (bug 31731). If so, can you outline how. If not, can this be provided early in M9 since we have dependent bugs which we would like to fix.
Okay, this is a brief summary of the steps to take. This stuff is still very new, so I'm not guaranteeing there won't be some quirks. If there are, please file separate bugs. Also, feel free to message me on IRC (irc.freenode.net#eclipse-dev) or on Sametime (IRC is preferred). 1.) The key binding 'Ctrl+Space' must be bound to a context that will be active when dialogs are open. Automatically, the "org.eclipse.ui.dialogAndWindow" context will be active, and I'd recommend this as a good starting point. However, it is possible to create your own context or place the key binding elsewhere. 2.) Register a handler that will be available when your dialogs are open. This can be done in XML (see the examples ("<handlerSubmission>") in the "plugin.xml" of "org.eclipse.ui"). It is also possible to do this by asking the workbench for its "commandSupport" and adding handler submissions directly. [Note: the ActionHandler class can be used to re-use an existing action, if you prefer not to subclass AbstractHandler or implement IHandler.] If you have specific types of conditions that you'd like to test with EnabledSubmission (contexts) or HandlerSubmission (handlers) -- but those conditions aren't currently available -- then we'd like to hear about them. For example, we've considered things like providing a Shell test or a "window type" (i.e., dialog, window, neither, both) test to HandlerSubmission. Again, IRC or Bugzilla are the best way to make these known. I've opened Bug 55977 to capture the work to move CyclePartAction to the new key bindings in dialogs API.
Dani, Martin: Before I close this bug as verified, I'd like some feedback as to whether my explanation seems okay to you or not. If you don't want to commit to answer yet (i.e., you want to play around with it a bit), don't worry about it. This bug can stay unverified into M9.
I took the key binding support out of the Quick controls and will cleanly add it at the beginning of M9 since I am still waiting for an answer in bug 54815. But maybe you can answer it here. What I would like to do is 1. get the key binding(s) for a specific command independent of whether it (or its scope) is currently active, i.e. I simply give the command name. 2. bind an action to that command 3. when the user presses the key sequence my action gets activated. No other side effects, no other active actions, simply the action(s) that I defined for my shell
Dani: I've appended comments to Bug 54815.
I believe the remaining discussion has moved to other bugs. Marking as verified in I200403251200.
