Community
Participate
Working Groups
Build Identifier: On Linux/GTK I've experienced some awkward (and arguably incorrect) behavior of keybindings. There is an open bugreport in STS that is caused by this bug. https://issuetracker.springsource.com/browse/STS-1400 The problem appears to be that if you have a keybinding assigning some command to a key combination like ALT-G ALT-F or ALT-G ALT-S This key binding is prone to conflicts with menu bar keys that match the *ending* of the keybinding. The result is that keybindings will fail to trigger if there is a menu in the menubar uses the same key as any key used in the keybinding. For example, in the case of the reported STS bug ALT-S will end up opening the "Source" menu (if it is currently present in the menubar). I've seen an identical problem with ALT-G ALT-F where the final ALT-F opened the "File" menu instead of triggering the command attached to the key sequence. This behavior seems specific to Linux. It does not happen on Windows (has not been tried on Mac yet, if I get a chance to try I'll post an update). I would expect that correct behavior for the menu bar to stop listening for keys once we are already in the middle of recognizing a longer key sequence (which is how it seems to work on other platforms). I can understand a conflict when the first keys match, but once a key binding sequence has been started, the ending of that sequence should not get 'stolen' by the menubar. Reproducible: Always Steps to Reproduce: It is easier to reproduce with a key binding like ALT-G ALT-F than ALT-G ALT-S because the "Source" menu comes and goes depending on having editors open. The file menu is always there, guaranteeing the problem will happen. 1. Create a keybinding for key sequence ALT-G ALT-F 2. Try to trigger the command/action associated with the binding Result: After pressing ALT-G a yellow popup appears showing the possible completions of the key stroke. If ALT-G ALT-F keybinding is registered correctly it will be shown in the popup. However, pressing ALT-F will not be able to trigger it, the File menu will be opened instead (and the yellow popup will stay).
The problem is caused by the OS eating defined menu accelerators so we never get an SWT.KeyDown event to filter. We have special code in MenuManager that removes menu accelerators from the main menu bar if there's a matching keybinding. Currently that code must not check for multi-stroke keybindings, hence this problem. PW
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. If you have further information on the current state of the bug, please add it. 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.
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.
