71147 2003-12-23 22:18:14 +0000 Alt-shortcuts dont work with secondary layout 2024-09-14 17:06:38 +0000 1 1 10 Unmaintained kdelibs qt unspecified Mandrake RPMs Linux RESOLVED UNMAINTAINED NOR normal --- 1 hhielscher faure cfeck faure fredrik glad08 kde-2011.08 kirill.bogdanenko l.lunak wolfgang.brehm 86 oldest_to_newest 188673 0 hhielscher 2003-12-23 22:18:14 +0000 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) 188676 1 thiago 2003-12-23 22:30:20 +0000 I can confirm this, but it would seem intentional. There might be a reason why there are no Alt+letter shortcuts on default KDE. 188733 2 hhielscher 2003-12-24 05:33:26 +0000 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. 248735 3 sibskull 2004-07-14 17:53:26 +0000 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. 514811 4 avatar 2007-03-13 09:35:28 +0000 I have the same problem on KDE 3.5 with SuSE 10.0 514869 5 kde-2011.08 2007-03-13 14:46:04 +0000 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. 514875 6 avatar 2007-03-13 15:27:10 +0000 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 694404 7 hhielscher 2009-01-05 11:11:28 +0000 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). 746699 8 kde-2011.08 2009-04-24 15:29:03 +0000 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. 1031259 9 faure 2010-10-13 02:47:55 +0000 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...] 1031275 10 hhielscher 2010-10-13 03:41:17 +0000 Gnome/Gtk uses secondary layout. You can easily test this with dvorak layout where e(dit) is on d and f(ile) on y. 1031281 11 hhielscher 2010-10-13 03:51:43 +0000 Right now in kate neither ctrl nor alt shortcut work in Russian layout. (Gnome Desktop with kate-4.5.68-1mdv2011.0) 1366802 12 wolfgang.brehm 2013-05-06 21:22:30 +0000 this may well be similar or even identical to BUG 274820 : https://bugs.kde.org/show_bug.cgi?id=274820 1382948 13 a 2013-07-12 10:05:27 +0000 (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! 1382960 14 cfeck 2013-07-12 11:17:38 +0000 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. 1382968 15 a 2013-07-12 11:43:16 +0000 (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. 2354232 16 christoph 2024-09-14 17:06:38 +0000 Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann