Bug 320423 - Keyboard shortcuts like Ctrl-C, Ctrl-V does not work in some apps like kate and kdevelop, krusader when russian layout is active
Summary: Keyboard shortcuts like Ctrl-C, Ctrl-V does not work in some apps like kate a...
Status: RESOLVED UPSTREAM
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: shortcuts (show other bugs)
Version: 4.10.3
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL: https://bugreports.qt-project.org/bro...
Keywords:
: 350095 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-05-29 14:21 UTC by glad08
Modified: 2015-08-12 13:24 UTC (History)
38 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description glad08 2013-05-29 14:21:17 UTC
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
Comment 1 Ivan Georgiev 2013-05-29 16:08:33 UTC
Ladies and Gentlemen,

Can we please have this issue escalated somehow? For example, put it in most hated bugs...
Comment 2 Jekyll Wu 2013-05-30 06:56:42 UTC
> 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.
Comment 3 glad08 2013-05-30 07:24:05 UTC
Is the qtcreator qt-only application? It does not affected to this bug.
Comment 4 Ivan Georgiev 2013-05-30 08:03:17 UTC
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!
Comment 5 Christoph Feck 2013-06-16 01:33:04 UTC
Is this bug report about the KDE text editor component (kate, kwrite, kdevelop, kile), or all KDE apps (e.g. Calligra, Konqueror etc.)?
Comment 6 glad08 2013-06-17 08:24:00 UTC
Konqueror does not affected this bug.
Calligra don't started on my machine saying: "Legacy integer arithmetics implementation", lol. Never use it before.
Comment 7 Ivan Georgiev 2013-06-17 08:36:47 UTC
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.
Comment 8 glad08 2013-06-17 09:04:24 UTC
update: calligraauthor, calligraflow, calligrasheets, calligrastage, calligrawords are affected to this bug.
Comment 9 Ivan Georgiev 2013-06-17 11:16:38 UTC
Indeed, Konqueror is NOT affected. Only text editors.
Comment 10 Andrew 2013-06-18 11:56:09 UTC
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
Comment 11 Lukáš Tinkl 2013-07-02 19:21:14 UTC
This is actually a Qt bug: https://bugreports.qt-project.org/browse/QTBUG-15319

To be fixed in Qt 4.8.5
Comment 12 Vasiliy Glazov 2013-07-04 11:48:57 UTC
I updated Qt to qt-4.8.5-2.fc19.x86_64 but problem still here.
Comment 13 Andrew 2013-07-04 14:06:32 UTC
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
Comment 14 Alexander Mustafin 2013-07-08 08:28:16 UTC
Confirm this bug. 
QT version: qt-4.8.4-19.fc19.x86_64
Comment 15 Alexei Panov 2013-07-09 13:58:59 UTC
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
Comment 16 Stas Ashirov 2013-07-11 06:00:40 UTC
Confirm this bug. 
QT version: qt-4.8.4-19.fc19.x86_64
KDE version: 4.10.4-1.fc19.x86_64
Comment 17 Kim 2013-07-11 11:12:18 UTC
I use greek layout and keyboard shortcuts don't work for Kate or Calligra (but work for some other kde apps).
Very annoying bug.
Comment 18 Andrew Gaydenko 2013-07-12 11:49:53 UTC
*** This bug has been confirmed by popular vote. ***
Comment 19 Wolfgang Brehm 2013-07-16 20:08:51 UTC
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"
Comment 20 Wolfgang Brehm 2013-07-16 20:27:13 UTC
I am sorry it is not fixed.
Have you tried setting a latin layout as first layout?
This may serve as a workaround.
Comment 21 Andrew Gaydenko 2013-07-16 20:28:59 UTC
(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?
Comment 22 Wolfgang Brehm 2013-07-16 20:37:01 UTC
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.
Comment 23 Andrew 2013-07-17 09:14:26 UTC
(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.
Comment 24 arcanis 2013-07-31 16:17:46 UTC
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
Comment 25 Alex Savin 2013-08-05 17:49:09 UTC
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
Comment 26 Stas Ashirov 2013-08-07 06:57:14 UTC
(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 +
Comment 27 snvv101 2013-08-25 20:00:52 UTC
I confirm the problem (debian sid)
Comment 28 snvv101 2013-08-25 20:06:02 UTC
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)
Comment 29 Andrew 2013-08-26 06:43:30 UTC
(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.
Comment 30 Kim 2013-08-27 09:15:29 UTC
This bug is not about russian layout but all non-english layouts. Can we change the title to reflect that?
Comment 31 StanislavArch 2013-08-28 11:56:06 UTC
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.
Comment 32 Nick Stefanov 2013-08-28 18:52:37 UTC
(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 :)
Comment 33 Christoph Feck 2013-09-12 22:02:14 UTC
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
Comment 34 Stas Ashirov 2013-09-13 08:34:29 UTC
Fixed in Fedora 19
qt-4.8.5-8.fc19
https://koji.fedoraproject.org/koji/buildinfo?buildID=464133
Comment 35 Dmitry Veltishev 2013-09-22 21:19:52 UTC
I'm experiencing the same problem. Updated qt packages from build system to qt-4.8.5-8.fc19, but the problem still persists.
Comment 36 glad08 2013-09-23 12:26:38 UTC
works for me after updating to qt-4.8.5-8.fc19 x86_64 from updates-testing
Comment 37 Mikhail Veltishchev 2013-09-24 12:44:45 UTC
Does not help after same update...
$ rpm -q qt
qt-4.8.5-8.fc19.x86_64
qt-4.8.5-8.fc19.i686
Comment 38 Andrew 2013-09-24 16:45:44 UTC
(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?
Comment 39 Mikhail Veltishchev 2013-09-24 17:50:00 UTC
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'.
Comment 40 glad08 2013-09-25 09:00:57 UTC
I confirm bug - if non-english layout is first (ru in my case) than shortcuts dows not work
Comment 41 Someone 2013-09-25 09:13:14 UTC
(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
Comment 42 Andrew 2013-09-25 09:42:05 UTC
(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)?
Comment 43 Mikhail Veltishchev 2013-09-25 09:51:28 UTC
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.
Comment 44 Someone 2013-09-25 09:55:10 UTC
(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).
Comment 45 Andrew 2013-09-25 10:07:31 UTC
(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
Comment 46 Mikhail Veltishchev 2013-09-25 10:26:50 UTC
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
Comment 47 Andrew 2013-09-25 10:53:19 UTC
(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)"     };
};
Comment 48 Someone 2013-11-07 15:03:14 UTC
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
Comment 49 valdikss 2013-11-07 15:05:32 UTC
(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
Comment 50 Nick Stefanov 2013-11-07 17:10:34 UTC
This bug was fixed a long time ago :)
Comment 51 Dmitry Veltishev 2013-11-07 19:47:32 UTC
Still not working in Fedora 19.
Reinstalling of qt package (with all depends) did not help.
Comment 52 Dmitry Veltishev 2013-11-07 19:53:08 UTC
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
Comment 53 Christoph Feck 2013-11-07 20:15:16 UTC
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
Comment 54 Andriy Batiuk 2014-04-13 19:05:28 UTC
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.
Comment 55 Andrew Gaydenko 2014-04-13 20:00:58 UTC
(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.
Comment 56 cmertes 2014-05-03 15:55:17 UTC
(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).
Comment 57 Andrew Gaydenko 2014-05-03 16:29:36 UTC
(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.
Comment 58 Dmitry Veltishev 2014-06-02 09:49:14 UTC
Still having this issue with Qt 4.8.6 on FC20.
Comment 59 Andrew 2014-06-02 17:03:21 UTC
(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)"     };
};
Comment 60 Christoph Feck 2014-06-04 20:07:43 UTC
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?
Comment 61 Dmitry Veltishev 2014-06-05 10:55:59 UTC
(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?
Comment 62 Christoph Feck 2014-07-17 18:50:05 UTC
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.
Comment 63 Dmitry Veltishev 2014-07-17 19:52:14 UTC
(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)
Comment 64 Mikhail Veltishchev 2014-07-17 20:21:52 UTC
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 :)
Comment 65 Ilya V. Portnov 2014-07-31 12:47:44 UTC
Still reproducible in Ubuntu 14.04, Qt 4.8.5, Kde 4.13.2.
Comment 66 Dmitry Veltishev 2014-08-02 23:23:10 UTC
(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.
Comment 67 Stanislav 2014-08-12 09:54:02 UTC
Same problem(. Ubuntu 14.04 x64 3.13.0-32-generic
Comment 68 sunwebrw 2014-08-14 07:13:21 UTC
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
Comment 69 Christoph Feck 2014-08-16 12:11:41 UTC
Is this really restricted to russian layout? It might actually be a change in X11 russian keyboard layouts.
Comment 70 Dmitry Veltishev 2014-08-18 09:42:11 UTC
(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?
Comment 71 Nick Stefanov 2014-08-18 11:38:40 UTC
Why not you try bulgarian layot to check it out?
Comment 72 Someone 2014-08-24 18:44:47 UTC
This is present in Plasma 5 (Plasmashell) though..
Comment 73 Dmitry Veltishev 2014-09-15 21:53:20 UTC
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
Comment 74 Dmitri Koulikoff 2014-10-05 20:28:04 UTC
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.
Comment 75 Igor Poboiko 2014-10-20 08:54:49 UTC
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!
Comment 76 Dmitri Koulikoff 2014-10-20 09:01:41 UTC
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
Comment 77 Sam Tuke 2014-11-04 11:19:43 UTC
(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
Comment 78 dklovedoctor 2015-03-11 14:49:39 UTC
Igor's Poboiko's exploit did the trick for me too. (Comment 75)
Comment 79 Knube2015 2015-04-05 11:41:27 UTC
Problem solves when you move Russian Keyboard Layout near the others.
Проблема решается, если переместить Русскую раскладку ниже Английской, в окне Клавиатура - Модуль настройки KDE.
Comment 80 Wolfgang Mader 2015-05-18 10:03:39 UTC
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
Comment 81 Denis Savenko 2015-07-10 01:13:37 UTC
(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.
Comment 82 Ilya V. Portnov 2015-07-10 15:20:38 UTC
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.
Comment 83 Wolfgang Mader 2015-07-10 19:24:57 UTC
(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
Comment 84 Stanislav 2015-07-13 11:41:12 UTC
+1 for reopening - the problem is not solved.
Comment 85 Halla Rempt 2015-08-12 13:24:17 UTC
*** Bug 350095 has been marked as a duplicate of this bug. ***