Download it now!
Bug 132089 - Some shortcuts doesn't work when changing keyboard layout to Arabic (or maybe other non-latin layouts) under plasma 5
Summary: Some shortcuts doesn't work when changing keyboard layout to Arabic (or maybe...
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.4.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2020-04-13 22:25 UTC by wissam
Modified: 2020-09-11 00:44 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wissam 2020-04-13 22:25:15 UTC
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
Comment 1 Buovjaga 2020-08-23 15:38:43 UTC
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
Comment 2 Jan-Marek Glogowski 2020-09-10 23:09:59 UTC
ِ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.
Comment 3 Jan-Marek Glogowski 2020-09-11 00:44:41 UTC
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...