Community
Participate
Working Groups
The mnemonics text field doesn't seem to have any effects on the e4 application. Defining mnemonics (e.g. &File) works if set as part of the label string though. Thus, what is the purpose of the mnemonics text field?
Since we correctly set the field in the tooling part I'm moving this to platform/UI for a hint on the usecase.
Setting the mnemonic in a MMenuItem should auto-apply it when it appears in a menu item. But if it's not working, we need to take a look at it. It should work the same was as the mnemonic attribute in the org.eclipse.ui.menus extension point. See the code in org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.updateMenuItem() if (text != null) { if (model instanceof MMenuElement) { String mnemonics = ((MMenuElement) model).getMnemonics(); if (mnemonics != null) { int idx = text.indexOf(mnemonics); if (idx != -1) { text = text.substring(0, idx) + '&' + text.substring(idx); } } } if (keyBindingText == null) item.setText(text); else item.setText(text + '\t' + keyBindingText); } else { ... PW
*** Bug 541845 has been marked as a duplicate of this bug. ***
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.
The support for using mnemonics in the label attribute as well as having a separate mnemonic definition causes confusion. The same confusion is present with the org.eclipse.ui.menus extension point, see also Bug 570722. There was a clear design decision to separate the two, see the documentation of the extension point, however this separation was never enforced. Changing this behavior now would cause many regressions, especially for the extension case. Do we want to depreciate one of the mechanisms? Or at least make clear which of the two mechanisms is preferred?
*** Bug 419823 has been marked as a duplicate of this bug. ***
