Community
Participate
Working Groups
Version: 4.2.0 Build id: I20120125-2200 Steps: 1. create a simple Java class with a main method 2. with the editor in focus -> Alt+Shift+X, J 3. notice a launch does not occur After you press Alt+Shift+X the little pop-up will show displaying all of the 'run' shortcuts. At this point if you pick one (J, E, etc) nothing will happen, but the popup will close. As a workaround you can use the arrow keys to select the shortcut you want and hit enter.
This applies to more than just the launching shortcuts. Using the shortcuts to open a view (Alt-Shift-Q) the keybindings fail there as well (menu opens, clicking/enter works, letter bindings don't). What does Platform UI call these popup menus?
I would expect the comment 0 case to be due to the Debug bundles not having been activated. The comment 1 case however is suspect. I will have to try it tomorrow.
(In reply to comment #2) > I would expect the comment 0 case to be due to the Debug bundles not having > been activated. I originally thought the same thing, but even if I change the steps to include: 1a. open the launch dialog and create a new Java launch configuration (guarantees debug is activated) the same behavior is still present (key bindings don't work).
I start I20120126-1300 on a new workspace, close welcome, activate the 'Package Explorer'. I then hit Alt+Shift+Q, Q and the 'Show View' dialog opens up for me. This is on Windows 7.
4.2 I20120126-1300 I can reproduce the failure on startup, but if I bring up the Run>Run Configurations dialog then ALT+SHIFT+X, J works (well pops up an error 'cause no main method :-) It it just that using J with the key assist dialog up doesn't work but the keybinding itself does, and selecting the command manually from the key assist dialog does? PW
(In reply to comment #5) > 4.2 I20120126-1300 > It it just that using J with the key assist dialog up doesn't work but the > keybinding itself does, and selecting the command manually from the key assist > dialog does? Correct, although its not just J, none of the letters work - i.e. E does not start a target workspace. Ah ha! just testing, and the problem comes from the assist popup - if I use the key sequence really fast (such that the assist popup does not show) it works.
(In reply to comment #2) > I would expect the comment 0 case to be due to the Debug bundles not having > been activated. Just for the records this is bug 218881.
*** Bug 377661 has been marked as a duplicate of this bug. ***
*** Bug 375986 has been marked as a duplicate of this bug. ***
Scenarios to be fixed: - Alt+Shift+Q, wait, Q => doesn't do anything - Alt+Shift+Q, wait, Esc, Q => opens "Show View" dialog, but shouldn't catch the Q after Esc
*** Bug 384176 has been marked as a duplicate of this bug. ***
*** Bug 385078 has been marked as a duplicate of this bug. ***
The problem is an incorrect set of contexts being provided by the BindingServiceImpl. If the popup doesn't open (too fast), the contexts are all of the workbench actions sets, 'In Windows and Dialogs' and 'In Windows'. If the popup is opened (pause) the contexts are only 'In Windows and Dialogs' and 'In Dialogs'. All of the keybindings references here are part of the 'In Windows' context, including the debug one. So a possible solution would be to set the 'in windows' context for the keyboard bindings popup. The popup can be opened for conflicts on dialogs though, so a better solution would be to add the contexts from when the first part of the keystroke is registered. Unless having the various action set contexts available when the popup is open is incorrect.
I'm not sure how to hack the EBindingService to restore the command contexts. BindingServiceImpl has the injected setContextIds which updates the set of command contexts whenever a shell is given activated. The KeyBindingDispatcher correctly keeps track of the context and binding service, but the injected method overrides any changes the dispatcher might make. Paul, do have any ideas/suggestions?
*** Bug 386644 has been marked as a duplicate of this bug. ***
In 3.x I believe this was handled by registering certain shells as "window" shells via org.eclipse.ui.contexts.IContextService.registerShell(Shell, int) Then the dialog shell wouldn't filter out all of the window contexts that should be active. Things you can check: Is that popup registered as a TYPE_WINDOW shell? If so, are we respecting that? PW
*** Bug 387571 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > In 3.x I believe this was handled by registering certain shells as "window" > shells via org.eclipse.ui.contexts.IContextService.registerShell(Shell, int) > > Then the dialog shell wouldn't filter out all of the window contexts that > should be active. > > Things you can check: Is that popup registered as a TYPE_WINDOW shell? If > so, are we respecting that? > > PW We cannot register the shell when creating the popup because org.eclipse.e4.ui.bindings sits lower on the stack. Adding a dependency on o.e.ui.workbench will cause a cyclical dependency.
"Alt+Shift+X, T" still doesn't work. Any clue on when and how this will be fixed?
(In reply to comment #19) > "Alt+Shift+X, T" still doesn't work. Any clue on when and how this will be > fixed? This won't be looked at until more imporant 4.2.2 items are complete. http://wiki.eclipse.org/Platform_UI/Plan/4.2.2
*** Bug 410502 has been marked as a duplicate of this bug. ***
*** Bug 411011 has been marked as a duplicate of this bug. ***
*** Bug 411695 has been marked as a duplicate of this bug. ***
Just in case anyone is wondering, I got this working on ubuntu 12.10 by reverting to indigo.
*** Bug 412916 has been marked as a duplicate of this bug. ***
*** Bug 413758 has been marked as a duplicate of this bug. ***
I usually use many multi-key bound sequences. I first noticed behavior like this in Kepler. Indigo worked fine. I've also noticed that if my delay after starting the sequence is smaller than some threshold, or Eclipse is slow to bring up the assist dialog, the end of the sequence can easily be associated with the view that's currently in focus. For instance, I have the sequence "ctrl-x 2" bound. When Eclipse is slow, and I don't press the two keys very quickly together, I often see "2" being inserted into my editor, because the assist dialog didn't have a chance to come up.
This is a regression compared to 3.x which particularly hurts users of the Emacs+ plugin, which provides Emacs keybindings and functionality (including a kill ring and macro recording): http://www.mulgasoft.com/ Other open Eclipse defects that hurt Emacs+: http://bit.ly/Wjg6pQ Eclipse Kepler related discussions on the Emacs+ Google Group: https://groups.google.com/forum/?hl=en?hl%3Den#!searchin/emacsplus/kepler
See also http://www.mulgasoft.com/emacsplus/juno
Created attachment 234037 [details] Simple Patch While this patch works, it does not address the issue that 3.x code has used IContextService.registerShell() to control what the shell sees. I'm going to back-port this fix to 4.3.1, but keep this bug open in hopes that we can provide a more complete solution for 4.4/Luna.
Created attachment 234038 [details] mylyn/context/zip
(In reply to comment #30) > Created attachment 234037 [details] [diff] > Simple Patch > > While this patch works, it does not address the issue that 3.x code has used > IContextService.registerShell() to control what the shell sees. > > I'm going to back-port this fix to 4.3.1, but keep this bug open in hopes > that we can provide a more complete solution for 4.4/Luna. PaulW cherry-picked that fix into 'master' (4.4 M1) as well: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ff93b81900d34181e13d23408cb365c0e14418d6 Verified in I20130807-2000 that the reported problem is gone, hence reducing severity to 'normal'.
*** Bug 417136 has been marked as a duplicate of this bug. ***
See bug 420722 for probably cause.
(In reply to Paul Elder from comment #30) > I'm going to back-port this fix to 4.3.1, but keep this bug open in hopes > that we can provide a more complete solution for 4.4/Luna. Can you provide a test case of what still does not work in 4.4 M2?
Created attachment 237186 [details] Fix for Esc key (In reply to Dani Megert from comment #35) > Can you provide a test case of what still does not work in 4.4 M2? (In reply to Markus Keller from comment #10) > Scenarios to be fixed: > - Alt+Shift+Q, wait, Q => doesn't do anything > - Alt+Shift+Q, wait, Esc, Q => opens "Show View" dialog, but shouldn't catch > the Q after Esc First scenario is fixed now (4.4 M3). Second scenario still fails. In 3.8, the end of KeyAssistDialog#close(boolean, boolean) performed if (resetState) { keyBindingState.reset(); } The attached patch does the equivalent in E4.
(In reply to Markus Keller from comment #36) > Created attachment 237186 [details] [diff] > Fix for Esc key Thanks Markus. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e0cbcda17c78bb2707c117ff7f5e39b32f2052dc
(In reply to Dani Megert from comment #37) > (In reply to Markus Keller from comment #36) > > Created attachment 237186 [details] [diff] [diff] > > Fix for Esc key > > Thanks Markus. > > Fixed with > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=e0cbcda17c78bb2707c117ff7f5e39b32f2052dc Filed bug 421082 for backport to 4.3.2.
I have tried the patches but it is still scenario one is not working. Alt+Shift+Q, wait, Q => doesn't do anything Let me explain a little background of what I am doing. I have implemented multiple editors(like HTML editor, XML editor). These editors have different key bindings which is why I am maintaining different contexts for these editors(parent context id: org.eclipse.ui.textEditorScope) And on focusGain/focusLost I am enabling/disabling these contexts. Now the shortcuts in context, which is not disabled on focusLost, are working as per scenario one. But shortcuts in contexts which are disabled on focusLost, are not working as per scenario one. Though they work when I hit enter on particular key binding in shortcut popup. I understand that because focus is lost, context is disabled so shortcuts are not working. But how are they working when I hit enter in that case. Something is definitely not working correctly. And just to remind I have done this complete testing after applying the patch.
Anybody?
I think all "Keybinding assist popup" issues have been fixed in the master branch with comment 37. IMO, this bug should have been marked as FIXED for M4. (In reply to Milan Chandna from comment #39) > I have tried the patches but it is still scenario one is not working. > Alt+Shift+Q, wait, Q => doesn't do anything This works for me in master. Note that not all changes that lead to this fix have necessarily been attached as patches here, so there may be additional fixes in master that made this work. Please use the master branch, and if it still doesn't work there, open a new bug for your scenario.
(In reply to Markus Keller from comment #41) > I think all "Keybinding assist popup" issues have been fixed in the master > branch with comment 37. IMO, this bug should have been marked as FIXED for > M4. > Agreed. I've opened Bug 432335 for me to continue looking at registerShell(*) problems. PW
New Gerrit change created: https://git.eclipse.org/r/42552
Gerrit change https://git.eclipse.org/r/42552 was merged to [R4_2_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=36f761aafffe2838b890437058c1dc280efa22f3
Backported to R4_2_maintenance with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=070d2cea00176a042bf2cfb04f67eb3b7fa16ef3 and http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=36f761aafffe2838b890437058c1dc280efa22f3.
Note: "Growl for Windows" application silently intercepts Alt+X key combination, causing problems with key bindings containing Alt+Shift+X (by default all "Run ..." commands).
