Bug 320423

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. ***