Community
Participate
Working Groups
Created attachment 280366 [details] See all tip Find Actions only displays a subset of all filtered actions and indicates "Results per category are limited. Press 'Ctrl+3' to see all" on Windows (see attached screenshot). However, pressing Ctrl+3 does not do anything as far as I can tell. I believe things worked on my macOS machine though.
Works for me on Windows, both in M1 as well as running from platform.ui HEAD. Nevertheless, there may be a delay in the computation of the extensions (I see about 1 second delay running from HEAD), so you should connect a profiler to your IDE (or dump a jstack) when trying to reproduce this. May you have some custom quick access extension running into the wild?
(In reply to Michael Keppler from comment #1) > Works for me on Windows, both in M1 as well as running from platform.ui > HEAD. Nevertheless, there may be a delay in the computation of the > extensions (I see about 1 second delay running from HEAD), so you should > connect a profiler to your IDE (or dump a jstack) when trying to reproduce > this. May you have some custom quick access extension running into the wild? No custom extension. I've just downloaded the latest standalone Platform SDK build (I20190916-1045) and launched it in a brand new workspace, and once Find Actions is opened, "see all"/"restrict" via a subsequent Ctrl+3 does not work. I believe this is the same cause than your comment here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=552289#c2 The Find Actions command by default is only available in "Windows". When you open it, the active part becomes a "Dialog". Subsequent Ctrl+3 are therefore ignored. I tried changing the command to "Dialogs and Windows" and it started working as expected.
(In reply to Pierre-Yves B. from comment #2) > I tried changing the command to "Dialogs and Windows" and it > started working as expected. Can reproduce.
I did some more testing, on macOS this time round, and I'm observing strange behaviour there as well. "'Cmd +3' to see all" does work with this operating system, but only with the '3' from the main keyboard bit. 'Cmd +3' with the '3' from the numeric pad has no effect. 'Cmd +3' with the '3' from the numeric pad does however allow to open Find Actions in the first place, it's just the "see all" that is affected. The revamped Find Actions does really look promising. But given this bug as well as more critical Bug 552289 which causes dozens of actions to become inaccessible, is it worth reverting and delaying changes to Quick Access to 4.15 if these can't be fixed in time? These kind of bugs will cause frustrations to users of 4.14.
(In reply to Pierre-Yves B. from comment #4) > "'Cmd +3' to see all" does work with this operating system, but only with > the '3' from the main keyboard bit. 'Cmd +3' with the '3' from the numeric > pad has no effect. 'Cmd +3' with the '3' from the numeric pad does however > allow to open Find Actions in the first place, it's just the "see all" that > is affected. Please either retitle this bug to make this issue more explicit, or open a new one.
(In reply to Mickael Istria from comment #5) > Please either retitle this bug to make this issue more explicit, or open a > new one. Roger that, retargeted this ones to be Windows only, opened Bug 553468 for macOS. They may have the same root cause, not sure yet at this point.
(In reply to Pierre-Yves B. from comment #4) > The revamped Find Actions does really look promising. But given this bug as > well as more critical Bug 552289 which causes dozens of actions to become > inaccessible, is it worth reverting and delaying changes to Quick Access to > 4.15 if these can't be fixed in time? Frankly, reverting all that is now close to impossible given the number of commits involved and the complexity of the refactorings. We just need to fix the bugs that are caused or made visible by those changes.
Maybe I don't get it right, therefore I have to ask again: The bug is that Ctrl+Numpad_3 does not invoke an action which has the shortcut Ctrl+3? If so, that is no bug at all. Numpad_3 and 3 are two different keys (You can check by pressing Ctrl+3 or Ctrl+Numpad_3 in they keys preferences "binding" field or by looking at the key code for keypad_3: https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2FSWT.html&anchor=KEYPAD_3). I would not expect any key combination involving one of the keys from 1 to 0 to work with their numpad equivalent instead. If this actually worked before, I would rather consider _that_ a bug.
(In reply to Michael Keppler from comment #8) > Maybe I don't get it right, therefore I have to ask again: The bug is that > Ctrl+Numpad_3 does not invoke an action which has the shortcut Ctrl+3? No, it doesn't work at all on my Windows machine, regardless of whether I use Ctrl+3 or Ctrl+Numpad_3. As said previously, the only way I got it to work was to switch the command scope to "In Dialogs and Windows" for the "When" parameter. Thomas is able to reproduce as well, however, I'm not sure what exact scenarios he's tried. ;) > If so, that is no bug at all. Numpad_3 and 3 are two different keys (You can > check by pressing Ctrl+3 or Ctrl+Numpad_3 in they keys preferences "binding" > field or by looking at the key code for keypad_3: > https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc. > isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2FSWT.html&anchor=KEYPAD_3). I > would not expect any key combination involving one of the keys from 1 to 0 > to work with their numpad equivalent instead. Is there not a bit of logic somewhere that says "if no command is found for Ctrl+Numpad_X, try Ctrl+X instead"? For years I've interchangeably used Ctrl+3/Ctrl+Numpad_3 for Quick Access across the IDE, Ctrl+1/Ctrl+Numpad_1 for Quick Fix in editors, Ctrl+4/Ctrl+Numpad_4 with PyDev, and probably other numeric shortcuts that have slipped off my mind. Still today with the new "Find Actions", I can initially open it with Ctrl+3 or Ctrl+Numpad_3 with either Windows or macOS. On macOS, however, following these changes, I can no longer trigger "See all" with Ctrl+Numpad_3, hence the separate Bug 553468.
(In reply to Pierre-Yves B. from comment #9) > (In reply to Michael Keppler from comment #8) > > Maybe I don't get it right, therefore I have to ask again: The bug is that > > Ctrl+Numpad_3 does not invoke an action which has the shortcut Ctrl+3? > > No, it doesn't work at all on my Windows machine, regardless of whether I > use Ctrl+3 or Ctrl+Numpad_3. As said previously, the only way I got it to > work was to switch the command scope to "In Dialogs and Windows" for the > "When" parameter. Thomas is able to reproduce as well, however, I'm not sure > what exact scenarios he's tried. ;) Exactly this. Ctrl-3 to open dialog, type something, hit Ctrl-3 again to get show all. Works only if key binding is activated "In Dialogs and Windows". Tested on Mac. Numpad not involved at all.
Just re-tested this, and I cannot reproduce anymore on Mac.
I did yet some more testing. When using a British keyboard layout on Windows, I cannot reproduce the problem described in my previous message. I can however reproduce something similar to Bug 553468, but let's leave that aside for now. When using a French keyboard layout, I can still reproduce the problem described in my previous message. A French layout differs because numbers aren't directly accessible. You have to press Shift+3 to produce a 3. In other words Ctrl+Shift+3 is needed to open "Find Actions". This combination opens the dialog as expected, but has no effect on "See all" unless the scope of the command is expanded to "In Dialogs and Windows". The command did work with the old Quick Access. To sum up, on a French keyboard (and probably other layouts that don't have directly accessible number keys), there is no way to action "See all" with the default command any more: Ctrl+Shift+3 no longer works and Ctrl+Numepad_3 no longer works either, whereas both did in 4.13.
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.
