Description: ALT+t opens the Tool Menu in all LibreOffice applications, and ALT+a opens the Table Menu in Writer. In recent updates, however, you get the same result if you use ALT+CTRL+a in Writer (Calc, Impress, Draw, Base and Math are not affected). This is a problem, because ALT+CTRL+a, SHIFT+ALT+CTRL+a, ALT+CTRL+o, etc. used to be available to facilitate customized input using the Keyboard Layout Manager program. ALT+u is not used as a menu shortcut, still ALT+CTRL+u input is disabled. Right Alt (AltGr) works as before. Steps to Reproduce: 1. Open a Writer file. 2. ALT+a (Writer correctly opens the Table menu) click on the file to close the menu 3. ALT+CTRL+a (Writer behaves as if the input were ALT+a) 4. SHIFT+ALT+CTRL+a (Writer behaves as if the input were ALT+a) Actual Results: Menu shortcuts use up three different input combinations. Expected Results: Menu shortcuts should be limited to the ALT+ format. Reproducible: Always User Profile Reset: No Additional Info: Microsoft Word (but not PowerPoint or Excel) always had this problem and LibreOffice Writer used to have a great advantage. User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
This is not correctly described as you have mixed assignment and use of mnemonic accelerators with short-cuts. Rework on the ALT toggle was done to support GKT3, and the accelerator handling changed. The accelerators are no longer key combinations--but instead are sequences of key entries to navigate menus. The actual shortcuts are still available for assignment. With a clean profile none of the CTRL, SHIFT and ALT key combinations you list are assigned, and all are available to use for customization via Tools -> Customize -> Keyboard assignments.
Thanks V Stuart. So this bug was introduced when rework on the ALT toggle was done to support GKT3. Keyboard Layout Manager is a front end processor that facilitates customized character input in a uniform way in all the applications on your computer. This is very useful when you work with various languages and mathematical symbols. "The actual shortcuts are still available for assignment in Tools -> Customize -> Keyboard assignments." is exactly the point. The combinations are not assigned and they should not be in LibreOffice, still Writer interferes with the front end processor. Currently I kept V.4.4.7.2 on one of my machines, because you can type much faster with a properly functioning ALT key. "The accelerators are no longer key combinations--but instead are sequences of key entries to navigate menus." Indeed you can push "ALT SHIFT CTRL a" even in this order and it still emulates "ALT+a".
Running some test on V.4.4.7.2 , indicated that accelerators were already sequences of key entries on earlier versions. Pushing "ALT SHIFT CTRL a" used to open the Table menu, but they were able to disregard and not interfere with combinations such as ALT+CTRL+a.
Leaning toward a NotOurBug for the described use case with external program. @UX-advise? =-ref-= @Frank, is this the 3rd party program having issues? http://www.klm32.com/
Hi Stuart, sorry I was incorrectly refering to klm32, actually it is The Microsoft Keyboard Layout Creator (MSKLC) https://msdn.microsoft.com/en-us/globalization/keyboardlayouts.aspx I have had it for years, thus I can type into browsers, mail, word processors exactly the same way. Set it up once and forget it. Past few hours, I recorded some macros for both Writer and MS Word. In both cases they are able to override the problem. MS Word only caused problems when the command was already defined, but it allows you to redefine them. Writer was annoying, because it never had this issue and I don"t see any reason why it should now. Anyway I can force it with macros, so I am happy as a user, just thought this feedback may help others.
(In reply to V Stuart Foote from comment #4) > Leaning toward a NotOurBug for the described use case with external program. My first idea was that hotkeys are case insensitive, and shift is needed for the non-alphanumeric mnemonics. From wikipedia 'keyboard shortcut' "At times, usually on Unix platforms, the case of the second character is significant – if the character would normally require pressing the Shift key to type, then the Shift key is part of the shortcut e.g. '^C' vs. '^c' or '^%' vs. '^5'. ^% may also be written "Ctrl+⇧ Shift+5"." Kate, very common Qt ASCII editor, forwards shift+alt+<key> into the document instead to open the menu. Firefox does nothing on shift+alt+F, the same for Inkscape, Gimp, Calligra... WPS Writer allows alt+H as well as shift+a+H to enable the respective section. The same for Thunderbird (surprisingly inconsistent for Mozilla). So my take is to add this to the HIG (and apply of course): * Unless not explicitly defined a shortcut is limited to only one key combination. If alt+<key> is defined shift+alt+<key> will not work as an alternative by default.
(In reply to Frank from comment #2) > Thanks V Stuart. So this bug was introduced when rework on the ALT toggle > was done to support GKT3. This bug was most likely introduced as a fix to bug 95761. That change has been reverted, and it should work in 6.0.0 like before (a lot of similar issues that are collected in the Shortcuts-AltGR meta bug are now fixed). Please test with this new version.
Meanwhile we provide easy customization, maybe not for the shortcuts but that is a most-wanted improvement in bug 115052. Issue is very much l10n-specific and also depends on the OS and DE. Since we run out of shortcuts anyway, limitation to alt+ (and no further modifier) won't fix.