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: Nothing Expected Results: Hotkeys should have effect
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.
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.
But I don't know what product should I set to this bug.
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
*** Bug 272259 has been marked as a duplicate of this bug. ***
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.
(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.
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.
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.
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
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.
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
Typo: Hope they fix it soon.*
I hope too. Sent link to other affected users I know with proposal to register, comment and vote.
I've found only Qt 5.1 bug https://bugreports.qt-project.org/browse/QTBUG-32274 but 4.8.5 mentiod there.
*** This bug has been confirmed by popular vote. ***
for me it seems this bug, which also seems to be the same as 274820 and 320423 Is fixed with Qt: 4.8.5 KDE: 4.10.5 "release 4"
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.
*** Bug 322454 has been marked as a duplicate of this bug. ***
*** Bug 320008 has been marked as a duplicate of this bug. ***
On archlinux and kubuntu similar problem have.
Fedora 19 with KDE 4.10.5 and Qt 4.8.4, similar problem.
@paul_arts, what happens if you upgrade to Qt 4.8.5?
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
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.
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.
(In reply to comment #26) > — hot keys work. If first layout is latin.
Here I post report: https://bugreports.qt-project.org/browse/QTBUG-32908 Please comment.
*** Bug 322027 has been marked as a duplicate of this bug. ***
The change was reverted upstream: http://qt.gitorious.org/qt/qt/commit/1f76ee2c4615907033f670fb61ea2eff515d72e9/diffs/0c03af0d4d928bdbb32b09eedb1dba3ce59e5278
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...
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: https://bugs.kde.org/show_bug.cgi?id=306374 https://bugs.kde.org/show_bug.cgi?id=316909 https://bugs.kde.org/show_bug.cgi?id=209699
Hello everyone! After months of switching layouts and banging my head against this bug, I thought I should check LibreOffice settings (I'm using 4.1.5.3 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. Cheers! PS Technically, though, shortcuts still remain language-dependent. This means if you enable this option, you will have to set your document languages manually.
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
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).
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.
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.
Wrong, it's not fixed, I have the same bug in Arch.
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.
We're probably talking of different issues then. The original issue only happens when you use multiple keyboard layouts, not just one.
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.
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 (((
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.
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.
can somebody explain me why anybody would need to have non-English layout first in the list?
Can anyone reproduce this in kf5/qt5-based apps?
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.
Upstream bugreport: https://bugreports.qt.io/browse/QTBUG-15319
(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
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
ok to close as FIXED UPSTREAM?
Please leave it open until we have confirmed it's fixed for all our users in all the software versions we maintain.
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, …).
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.
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
This used to work with KDE 4 but is broken with Arch and Plasma 5.5.2.
This fixed the problem for me (from https://forum.kde.org/viewtopic.php?f=289&t=130179&p=348185#p348027 ): pkill kglobalaccel5 kglobalaccel5 &
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.
... Forgot to mention that those shortcuts in KDevelop actually do work once every few weeks but the next reboot they are gone again.
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.
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. :)
Same here with Arch and Plasma 5.5.3. 4 years...
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: EurKey standard US QWERTY Custom layout Thanks, Ian
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?
Probably needs a Qt patch similar to comment #60. We didn't find a developer yet who is able to fix it.
(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.
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?
(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.
Phew! Thanks for the confirmation.
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).
(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.
*** This bug has been marked as a duplicate of bug 375518 ***
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
(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.
*** Bug 451821 has been marked as a duplicate of this bug. ***
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.
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
That sounds like a different issue. Please file a new bug report.