Bug 71147

Summary: Alt-shortcuts dont work with secondary layout
Product: [Frameworks and Libraries] kdelibs Reporter: Helge Hielscher <hhielscher>
Component: qtAssignee: David Faure <faure>
Status: CONFIRMED ---    
Severity: normal CC: cfeck, faure, fredrik, glad08, kde-2011.08, kirill.bogdanenko, l.lunak, wolfgang.brehm
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Mandrake RPMs   
OS: Linux   
Latest Commit: Version Fixed In:

Description Helge Hielscher 2003-12-23 22:18:14 UTC
Version:            (using KDE KDE 3.1.94)
Installed from:    Mandrake RPMs
OS:          Linux

Reproducible: Always

Steps to Reproduce:
1. set your keyboard to ru/us ("e.g. setxkbmap -model pc102 -layout ru,us
-variant ,basic")
2. try to use a shortcut (e.g. Alt+E) in kwrite or konqueror (locale:en_US)

Actual Results:  
only Ctrl-shortcuts (e.g. Ctrl-F) do work

Expected Results:  
shortcuts should work like in other applications (e.g. gedit)
Comment 1 Thiago Macieira 2003-12-23 22:30:20 UTC
I can confirm this, but it would seem intentional. There might be a reason why there are no Alt+letter shortcuts on default KDE.
Comment 2 Helge Hielscher 2003-12-24 05:33:26 UTC
Well, there are Alt-Shortcuts in KDE. E.g. Alt-E opens the edit menu.
This bug is about using a keyboard layout without latin keys but using latin locale and thus latin shortcuts, not about shortcuts in general.
Comment 3 Andrey Cherepanov 2004-07-14 17:53:26 UTC
I use 'ru' layout and cannot activate menu item with cyrillic letter via accel key too. On other hand GTK+ 2.x applications work correct with cyrillic accelerators.
Comment 4 Misha Aizatulin 2007-03-13 09:35:28 UTC
I have the same problem on KDE 3.5 with SuSE 10.0
Comment 5 Dotan Cohen 2007-03-13 14:46:04 UTC
On my Hebrew/English KDE installation the shortcuts work only in English. So CTRL-V pastes, but CTRL-ה (the letter ה on the same key as V) does not. However, in Gnome CTRL-ה pastes just like it should. It is a pain to switch to English each time I must perform a keyboard shortcut.

KDE 3.5.6 on FC6 on a Dell Inspiron lappy.
Comment 6 Misha Aizatulin 2007-03-13 15:27:10 UTC
Ctrl-shortcuts work for Russian in my KDE 3.5. In order for them to work you probably have to include latin as second layout, this is my config:
setxkbmap -model pc105 -layout us,ru -variant ,winkeys
Comment 7 Helge Hielscher 2009-01-05 11:11:28 UTC
In KDE4 Alt-Shortcuts work only on the first level. That means Alt-E open the Edit Menu, but any further key is ignored (cursor keys work though).
Comment 8 Dotan Cohen 2009-04-24 15:29:03 UTC
In KDE 4.2 with the Israeli keyboard layout and the config "setxkbmap -model pc104 -layout us,il -variant ,lyx", I can use keyboard shortcuts (while in Hebrew) for Ctrl-Z,X,C,V,A and so forth, but I cannot open Main Menu items. The main menu items are in Hebrew, for instance File is קובץ and the leading letter is underlined, however, Alt-ק does not open the menu item.
Comment 9 David Faure 2010-10-13 02:47:55 UTC
KDE-4.5 + Qt-4.6: I can reproduce the initial report: Alt+E doesn't work in russian layout. Comment #7 surprises me, then.

This looks very much like a Qt bug/issue, but anyway, let's have a look.

With a US layout, Alt+E opens the menu via QShortcutMap::tryShortcutEvent(), which calls (via nextState), the method QShortcutMap::find(). In the loop, entry.keyseq[0] is 0x8000045, entry.keyseq.toString(0) says "Alt+E", and so does (*it).keyseq.toString(0) ==> match.

With a RU layout, entry.keyseq.toString(0) says "Alt+" [probably a non-printable letter in my terminal], and the qLowerBound doesn't find anything. entry.keyseq[0] is 0x8000423. Well, from a technical point of view, it makes perfect sense, the pressed key was not 'E', but Cyrillic_u (keysym 0x6d5; ev->key() is 0x423). (Seen in `xev`, or in QKeyMapperPrivate::translateKeyEvent). The keycode is always 26, but that's too much of a physical information. When my wife switches my qwerty keyboard to french azerty, surely she wants Ctrl+A to be where the A is on a french layout, not where the Q is on a french layout... Anyway I guess the way other toolkits solve this is by only falling back to looking at the physical key if the layout-dependent keysym didn't match anything?
Or do they use the secondary keyboard layout as fallback, rather than hardcoding "US"? Please investigate the competition a little bit, so we can find out what to do exactly :-)
Check if Alt+A still works in "ru,fr" mode, where the key labelled "A" would only map to Cyrillic_ef or 'Q', if looking at the configured keyboard layouts. If it still works then "US" is hardcoded.

[Note to myself: we can get the keycode and virtual key even in QShortcutMap::find() because the QKeyEvent is in fact a QKeyEventEx with additional fields.]
[No clue how to ask for a lookup in another keyboard layout than the default one, though... XLookupString doesn't do that... CC'ing some X experts...]
Comment 10 Helge Hielscher 2010-10-13 03:41:17 UTC
Gnome/Gtk uses secondary layout. You can easily test this with dvorak layout where e(dit) is on d and f(ile) on y.
Comment 11 Helge Hielscher 2010-10-13 03:51:43 UTC
Right now in kate neither ctrl nor alt shortcut work in Russian layout.
(Gnome Desktop with kate-4.5.68-1mdv2011.0)
Comment 12 Wolfgang Brehm 2013-05-06 21:22:30 UTC
this may well be similar or even identical to BUG 274820 : https://bugs.kde.org/show_bug.cgi?id=274820
Comment 13 Andrew Gaydenko 2013-07-12 10:05:27 UTC
(In reply to comment #11)
> Right now in kate neither ctrl nor alt shortcut work in Russian layout.
> (Gnome Desktop with kate-4.5.68-1mdv2011.0)

Confirming - and not in kate only but KDE overall, say in konqueror also. Very annoying. In fact this is a reason I'm evaluating another environments being on KDE > 10 years. Can we rise importance by votes? Thanks!
Comment 14 Christoph Feck 2013-07-12 11:17:38 UTC
Andrew, this bug is 10 years old. Do you get the Ctrl+ not working since 10 years? What you see is probably bug 320423.

Please find out what you did update to get the bug by trying previous versions. Relevant are Qt and anything with an X in it. It could also depend on input method extensions installed by the distributions.
Comment 15 Andrew Gaydenko 2013-07-12 11:43:16 UTC
(In reply to comment #14)
> Andrew, this bug is 10 years old. Do you get the Ctrl+ not working since 10
> years? What you see is probably bug 320423.

I have met the problem some days ago and at the moment can not determine that updated package causing an issue.

Thanks for the ref to recent similar but, I'll go there.