Community
Participate
Working Groups
When Alt+<Key> is used as keybinding for a command, conflicts can occur with top-level menu items. The current solution for this conflict is to remove the mnemonic for the top-level menu. This removal is context sensitive, so depending on the selected part, some mnemonics get added/removed. On windows there are 2 ways to activate mnemonics: - By single key press Alt+<Key> - By F10 or ALT key press, followed by <Key> press Both cases are disabled for the conflicting mnemonics, see also Bug 208626 Comment 15. Currently, the mnemonics are removed in the MenuManager. When this behavior is disabled, two things happen: 1) The mnemonic is shown on the menu, however commands take priority. So although the mnemonic is shown, it will not be triggered. 2) When the command is not executable, the menu is opened. This is different behavior then the current solution. Mnemonics become not only context dependent but also dependent on command enabled state. This is solvable in the KeyBindingDispatcher, by always eating 'Alt+<key>' also when an command is disabled. (I have a prototype available) Then the question is, which behavior is more desirable/intuitive to the user: a) The current behavior, mnemonics are removed. They can also not be selected with two key presses. b) The changed behavior, mnemonics are show but commands take priority. The mnemonics are shown, but cannot be selected with single press. They will can be selected with the two key presses. c) As proposed in Bug 208626 Comment 15, handle this as a real conflict between keystrokes. Though implementing that can become quite complex. To test this behavior, switch to the Emacs keybinding schema. Good examples are Alt-F, which is only active in text editors to go to the following word, and, Alt-W which is bound to the cut command which is always active but only executable when a selection is active.
Lets add some more complexity: On windows: 1) There is an option to always show mnemonics, so showing a disabled mnemonic could add confusion [1] 2) When no mnemonic is specified, the first character is used as mnemonic. This mnemonic is not highlighted (in Eclipse). This seems to be default behavior in Windows, though I have not found any reference for this yet. To test the 2nd point, with the Emacs bindings, close all editors and select the outline. Push Alt+W, and the windows menu shows up. In general, can be tested by pressing Alt then typing the first character of a menu without mnemonic. It seems that when a mnemonic is defined for a character it takes precedence over the first character. And now the fun starts: Define a binding for Alt+a, this will remove the mnemonic from the Search menu. - With all editors closed; Alt+S opens the search menu. - Open a Java editor, the Source menu with S-mnemonic is added; Alt+S doesn't open any menu (Same with the text editor, but that doesn't add a (visible) source menu) - Close the editor; Alt+S doesn't open any menu - Select the outline editor; Alt+S opens the Search menu This behavior is probably some kind of bug So in general, disabling the (default) mnemonics on windows will enable the first character as mnemonic (though this one will not be underlined) [1] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/dnacc/guidelines-for-keyboard-user-interface-design#underlining-access-keys
I think it is gernally wrong (at least discouraged) to put a keybinding to Alt+<Key> in a windows env, not?
(In reply to Thomas Schindl from comment #2) > I think it is gernally wrong (at least discouraged) to put a keybinding to > Alt+<Key> in a windows env, not? It is indeed discouraged to have a keybinding on Alt+<Key> in Windows, due to interactions with the mnemonics. However the Emacs KeyBindings by default use them, otherwise they wouldn't be mimicking Emacs.
The behavior that the first character becomes the mnemonic (Comment 1) is supposed to be suppressed by Eclipse. However this behavior is flaky, see Bug 346475 and Bug 570998.
