Bug 309193 - Keyboard shortcuts doesn't work if non-english keyboard layout is set before english one
Summary: Keyboard shortcuts doesn't work if non-english keyboard layout is set before ...
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_keyboard (show other bugs)
Version: 5.24.4
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
: 272259 320008 322027 322454 451821 (view as bug list)
Depends on:
Reported: 2012-10-29 12:05 UTC by Dmitry
Modified: 2022-08-11 19:51 UTC (History)
50 users (show)

See Also:
Latest Commit:
Version Fixed In: Qt 5.something

Attempt to fix in Qt (1.92 KB, patch)
2016-05-19 07:20 UTC, Ruslan Kabatsayev

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry 2012-10-29 12:05:48 UTC
If in systemsettings english keyboard layout isn't set first (for example, I can move russian keyboard layout before english) then hotkeys doesn't work (: Ctrl+Shift+T doesn't open new tab, it isn't possible to copy/paste with Ctrl+Shift+C/V. 

Reproducible: Always

Steps to Reproduce:
1. Open keyboard settings and put non-english layout before english
2. Open konsole, try Ctrl+Shift+T
Actual Results:  

Expected Results:  
Hotkeys should have effect
Comment 1 Jekyll Wu 2012-10-29 23:04:38 UTC
Just to be clear, when you say "try Ctrl+Shift+T", is it per the physical keyboard layout, or the logical keyboard layout ?

Although I have limited knowledge about those layout issues(because I never need/use it), I guess the problem is not specific to konsole.  It should be a KDE/Qt wide problem. Please also try other KDE applications where you have defined "Ctrl+Shift+...." shortcuts.
Comment 2 Dmitry 2012-10-30 06:22:34 UTC
Thank you!

Ctrl+Shift+T => T is latin symbol

More shortcuts don't work: Ctrl+Shift+C and etc. I've found that some shortcuts of another applications don't work. For example, krunner search panel doesn't appear if I set its shortcut to Win+R. So, this bug should be moved to upstream.
Comment 3 Dmitry 2012-10-30 06:25:17 UTC
But I don't know what product should I set to this bug.
Comment 4 ro.ggi 2012-11-18 18:09:47 UTC
I can confirm that with Russian keyboard, you can not copy/paste in dolphin and kate, the combination of "Alt+." didn't show hidden files, etc. I also noticed that this problem only applies to some KDE Apps. LibreOffice, Rekonq, Kontakt works well with shortcuts. You can also move Russian to the second language in settings and select it later over control bar, than all shortcuts works too.

There is older duplicate of this bug: https://bugs.kde.org/show_bug.cgi?id=272259
Comment 5 Jekyll Wu 2012-12-14 05:38:31 UTC
*** Bug 272259 has been marked as a duplicate of this bug. ***
Comment 6 emg81 2013-02-04 07:01:58 UTC
I can confirm this bug.

It happens when you set russian (doesn't matter which one) as a default layout.
I got this bug since 2009 (KDE 4.2) until KDE 4.8.5 (didn't try with KDE 4.9)
Distributions: archlinux i686, gentoo i686, kubuntu i686 / amd64. So I guess it is not a packaging problem.

Back in 2009 I switched layouts and set english as first layout and forgot about it. Thought this bug was fixed but found it in Kubuntu 12.04 few days ago.
Comment 7 emg81 2013-02-06 21:31:55 UTC
(In reply to comment #6)

Just tried with Gentoo i686 & KDE 4.9.5.
Bug still exists. 
Once you set english layout as second - hotkeys do not work at all.
When you get it back at 1st place - everything is fine.

It doesn't depend on gcc / glibc / xorg / etc version, distro and all that stuff as far as I can tell.
Comment 8 Mykola Krachkovsky 2013-07-06 09:23:21 UTC
openSUSE x86_64, KDE SC 4.10.5 — looks like hotkeys use keysym, not a keycode, so when I use ukrainian or russian shortcuts don't work (or may work unexpectedly).

PS. When I've used 4.10.4 all was fine.
Comment 9 Ivan Kolmycheck 2013-07-08 10:00:21 UTC
I'm having this bug too, in 4.10.5. In 4.10.4 everything worked just fine. With latin layout everything is working fine, but not with russian or ukrainian.

Offtopic: it reminds me good'n'old bug in Firefox with same effect.
Comment 10 Yevhen K. 2013-07-13 05:52:20 UTC
I can confirm this bug. Shortcuts (Ctrl+C Ctrl+V Ctrl+Z Ctrl+P Ctrl+Q Ctrl+W Ctrl+T) do not work in such applications as dolphin, krusader, konsole etc. in case when russian/ukrainian keyboard layout is activated.
But shortcuts work fine in such applications as firefox and thunderbird (and maybe in other applications which built on GTK) regardless of the chosen keyboard layout.

$uname -a
Linux Arch64 3.9.9-1-ARCH #1 SMP PREEMPT Wed Jul 3 22:45:16 CEST 2013 x86_64 GNU/Linux

$kde4-config --version
Qt: 4.8.5
KDE: 4.10.5
kde4-config: 1.0
Comment 11 Mykola Krachkovsky 2013-07-15 04:48:04 UTC
By the way, this may be a Qt 4.8.5 problem, not KDE SC. I've created test Qt application, added action with Ctrl+A shortcut. This shortcut works with english layout, but does not with ukrainian/russian ones.
Comment 12 Nick Stefanov 2013-07-15 23:51:39 UTC
Hello, I can confirm that Qt 4.8.5 is the culprit. I've been lucky enough having image (backup) before it's upgrade went out, which helps me to investigate the problem. I've installed a group of available updates and seek for the problem. When it finally appeared I've remember from which group it came and I've just begun to close circle by installing less and less packages from this group and finaly found it. It's definitely Qt 4.8.5. For now I hold it via editing pacman.conf at v. 4.8.4 and haven't problems at all. In case of upgrade to version 4.8.5, the problem appears after reboot. Hope the fix it soon.

$ uname -a
Linux mozo 3.9.9-1-ARCH #1 SMP PREEMPT Wed Jul 3 22:45:16 CEST 2013 x86_64 GNU/Linux

$ kde4-config --version
Qt: 4.8.4
KDE Development Platform: 4.10.5
kde4-config: 1.0
Comment 13 Nick Stefanov 2013-07-15 23:53:51 UTC
Hope they fix it soon.*
Comment 14 Ivan Kolmycheck 2013-07-16 07:02:27 UTC
I hope too. Sent link to other affected users I know with proposal to register, comment and vote.
Comment 15 Mykola Krachkovsky 2013-07-16 08:22:24 UTC
I've found only Qt 5.1 bug https://bugreports.qt-project.org/browse/QTBUG-32274 but 4.8.5 mentiod there.
Comment 16 Йордан Атанасов 2013-07-16 12:59:51 UTC
*** This bug has been confirmed by popular vote. ***
Comment 17 Wolfgang Brehm 2013-07-16 20:07:16 UTC
for me it seems this bug, which also seems to be the same as
274820 and
Is fixed with
Qt: 4.8.5
KDE: 4.10.5 "release 4"
Comment 18 Wolfgang Brehm 2013-07-16 20:25:18 UTC
KDE apps behave now as expected but, only if the first keyboard is standard.
So I am sorry I mislead you. This bug exactly is not fixed but the situation has improved.
Comment 19 Jekyll Wu 2013-07-17 02:43:17 UTC
*** Bug 322454 has been marked as a duplicate of this bug. ***
Comment 20 Jekyll Wu 2013-07-21 03:32:01 UTC
*** Bug 320008 has been marked as a duplicate of this bug. ***
Comment 21 Vova 2013-07-22 14:14:32 UTC
On archlinux and kubuntu similar problem have.
Comment 22 paul_arts 2013-07-23 18:59:50 UTC
Fedora 19 with KDE 4.10.5 and Qt 4.8.4, similar problem.
Comment 23 Nick Stefanov 2013-07-23 20:30:19 UTC
@paul_arts, what happens if you upgrade to Qt 4.8.5?
Comment 24 Dimitrios Glentadakis 2013-07-27 14:03:57 UTC
I have the same problem since i installed kde 4.10.4
For example, before, i could open the search dialogue in konqueror with ctrl+f even when i had the Greek keyboard layout enabled
Comment 25 Nikita Skovoroda 2013-08-09 14:13:20 UTC
Now the keyboard shortcuts do not work at all, if the current keyboard layout is non-latin.

It does not depend on the keyboard layout order.

Using KDE SC 4.10.97.
Comment 26 Mykola Krachkovsky 2013-08-09 14:37:21 UTC
Nikita, this is Qt 4.8.5 bug, not KDE. I'm using Qt 4.8.4 and KDE SC 4.10.97 — hot keys work.
Comment 27 Mykola Krachkovsky 2013-08-09 14:40:46 UTC
(In reply to comment #26)
> — hot keys work.
If first layout is latin.
Comment 28 Nick Stefanov 2013-08-10 10:17:13 UTC
Here I post report:


Please comment.
Comment 29 Jekyll Wu 2013-08-28 13:57:29 UTC
*** Bug 322027 has been marked as a duplicate of this bug. ***
Comment 31 Dimitrios Glentadakis 2013-09-25 04:45:51 UTC
It has to be Linus Torvalds who did it. He is the only guy who returns on his decisions. Or, he did his effective gesture again...
Comment 32 AnAkkk 2014-01-31 21:03:32 UTC
I'm having the same issue, and it's quite annoying. I need the layout to be ordered in a specific way to work around a bug in Wine with some games, but the shortcuts are always the ones of the first layout, even when I switch.

There seem to be many duplicates of this bug:
Comment 33 finomeno@gmail.com 2014-03-05 22:40:07 UTC
Hello everyone!

After months of switching layouts and banging my head against this bug, I thought I should check LibreOffice settings (I'm using now). What figures? I did find something. And in just a few clicks.

This is not a bug! It's simply a matter of configuration.

For the regular keyboard shortcuts (like Ctrl+C, Ctrl+V, etc.) to remain operational in LibreOffice applications while using a non-latin keyboard layout (like Greek or Russian), go to Tools -> Options -> Language Settings -> Languages, check the Ignore system input language option, save, and Bob's your uncle.

Hope this helps.


Technically, though, shortcuts still remain language-dependent. This means if you enable this option, you will have to set your document languages manually.
Comment 34 Dimitrios Glentadakis 2014-03-06 05:17:22 UTC
For me in LibreOffice the shortcuts ctrl+c ctr+v ctr+z ctr+x work without the above setting
But in KDE they work too.
But the shortcuts like ctrl+O ctrl+T don't work
I use a Greek layout and the keys 'T' and 'O' remain at the same position on the keyboard
EG: in kmail the ctrl+. (collapse messages view) works in Greek too and the '.' is at a different position than the physical position of the '.' key on the keyboard (i use a French keyboard with French/Greek layouts)
Same for the Ctrl+, it works for the both layouts

So the problem is only with letters and not with symbols and not with the standard combinations copy paste cut cancel
Comment 35 AnAkkk 2014-03-06 11:07:49 UTC
I'm not sure if we're all having the same problem or a different issue. Anyway I think mine is the same as the original post: only the keyboard layout you set first is used in KDE applications such as Dolphin.
I have the English one first and French 2nd. My keyboard layout is set to the 2nd. CTRL+A should select all files in Dolphin, but instead is closes Dolphin (because A on a Azerty keyboard is at the same place as Q, so it does CTRL+Q = Quit).
Comment 36 sunwebrw 2014-08-14 07:27:23 UTC
Yes, this exactly what happens to me and seeing this is a bug from 2012 doesn't make we cheerfull in the slightest. They didn't fix it back then they won't fix it now =(

If i choose first layout as English everything works even if i change language but if choose non English layout first KDE programs won't recognize most useful shortcuts even when i change language to English.

Kubuntu 14.04, latest updates till date. KDE is really nice envornment but such extremely stupid bugs are really downing in 2014.
Comment 37 Nick Stefanov 2014-08-14 11:00:24 UTC
This bug has been solved a long time ago. Just don't use shity *buntu, with 100 years old packages. In Arch we already forget about this bug. It has been sooo time long ago.
Comment 38 AnAkkk 2014-08-14 11:03:26 UTC
Wrong, it's not fixed, I have the same bug in Arch.
Comment 39 Nick Stefanov 2014-08-14 11:07:38 UTC
I don't have it anymore since I have reported it.

$ uname -a
Linux mozo 3.16.0-2-ARCH #1 SMP PREEMPT Mon Aug 4 19:04:45 CEST 2014 x86_64 GNU/Linux

$ kde4-config --version
Qt: 4.8.6
KDE Development Platform: 4.13.3
kde4-config: 1.0

I use bulgarian layout and all is working fine.
Comment 40 AnAkkk 2014-08-14 11:10:01 UTC
We're probably talking of different issues then. The original issue only happens when you use multiple keyboard layouts, not just one.
Comment 41 Nick Stefanov 2014-08-14 12:46:33 UTC
No, it is not a different issue. I use En(US) and Bulgarian layouts. When I use Bg layout, all hotkeys works without any problem.
Comment 42 Alexander 2014-12-23 13:38:46 UTC
Any news about this issue?

Laout config:
us - English (US) - us
ru - Russian - ru

$ uname -a
Linux xxx 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ kde4-config --version
Qt: 4.8.6
KDE Development Platform: 4.13.3
kde4-config: 1.0

I need to logoff for make hotkays working in application's (e.g. Ctrl+Shift+T in Konsole, Ctrl+X in Dolphin etc.).
But after some time hotkeys stop working again. So I need to logoff/loggin each time ((

Is there any other workarounds?

P.S. I do not specialist in Linux, but how I how hotkeys must be processed in application directly without any other hidden ways/services. Like processing keys/virtual keys in WindowProc through message queue in windows application. But in kde some strange delirium with this (((
Comment 43 Alexander 2014-12-23 14:50:26 UTC
Also "Alt-Shift" for switch language keyboard stops working permanently.

But workaround works:
Open language settings/Layouts, move some layout to up, push apply, back layout to down, push apply & close.

But will be nice without this workarround.
Comment 44 Christoph Feck 2015-02-02 23:21:20 UTC
I have selected this bug as the "Bug of the Month". See https://community.kde.org/Gardening

If you are able to fix it, you will receive a honorable mention in the next issue of my blog post "The Bug of the Month" on Planet KDE.

Not all developers that would be able to fix it are subscribed to this bug. If you know someone, feel free to point them here.
Comment 45 Nick Shaforostoff 2015-02-04 00:21:16 UTC
can somebody explain me why anybody would need to have non-English layout first in the list?
Comment 46 Nikita Skovoroda 2015-02-04 01:37:28 UTC
Can anyone reproduce this in kf5/qt5-based apps?
Comment 47 Nikita Skovoroda 2015-02-04 01:53:38 UTC
My observations:
1) Reproducible in kde4 and pure qt4-based apps. Qt4 version: 4.8.6
2) Not reproducible in kf5 and pure qt5-based apps. Qt5 version: 5.4.0

For me, it looks like a Qt4 bug which is already fixed in Qt5.
Comment 48 Nikita Skovoroda 2015-02-04 02:06:17 UTC
Upstream bugreport: https://bugreports.qt.io/browse/QTBUG-15319
Comment 49 Dimitrios Glentadakis 2015-02-04 05:19:07 UTC
(In reply to Dimitrios Glentadakis from comment #24)
> I have the same problem since i installed kde 4.10.4
> For example, before, i could open the search dialogue in konqueror with
> ctrl+f even when i had the Greek keyboard layout enabled

It works now with KDE 4.14.3
Comment 50 Nikita Skovoroda 2015-02-05 00:06:33 UTC
https://codereview.qt-project.org/#/c/96993/ — this looks to be the proper fix (and explanation) in Qt5. +147, -48, and those changes were done in the xcb QPA backend. The main file is https://qt.gitorious.org/qt/qtbase/source/5.4:src/plugins/platforms/xcb/qxcbkeyboard.cpp

Qt4 has different architecture, the files in question are something around https://qt.gitorious.org/qt/qt/source/4.8:src/gui/kernel/qkeymapper_x11.cpp
Comment 51 Nick Shaforostoff 2015-02-05 13:16:17 UTC
ok to close as FIXED UPSTREAM?
Comment 52 Albert Astals Cid 2015-02-05 19:08:21 UTC
Please leave it open until we have confirmed it's fixed for all our users in all the software versions we maintain.
Comment 53 Louis Moureaux 2015-03-02 14:18:29 UTC
I can reproduce this bug (both Qt 4.8.6 and 5.4.1) using Belgian and French (Bépo) layouts, in this order. Some shortcuts work as expected (in rekonq: Ctrl+T), some others don't (Ctrl+W). I think it works when the first layout has a letter, and doesn't  when it's a symbol (dot, comma, …).
Comment 54 Óscar Nájera 2015-07-26 14:36:28 UTC
I have this same problem. I use kde 5 with plasma 5 in arch linux.
The shortcut match the physical layout of the keyboard and not the Dvorak layout I have on top.
Comment 55 jules 2015-09-14 12:30:38 UTC
I have the same problem, with French (AZERTY) keyboard as first keyboard, and using english keyboard. (so Ctrl+A quit and Ctrl+Q select All, confusing...)
using: Ubuntu 14.04, kde 4.13.3, Qt 4.8.6
Comment 56 Holy 2015-12-25 23:37:18 UTC
This used to work with KDE 4 but is broken with Arch and Plasma 5.5.2.
Comment 57 Holy 2015-12-26 00:22:26 UTC
This fixed the problem for me (from https://forum.kde.org/viewtopic.php?f=289&t=130179&p=348185#p348027 ):

pkill kglobalaccel5
kglobalaccel5 &
Comment 58 Frederik Schwarzer 2016-04-11 19:41:50 UTC
I have this problem for a long time now.
Shortcuts like Ctrl+S for Saving do work in Kate but not in KDevelop for instance.
My intuition told me that the KF5 versions work but the KDE4 versions don't, but I did not check this properly.

Qt 4.8.7 and 5.5.1 installed.
My keyboard layout is US with some custom mappings with xmodmap.
Comment 59 Frederik Schwarzer 2016-04-11 19:47:00 UTC
... Forgot to mention that those shortcuts in KDevelop actually do work once every few weeks but the next reboot they are gone again.
Comment 60 Ruslan Kabatsayev 2016-05-19 07:20:36 UTC
Created attachment 99068 [details]
Attempt to fix in Qt

I'm not sure whether this patch for Qt4 even goes in the right direction, but it does appear to fix this problem for me with US+Russian layouts, regardless of which layout is primary. I guess it might break with e.g. US+AZERTY or other cases when all layouts are Latin, I didn't check this yet.
Maybe someone could constructively criticize my approach so that I could do it in a better way.
Didn't try to submit it to Qt, since 1) not sure if it's the right approach and 2) Qt bug 15319 is closed.
Comment 61 Pavlo Verba 2016-06-17 22:45:06 UTC
I would like to note that this bug is still alive and doing well. I am on openSUSE Tumbleweed with KDE Plasma 5.5.3, KDE Frameworks 5.22.0 and Qt 5.6.0, and it sure does not look fixed from here. :)
Comment 62 Nick Stefanov 2016-06-18 09:11:29 UTC
Same here with Arch and Plasma 5.5.3. 4 years...
Comment 63 Ian 2016-08-10 08:14:54 UTC
just adding my 2c worth ... I also have this problem. am experimenting with different layouts, all variants of US English.

Hotkey behaviour seems to vary by program---  some work fine, others work if you hit where the key is supposed to be on US QWERTY layout. It SEEMED to me as if the program was reading the scancode rather than the letter it was mapped to ....

My layouts in order are:
standard US QWERTY
Custom layout

Thanks, Ian
Comment 64 Hexawolf 2018-01-20 21:21:45 UTC
Can be reproduced on Arch Linux, KDE on Wayland, seems to work with Firefox but doesn't works with Kate, Telegram, Konsole and probably any other Qt application. Seems to work on Gnome. Doesn't works if layout is non-latin. Haven't tested on X session.

KDE Plasma Version: 5.11.5
KDE Frameworks Version: 5.42.0
Qt Version: 5.10.0

It's 2018, can this finally receive some attention or KDE developers really care about bugs less than those fancy "vaults" that nobody actually cares about?
Comment 65 Christoph Feck 2018-01-21 02:22:28 UTC
Probably needs a Qt patch similar to comment #60. We didn't find a developer yet who is able to fix it.
Comment 66 Albert Astals Cid 2018-01-21 19:05:20 UTC
(In reply to Hexawolf from comment #64)
> It's 2018, can this finally receive some attention or KDE developers really
> care about bugs less than those fancy "vaults" that nobody actually cares
> about?

I like how you know what every single person in the world cares about. Maybe if you really care about this bug you should hire someone to fix it. Stop bitching  about things you're given for free, it doesn't make you look nice.
Comment 67 Nate Graham 2020-07-26 02:20:28 UTC
Ruslan, if this is a Qt issue, would you be interested in submitting a patch for Qt 5?

That said, all of the Qt bug reports listed in the comment thread here have been closed upstream. Apparently the Qt developers think it's fixed. If it's not fixed, can somebody file a new one?
Comment 68 Ruslan Kabatsayev 2020-07-26 05:04:35 UTC
(In reply to Nate Graham from comment #67)
> Ruslan, if this is a Qt issue, would you be interested in submitting a patch
> for Qt 5?

I don't reproduce this problem with Qt5, at least in Kubuntu 18.04, so I suppose it's fixed there.
Comment 69 Nate Graham 2020-07-26 13:31:15 UTC
Phew! Thanks for the confirmation.
Comment 70 Egor T 2020-12-28 23:52:46 UTC
Kubuntu 20.10, bug still exist. If I set Russian layout to Top in list, shortcuts stops working (Ctrl+Atl+T, Win+E and other).
Comment 71 Ruslan Kabatsayev 2020-12-29 00:00:03 UTC
(In reply to Egor T from comment #70)
> Kubuntu 20.10, bug still exist. If I set Russian layout to Top in list,
> shortcuts stops working (Ctrl+Atl+T, Win+E and other).

Looks like you're mentioning some _global_ shortcuts (similar to Alt+F2). These are likely implemented in a very different way than application-local ones (like Ctrl+S). If I'm right that your shortcuts are global, then this should go into a different bug report.
Comment 72 Bharadwaj Raju 2021-04-20 09:30:51 UTC

*** This bug has been marked as a duplicate of bug 375518 ***
Comment 73 Andrey 2021-04-23 13:08:44 UTC
I'm sorry but seems bug 375518 fixes the problem for Wayland only.
I'll see if similar approach can be reused to fix it on X11
Comment 74 Andrey 2021-04-23 22:32:43 UTC
(In reply to Andrey from comment #73)
> I'll see if similar approach can be reused to fix it on X11
Well, it can.
But need to link KKeyServer with xkbcommon library first and add some glue init code there, pretty much the same as it's done in https://code.woboq.org/qt5/qtbase/src/plugins/platforms/xcb/qxcbkeyboard.cpp.html.
Also it might be worth to think about reusing that whole Qt's xcbkeyboard plugin as from what I can see KKeyServer mostly just duplicates functionality there.
Comment 75 Andrey 2022-03-28 11:27:13 UTC
*** Bug 451821 has been marked as a duplicate of this bug. ***
Comment 76 Andrey 2022-05-11 11:33:40 UTC
Assuming this bug is opened for local shortcuts, closing as fixed in Qt.
For global shortcuts, it was fixed in KWin for Wayland, for X11 see my notes above.
Comment 77 empyreal 2022-08-11 19:40:40 UTC
Global actions/shortcuts do not work after language change.
Global actions/shortcuts in  System Settings - Shortcuts - Media Controller work only when EN language is selected.
Operating System: Kubuntu 22.10
KDE Plasma Version: 5.25.4
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.4
Kernel Version: 5.15.0-46-generic (64-bit)
Graphics Platform: X11
Comment 78 Nate Graham 2022-08-11 19:51:33 UTC
That sounds like a different issue. Please file a new bug report.