Keyboard shortcuts like Ctrl-C, Ctrl-V does not work in some apps like kate and kdevelop, krusader when russian layout is active Reproducible: Always Steps to Reproduce: 1. Open Kate, type some text 2. Switch layout to russian select some text and press Ctrl-C 3. Move cursor to another place and press Ctrl-V Actual Results: text will not pasted into new place Expected Results: text successfully copies to clipboard and then pasted into new place reproduces in kde apps when it runs from either kde or mate desktop. works well in non-kde applications like firefox
Ladies and Gentlemen, Can we please have this issue escalated somehow? For example, put it in most hated bugs...
> Can we please have this issue escalated somehow? For example, put it in most hated bugs... Well, that is not how "most hated bugs" are defined . Most hated bugs, just as their names imply, are bugs that really really really has many many many haters, subscribers, comments and votes. No one can put a bug report only created yesterday into "most hated bugs". I'm not an expert of keyboard layout and shortcut, but I suspect the root cause is in Qt. Try some Qt only applications to see whether they suffer the same problem.
Is the qtcreator qt-only application? It does not affected to this bug.
Hello Jekyll! Thank you for the feedback! Please, search the bugs database for "keyboard layout shortcuts" and observe the results. There are quite a lot similar bugs. Skype is Qt. With it I have no problems. However if I start kwrite/kate, dolphin or whatever KDE app, I experience the following behaviour: 1) Write in English - Ctrl-V, Ctrl-C, Ctrl-X works. 2) Switch layout to Bulgarian 3) Write in Bulgarian - not a single shortcut, containing a letter works ( Ctrl-V, Ctrl-C ) IMHO this is very embarrassing. Although most of the time I use Latin letters, I should be able to use keyboard shortcuts with Cyrillic layout as well. To define the impact: Basically I am not convinced that using different keyboard layout is useful, when I have to sacrifice 50% of the usability of my keyboard. Please let me know if this bug can be re-prioritized. P.S. I know that the people here are not obligated in resolving bugs, so I thank everyone in advance for their spared time!
Is this bug report about the KDE text editor component (kate, kwrite, kdevelop, kile), or all KDE apps (e.g. Calligra, Konqueror etc.)?
Konqueror does not affected this bug. Calligra don't started on my machine saying: "Legacy integer arithmetics implementation", lol. Never use it before.
Hi I asked some people on forums whether they experience same behaviour - they said no. Could it be related to input method? Currently I am NOT using ibus, BUT switching it on does not change anything.
update: calligraauthor, calligraflow, calligrasheets, calligrastage, calligrawords are affected to this bug.
Indeed, Konqueror is NOT affected. Only text editors.
I have it too. Ukrainian layout is broken as well. Affected apps: Kate, Krusader, Konsole, QupZilla. Not affected: Qmmp main window (Qt music player) Some highlights: 1) Ctrl+. is set to "show hidden files" in Krusader. For English layout pressing that opens a search bar and prints a dot there. For Russian/Ukrainian layout the similar combination with Cyrillic dot (different key on a keyboard) does a trick (show/hide hidden files). 2) Ctrl+Shift+P is set to "Print screen" in Konsole. Actually it works like Ctrl+P or Ctrl+"Arrow Up": show previous command from history. 3) Combinations like Alt+Arrow or Ctrl++ seems fine. 4) Combinations like Alt with letter is broken. For example, Alt+N prints a question mark in Konsole while assigned to "Add bookmark". KDE 4.10.4 from repos of Fedora 19 beta x86-64 qt-4.8.4-19.fc19.x86_64
This is actually a Qt bug: https://bugreports.qt-project.org/browse/QTBUG-15319 To be fixed in Qt 4.8.5
I updated Qt to qt-4.8.5-2.fc19.x86_64 but problem still here.
I have this too with Qt 4.8.5 Updated to following versions of packages. Launching "setxkbmap -layout us,ru" doesn't fix it. qt-4.8.5-2.fc19.i686.rpm qt-4.8.5-2.fc19.x86_64.rpm qt-assistant-4.8.5-2.fc19.x86_64.rpm qt-demos-4.8.5-2.fc19.x86_64.rpm qt-devel-4.8.5-2.fc19.x86_64.rpm qt-doc-4.8.5-2.fc19.noarch.rpm qt-examples-4.8.5-2.fc19.x86_64.rpm qt-x11-4.8.5-2.fc19.i686.rpm qt-x11-4.8.5-2.fc19.x86_64.rpm
Confirm this bug. QT version: qt-4.8.4-19.fc19.x86_64
I can confirm this bug too. Qt: qt-4.8.5-2.fc19 (https://koji.fedoraproject.org/koji/buildinfo?buildID=431260) KDE: 4.10.4-1.fc19
Confirm this bug. QT version: qt-4.8.4-19.fc19.x86_64 KDE version: 4.10.4-1.fc19.x86_64
I use greek layout and keyboard shortcuts don't work for Kate or Calligra (but work for some other kde apps). Very annoying bug.
*** This bug has been confirmed by popular vote. ***
this bug may be the same as 274820 and 309193 they are fixed for me with Qt: 4.8.5 KDE: 4.10.5 "release 4"
I am sorry it is not fixed. Have you tried setting a latin layout as first layout? This may serve as a workaround.
(In reply to comment #19) > this bug may be the same as > 274820 and > 309193 > they are fixed for me with > Qt: 4.8.5 > KDE: 4.10.5 "release 4" It is strange: I also use qt 4.8.5, and at that 309193 discussion especially qt 4.8.5 is treated as a reason of the issues, while you have opposite situation. And I'm not aware of "release 4" applied to KDE - is it your distribution specific?
No I am sorry, i was confused. I had this problem for a longer time. My workaround was setting a standard layout as first layout, neo as secondary layout, but that produced inconsistent shortcuts between kde and non kde apps. Now that I updated my opensuse 12.3 it was suddenly consistent and I thought it was fixed, but I had only forgotten about the workaround. Plus I thougt that what applies to neo layout may apply to a russian layout - this may also not be the case.
(In reply to comment #20) As for me, setting "setxkbmap -layout us,ru" doesn't help. And the subject issue still present for Qt 4.8.5 / KDE 4.10.5. So seems like this is a different issue (not the same with 309193 / QTBUG-15319). Not sure for 274820.
Confirm this bug. Additionally information: * In kwrite: if I tap Ctrl+Shift+I in russian layout it is processed like Ctrl+I System information: System: 3.10.3-1-ARCH Qt ver: 4.8.5 KDE ver: 4.10.5
Confirm this bug. libqt4-4.8.5-321.1.x86_64 kde4-4.10.5-3.1 opensuse 12,3 setting "setxkbmap -layout us,ru" doesn't help either
(In reply to comment #24) > Additionally information: > * In kwrite: if I tap Ctrl+Shift+I in russian layout it is processed like > Ctrl+I In russian layout all combination with Ctrl + Shift + processed like Ctrl +
I confirm the problem (debian sid)
Please note when my locale is in gr then using Ctrl+Shift+... {C or V or P etc} works. In English shift is not needed to shortcuts (i.e. copy, past, print etc)
(In reply to comment #28) > Please note when my locale is in gr then using Ctrl+Shift+... {C or V or P > etc} works. Same for the russian and ukrainian layout. Ctrl+Shift+{A,P,W,N,O} with them act like same combinations without Shift for English. To be more clear, Ctrl+Shift+O does "open" when switched to RU / UA. The right combination is default, Ctrl+O and it works with English locale.
This bug is not about russian layout but all non-english layouts. Can we change the title to reflect that?
Already, with right title https://bugs.kde.org/show_bug.cgi?id=309193 Difference is that in qt4.8.4 all works fine if EN layout is set before any other, but in qt4.8.5 even worth - no matter what layout is first it is bug anyway. Follow here https://bugreports.qt-project.org/browse/QTBUG-32908 Please vote.
(In reply to comment #31) > Already, with right title > https://bugs.kde.org/show_bug.cgi?id=309193 > Difference is that in qt4.8.4 all works fine if EN layout is set before any > other, but in qt4.8.5 even worth - no matter what layout is first it is bug > anyway. > Follow here > https://bugreports.qt-project.org/browse/QTBUG-32908 > > Please vote. Yeah, I posted it and wrote for that in this tread :)
According to the Qt project bug tracker, a commit was made to the Qt 4.8 branch that should address this bug. Can someone who is able to compile Qt and reproduce this bug confirm that this commit[1] fixes this issue? Is bug 309193 a duplicate (it was already reported for Qt 4.8.4)? [1] see https://bugreports.qt-project.org/browse/QTBUG-32908 commit is 0c03af0d4d928bdbb32b09eedb1dba3ce59e5278
Fixed in Fedora 19 qt-4.8.5-8.fc19 https://koji.fedoraproject.org/koji/buildinfo?buildID=464133
I'm experiencing the same problem. Updated qt packages from build system to qt-4.8.5-8.fc19, but the problem still persists.
works for me after updating to qt-4.8.5-8.fc19 x86_64 from updates-testing
Does not help after same update... $ rpm -q qt qt-4.8.5-8.fc19.x86_64 qt-4.8.5-8.fc19.i686
(In reply to comment #33) > Is bug 309193 a duplicate (it was already reported for Qt 4.8.4)? As far as i understand, the current problem (KDE 320423, Qt 32908) is caused by the fix of KDE 309193 (Qt 15319). Then Qt 15319 patch was reverted in Qt 32908 and seems like Qt 15319 appeared again. I'm able to reproduce it with launching "setxkbmap -layout ru,us" and qt-4.8.5-8.fc19 (In reply to comment #35) (In reply to comment #37) Do you have the primary layout other than US?
I have primary layout set to 'us' and secondary to 'ru'. More precisely, I have 'English' language set in the Gnome Desktop settings and two configured input sources, first 'English US', and second one, 'Russian'.
I confirm bug - if non-english layout is first (ru in my case) than shortcuts dows not work
(In reply to comment #40) > I confirm bug - if non-english layout is first (ru in my case) than > shortcuts dows not work For me they don't work even if English layout is first
(In reply to comment #39) (In reply to comment #41) Do you have shortcut problems with RU case only or the currently selected layout doesn't matter (all layouts are affected)?
When layout is switched to 'en', there is no problem. I develop code in KDevelop and basically use English layout, so this bug won't hurt much when writing *C++ code*. But when I edit my TeX files (that I write in Russian) in same KDevelop, I use 'ru' layout and this bug spoils all the work. I need to switch to English just to copy-and-paste some text.
(In reply to comment #42) > (In reply to comment #39) > (In reply to comment #41) > Do you have shortcut problems with RU case only or the currently selected > layout doesn't matter (all layouts are affected)? Only when non-English layout is selected currently (in my case Russian).
(In reply to comment #43) (In reply to comment #44) OK, seems like you have the current issue not fixed. I'm just a curious Captain Obvious, sorry :) As for me, it is solved with the latest stable updates[1] of Fedora 19 x64. However seems like bug 309193 is present (not a problem for me because US layout is the first one). 1: $ rpm -qa qt\* qt-x11-4.8.5-8.fc19.x86_64 qtwebkit-2.3.2-1.fc19.i686 qt-mobility-1.2.2-0.4.20120224git.fc19.x86_64 qtsoap-2.7-5.fc19.x86_64 qt-4.8.5-8.fc19.x86_64 qt-qdbusviewer-4.8.5-8.fc19.x86_64 qt-4.8.5-8.fc19.i686 qt-mobility-1.2.2-0.4.20120224git.fc19.i686 qtwebkit-2.3.2-1.fc19.x86_64 qt-gstreamer-0.10.2-4.fc19.x86_64 qt3-3.3.8b-47.fc19.x86_64 qtlockedfile-2.4-6.fc19.x86_64 qtsingleapplication-2.6.1-8.fc19.x86_64 qt-settings-19-23.1.fc19.noarch qt-x11-4.8.5-8.fc19.i686
I have exactly same versions of qt*packages installed, but some packages are missing (marked with - sign) -qt3-3.3.8b-47.fc19.x86_64 qt-4.8.5-8.fc19.i686 qt-4.8.5-8.fc19.x86_64 -qt-gstreamer-0.10.2-4.fc19.x86_64 -qtlockedfile-2.4-6.fc19.x86_64 qt-mobility-1.2.2-0.4.20120224git.fc19.i686 qt-mobility-1.2.2-0.4.20120224git.fc19.x86_64 -qt-qdbusviewer-4.8.5-8.fc19.x86_64 qt-settings-19-23.1.fc19.noarch -qtsingleapplication-2.6.1-8.fc19.x86_64 qtsoap-2.7-5.fc19.x86_64 qtwebkit-2.3.2-1.fc19.i686 qtwebkit-2.3.2-1.fc19.x86_64
(In reply to comment #46) As far as I know, the differences shouldn't affect the current case... As a last resort: I use KDE (you've mentioned Gnome) and I verify the subject mostly in Kate. Configured layouts are us-ru-ua. Tried to remove UA but it doesn't change anything. $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+ru:2+ua:3+inet(evdev)+group(menu_toggle)+compose(caps)+terminate(ctrl_alt_bksp)" }; xkb_geometry { include "pc(pc104)" }; };
I just noticed that this bug is not present for me any more! I haven't done anything, it's probably some updates earlier. Check out how it works for you, folks. If someone really finally fixed this bug - thank you a lot! <3 OS: Arch Linux x86_64 KDE: 4.11.3 qt4: 4.8.5-6
(In reply to comment #48) > I just noticed that this bug is not present for me any more! I haven't done > anything, it's probably some updates earlier. Check out how it works for > you, folks. If someone really finally fixed this bug - thank you a lot! <3 > > OS: Arch Linux x86_64 > KDE: 4.11.3 > qt4: 4.8.5-6 That was me :3 https://bugs.archlinux.org/task/36947
This bug was fixed a long time ago :)
Still not working in Fedora 19. Reinstalling of qt package (with all depends) did not help.
Addition to my previous comment: My Qt & kde packages list: qt-x11-4.8.5-10.fc19.x86_64 qt-devel-4.8.5-10.fc19.x86_64 qt-4.8.5-10.fc19.x86_64 qt-mobility-1.2.2-0.4.20120224git.fc19.x86_64 qt-qdbusviewer-4.8.5-10.fc19.x86_64 qt-settings-19-23.1.fc19.noarch kdevplatform-1.5.1-1.fc19.x86_64 kdevelop-libs-4.5.1-1.fc19.x86_64 kde-settings-19-23.1.fc19.noarch kde-runtime-libs-4.11.2-1.fc19.x86_64 kde-runtime-drkonqi-4.11.2-1.fc19.x86_64 kdevelop-4.5.1-1.fc19.x86_64 kdelibs-common-4.11.2-1.fc19.x86_64 kdevplatform-libs-1.5.1-1.fc19.x86_64 kde-runtime-4.11.2-1.fc19.x86_64 kdelibs-4.11.2-1.fc19.x86_64 kde-filesystem-4-45.fc19.x86_64 kde-runtime-flags-4.11.2-1.fc19.noarch kdesdk-common-4.11.2-1.fc19.noarch
This bug should be fixed with Qt 4.8.6. Some distributions provide patched Qt 4.8.5 versions, which include the fix. If this bug still occurs with Qt 4.8.6, please add a comment to https://bugreports.qt-project.org/browse/QTBUG-32908
It is not a bug. It is feature :) Just additionally press Shift key under the non-english layout selected i.e.: Ctrl+c became Ctrl+Shift+c Ctrl+v became Ctrl+Shift+v Ctrl+s became Ctrl+Shift+s Ctrl+r became Ctrl+Shift+r and so on.
(In reply to comment #54) > It is not a bug. It is feature :) > Just additionally press Shift key under the non-english layout selected i.e.: > Ctrl+c became Ctrl+Shift+c > Ctrl+v became Ctrl+Shift+v > Ctrl+s became Ctrl+Shift+s > Ctrl+r became Ctrl+Shift+r > and so on. It *was* a Qt bug resolved an age ago.
(In reply to comment #55) > It *was* a Qt bug resolved an age ago. Maybe it's a bit inappropriate to say "ages ago" when this bug is still present in Ubuntu 14.04 (which uses Qt version 4.8.6).
(In reply to comment #56) > Maybe it's a bit inappropriate to say "ages ago" when this bug is still > present in Ubuntu 14.04 (which uses Qt version 4.8.6). May be, of course! I mean own experience only. Under Arch Linux the issue has gone really few months ago.
Still having this issue with Qt 4.8.6 on FC20.
(In reply to comment #58) > Still having this issue with Qt 4.8.6 on FC20. Hm, absent for me on nearly the same (RFRemix 20 x64). Can copy-paste in Kate with russian layout active. $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+ru:2+ua:3+inet(evdev)+group(menu_toggle)+compose(caps)+terminate(ctrl_alt_bksp)" }; xkb_geometry { include "pc(pc105)" }; };
If you can still reproduce it, can you please check, if there are any "input method" helpers are installed (ibus, fcitx), and if yes, if removing those solves this issue?
(In reply to comment #60) > If you can still reproduce it, can you please check, if there are any "input > method" helpers are installed (ibus, fcitx), and if yes, if removing those > solves this issue? Ok, I'll check it. Could you provide exact actions I should execute to get this info?
If you never used the package manager, you would need to ask in a forum of your distribution whether one of those is installed by default.
(In reply to Christoph Feck from comment #62) > If you never used the package manager, you would need to ask in a forum of > your distribution whether one of those is installed by default. I had NOT installed any helpers manually. I have 'plain' Fedora 20 distribution. To be precise about packages: rpm -qa | grep -i ^ibus ibus-libs-1.5.7-2.fc20.x86_64 rpm -qa | grep -i fcitx (nothing)
Hmm, cannot reproduce this on my FC20 Heisenbug installation. But I'm using LXDE. My xkbmap config is the following: mvel@blackbox: ~ $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+ru:2+inet(evdev)+group(alt_shift_toggle)" }; xkb_geometry { include "pc(pc105)" }; }; mvel@blackbox: ~ $ cat ~/.Xkbmap -option grp:alt_shift_toggle,grp_led:scroll us,ru But I also have some ibus libs installed, even more than Dmitry has: mvel@blackbox: ~ $ rpm -qa '*ibus*' ibus-libpinyin-1.6.92-2.fc20.x86_64 ibus-chewing-1.4.10.1-1.fc20.x86_64 libuser-python-0.60-3.fc20.x86_64 libusbx-1.0.19-1.fc20.x86_64 libusb-0.1.5-3.fc20.x86_64 ibus-rawcode-1.3.2-3.fc20.x86_64 ibus-setup-1.5.7-2.fc20.noarch libusbx-1.0.19-1.fc20.i686 ibus-hangul-1.4.2-7.fc20.x86_64 ibus-gtk3-1.5.7-2.fc20.x86_64 libusal-1.1.11-22.fc20.x86_64 ibus-1.5.7-2.fc20.x86_64 libuser-0.60-3.fc20.x86_64 ibus-libs-1.5.7-2.fc20.x86_64 ibus-wayland-1.5.7-2.fc20.x86_64 ibus-m17n-1.3.4-12.fc20.x86_64 ibus-kkc-1.5.20-1.fc20.x86_64 ibus-gtk2-1.5.7-2.fc20.x86_64 mvel@blackbox: ~ $ rpm -qa '*fcitx*' mvel@blackbox: ~ $ But since both QTBUG-32908 and QTBUG-15319 stay unresolved, I guess we need to wait for Qt5 to get it finally fixed :)
Still reproducible in Ubuntu 14.04, Qt 4.8.5, Kde 4.13.2.
(In reply to Ilya V. Portnov from comment #65) > Still reproducible in Ubuntu 14.04, Qt 4.8.5, Kde 4.13.2. Yes. Some time ago I've noticed this issue on 14.04 too.
Same problem(. Ubuntu 14.04 x64 3.13.0-32-generic
Same problem Ctrl-A, Ctrl-C, Ctrl-V doesn't work in KDE programms but work fine everywhere else. Kubuntu 14.04 x64 wit the latest updates till date. dpkg -l | awk '/ibus/{print $2" "$3}' ibus-qt4 1.3.2-2 libgusb2:i386 0.1.6-5 libibus-1.0-5:i386 1.5.5-1ubuntu3 libibus-qt1 1.3.2-2 libusb-0.1-4:i386 2:0.1.12-23.3ubuntu1 libusb-1.0-0:i386 2:1.0.17-1ubuntu2 libusbmuxd2 1.0.8-2ubuntu1 libustr-1.0-1:i386 1.0.4-3ubuntu2
Is this really restricted to russian layout? It might actually be a change in X11 russian keyboard layouts.
(In reply to Christoph Feck from comment #69) > Is this really restricted to russian layout? It might actually be a change > in X11 russian keyboard layouts. I've also noticed that this problem is reported mostly by russian comminity users, so this could be a right suggestion. Anyway, is there a hack/workaround for us?
Why not you try bulgarian layot to check it out?
This is present in Plasma 5 (Plasmashell) though..
I've tested this issue under LXDE and I had the same problem. Moreover, I've tested some different layouts under LXDE and Gnome shells and I've got DIFFERENT results. For example: 1) Russian: FAIL 2) Serbian: FAIL 3) Armenian: FAIL 4) Belarus: FAIL 5) Spanish: OK 6) French: OK 7) Hungarian: OK 8) Moldovian: OK
In earlier days in KDE there was a setting in keyboard layout "include Latin layout" that has gone. I suspect the problem is connected with the lack of Latin characters in, say, Cyrillic layout as it is not Latin. And according to Dmitry Veltishev we see, that the problem is only in non-Latin layouts. I use 4.13.3 KDE and met the problem. In 4.10.5 and 4.8.5 I did not have this problem.
I've found a weird workaround for this problem. In systemsettings I have 2 layouts in following order: first russian, then english. But when I have swapped them, all the shortcuts started working!
I have fixed the problem, by fixing QTBUG-32908 Here is the patch: From 8660bb907ef132f2c7c774a7b05f96bf8cab00e6 Mon Sep 17 00:00:00 2001 From: Gatis Paeglis <gatis.paeglis@digia.com> Date: Sat, 31 Aug 2013 21:22:47 +0200 Subject: [PATCH] Revert "QTBUG-15319: fix shortcuts with secondary Xkb layout." The change which attempted to fix QTBUG-15319 broke keyboard shortcuts for non latin keyboard layouts. This patch reverts QTBUG-15319 (f45cdeda8) since it caused a regression. Task-number: QTBUG-32908 Change-Id: I47d7984fa7986d5218d1f3ff1fc36d2ec67c9ba7 --- src/gui/kernel/qkeymapper_x11.cpp | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/gui/kernel/qkeymapper_x11.cpp b/src/gui/kernel/qkeymapper_x11.cpp index 005ff3f..7daa41d 100644 --- a/src/gui/kernel/qkeymapper_x11.cpp +++ b/src/gui/kernel/qkeymapper_x11.cpp @@ -282,12 +282,9 @@ QList<int> QKeyMapperPrivate::possibleKeysXKB(QKeyEvent *event) // first, translate key only using lock modifiers (there are no Qt equivalents for these, so we must // always use them when determining the baseKeySym) - // Note: the Xkb group to be used for the conversion keycode->keysym has to be given to - // XkbLookupKeySym(). This information is contained in the bits 8 to 15 of xmodifiers. - // See https://bugreports.qt-project.org/browse/QTBUG-15319 . KeySym baseKeySym; uint consumedModifiers; - if (!XkbLookupKeySym(X11->display, xkeycode, (xmodifiers & (0xff00 | LockMask | qt_num_lock_mask)), + if (!XkbLookupKeySym(X11->display, xkeycode, (xmodifiers & (LockMask | qt_num_lock_mask)), &consumedModifiers, &baseKeySym)) return QList<int>(); -- 1.8.4
(In reply to Igor Poboiko from comment #75) > I've found a weird workaround for this problem. In systemsettings I have 2 > layouts in following order: first russian, then english. But when I have > swapped them, all the shortcuts started working! I believe this is because the first layout is used for shortcuts regardless of which input is currently in use. This is/was also a bug. More info in the Launchpad bugs related to this: https://bugs.launchpad.net/unity/+bug/1226962
Igor's Poboiko's exploit did the trick for me too. (Comment 75)
Problem solves when you move Russian Keyboard Layout near the others. Проблема решается, если переместить Русскую раскладку ниже Английской, в окне Клавиатура - Модуль настройки KDE.
Abstract -------- In KDE4 times, there was a QT bug messing up shortcuts when a non-standard (russian, neo, etc.) keyboard layout or variant was set as the default layout either via xorg.conf or in the System Setting of KDE4. This is documented in the KDE as well as in the QT bug tracker [1,2], and was fixed at some point for QT4 and KDE4. According to [1], the issue reappeared for Plasma5 . My observation on Plasma5 is, than not only the shortcuts are affected, but also mouse clicks fall through, at least for Java applications using the Abstract Window Toolkit [3]. The Java application in question is Matlab (R2015a), and since it is closed source (sorry, not my choice), I rely on information from the java console (jconsole). Setup and configuration ----------------------- I experience the issue running Plasma 5 a MacBook Pro using the Intel Integrated Graphics Controller of its i7 cpu. My graphics setup is 20-intel.conf -------------- Section "Device" Identifier "Intel Graphics" Driver "intel" Option "TearFree" "true" EndSection So I am using the standard open source "intel" driver. My keyboard setup on X11 level is 20-keyboard.conf ---------------- Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "de" Option "XkbModel" "pc104" EndSection I use the German keyboard layout "de" here. I would love to configure neo [4,5], but unfortunately, this kills shortcuts and clicks. In the System Setting of Plasma 5 under "Input Devices" I configure two layouts. Both are German, the first in the default variant "de", the second in the variant "neo". I leave the System Setting of KDE 4 alone. The situation ------------- To make the naming of shortcuts clear I prepend the active variant "de" or "neo" to the shortcut. This is de[Strg+c] is copy in the sense of the "de" variant, and the actual keys pressed coincide with the labeling on the physical keyboard. In contrary neo:[Strg+c] refers to copy in the frame of the neo variant, but the actual keys pressed with respect to the physical keyboard are Strg+r. The setup described above leads to the following situation. --- Keyboard shortcuts ---- ------------------ ------ KF5 based applications In KF5 based applications like KWrite, keyboard shortcuts follow the layout variant. This is, neo[Strg+x] cuts out text, and de[Strg+x] also cuts out text when the respective layout is activated. Interestingly, if "neo" is active, and I hit neo[Strg+ö] which is de[Strg+x], text is also cut out. So, the shortcut is interpreted as if "de" would be active. However, if I hit neo[Strg+p] which is de[Strg+v], text is not inserted as you might expect, but the print dialog opens. This is because neo[Strg+p] is the shortcut for print. So, a shortcut configured in the frame of the currently active variant "neo" takes precedence over whatever is configured in the frame of an inactive variant. This is already strange by itself, and I would considered it a bug. ------ KDE 4 applications In applications still based on KDE4 such as Dolphin, only the shortcuts in the frame of the "de" variant work. This makes perfect sense, since X11 only know about "de" and the System Setting of KDE 4 are not changed. Here, I would love so see, that KDE 4 applications follow whatever is configured for Plasma5 to avoid inconsistencies. The usual user simply does not care which libraries an application uses, and hence does not want to configure the same things twice for different applications. --- Mouse clicks ---------------- As already mentioned in the Abstract, I use Matlab which is a Java application. The situation is a little fuzzy in detail, but the general picture is, that if there are more than two Matlab windows open, e.g. the editor and two windows for plots, the clicks fall through the window which is clicked. This only happens, if the non-standard keyboard layout variant "neo" is active. To this end, it is not important if it is the primary or the non- primary variant. If I configure "neo" as the only variant on X11 level, keyboard and clicks are broken. If I configure "de" as the only variant in X11 and "de" as primary and "neo" as secondary variant in the Plasma5 System Setting, clicks are broken as soon as "neo" is active, and work all right is "de" is active. Information I can provide ------------------------- I would be glad to help the situation by providing further information. I would categorize myself as an advanced user. So you can ask me for all information I can gather on the command line, system logs, java console, etc. I fear, however, that I can not offer to compile e.g. kwin in order to test patches; therefore, I am simply lacking the time. I run Arch Linux, and as far is I know, they strip their binaries. Debugging information is therefore of limited use. If there is really the need, irrespective of what I just say, you can ask me to compile, and I see what I can do. References ---------- [1] https://bugs.kde.org/show_bug.cgi?id=320423 [2] https://bugreports.qt.io/browse/QTBUG-32908 [3] https://en.wikipedia.org/wiki/Abstract_Window_Toolkit [4] http://www.neo-layout.org/ [5] http://en.wikipedia.org/wiki/Keyboard_layout#Neo
(In reply to Knube2015 from comment #79) > Problem solves when you move Russian Keyboard Layout near the others. > Проблема решается, если переместить Русскую раскладку ниже Английской, в > окне Клавиатура - Модуль настройки KDE. Thank you. It's solved problem with Ctrl+C on plasma 5 Fedora 22 too.
I beleive this issue should be reopened, since it is not actually resolved. I don't know, maybe it's resolved in Qt, but for some reason the fix did not land in actual kde versions. There are still reports like https://bugs.kde.org/show_bug.cgi?id=350095.
(In reply to Ilya V. Portnov from comment #82) > I beleive this issue should be reopened, since it is not actually resolved. > I don't know, maybe it's resolved in Qt, but for some reason the fix did not > land in actual kde versions. There are still reports like > https://bugs.kde.org/show_bug.cgi?id=350095. +1 for reopening. There is also a longer bug report [1] discussing the same issue also touching on an issue with mouse clicks which seems, at least to me, related. [1] https://bugs.kde.org/show_bug.cgi?id=347964
+1 for reopening - the problem is not solved.
*** Bug 350095 has been marked as a duplicate of this bug. ***