Description: Some shortcuts doesn't work in libreoffice when changing keyboard layout to Arabic (or maybe other non-latin layout) under plasma 5 for examble Ctrl+B for bold doesn't work Ctrl+[ and Ctrl+] for changing font size doesn't work. Ctrl+C and Ctrl+V and Ctrl+A works just fine. I noticed that when I used manjaro before and now in kubunut 20.04 in lxde (lubuntu 18.04) everything works just fine I tested it in: Libreoffice 6.4.x previously in manjaro (I didn't remember the exact version) Libreoffice 6.4.2.2 in Kubuntu 20.04 beta LibreOffice-fresh.full-x86_64.AppImage in Kubuntu 20.04 beta LibreOfficeDev-7.0.0.0.alpha0_2020-02-26-x86_64.AppImage in Kubuntu 20.04 beta Steps to Reproduce: 1.change keyboard layout to Arabic or other non-latin language 2.Some shortcuts (like Ctrl+B, Ctrl+[ or Ctrl+] for example) don't work 3.change keyboard layout back to English and shortcuts works as it should Actual Results: Some shortcuts (like Ctrl+B, Ctrl+[ or Ctrl+] for example) don't work Expected Results: shortcuts should work in different keyboard layout under plasma 5 Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: tested in plasma 5.17.x and 5.18
Confirmed with Arabic layout under Plasma 5. The problem is not seen with gen or gtk3 backends. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: bcf8868e031f916473f13bcd1a0835c74cb05de5 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 20 August 2020
ِAFAIK this is a Qt bug, but with input method handling, I'm not 100% sure... Originally I thought it was some problem in the key handling - we had a bunch of bugs with "Old Hungarian" input, but it turns out Qt sends (wrongly?) an inputMethodEvent for the Ctrl+b, instead of a key event. Layout: ara Ctrl debug:23031:23031: QEvent::ShortcutOverride debug:23031:23031: st press co 0 len 0 Ctrl+b debug:23031:23031: inputMethodEvent 1 0 debug:23031:23031: st release co 513 len 1 debug:23031:23031: st release co 0 len 0 Layout: de Ctrl debug:23031:23031: QEvent::ShortcutOverride debug:23031:23031: st press co 0 len 0 Ctrl+b debug:23031:23031: QEvent::ShortcutOverride debug:23031:23031: st press co 513 len 1 debug:23031:23031: st release co 513 len 1 debug:23031:23031: st release co 0 len 0 As you can see, there is not even a a key press event for Ctrl+b, but instead you get a "commit string" of length 1 for "inputMethodEvent", which LO does comply with by inserting the "ل", the same character when just pressing "b". I get the same behavior in kate, where Ctrl+b normally adds a bookmark with "de" layout and English UI, but inserts a "ل" with "ara" layout instead. Also note, that gtk3 inserts a "ﻻ", if I press b. And I noticed a message in my ".xsession-errors", if I switch to the "ara" layout: qt.qpa.xkeyboard: no keyboard layouts with latin keys present I also tested the minimal Qt text editor /usr/lib/x86_64-linux-gnu/qt5/examples/widgets/richtext/textedit/textedit in WindowMaker, where I switched the layout between "de" and "ara" using "setxkbmap -layout". Same behavior the LO. This really looks like a Qt bug.
BTW - this was done on a Debian Buster with LO 7.1 build. Now I also tried a KDE neon testing live DVD (neon-testing-20200901-1829.iso). This inserts the correct glyph in kate, but the shortcut is still not working...