| Summary: | Alt-shortcuts dont work with secondary layout | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Helge Hielscher <hhielscher> |
| Component: | qt | Assignee: | David Faure <faure> |
| Status: | RESOLVED UNMAINTAINED | ||
| 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: | ||
| Sentry Crash Report: | |||
I can confirm this, but it would seem intentional. There might be a reason why there are no Alt+letter shortcuts on default KDE. 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. 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. I have the same problem on KDE 3.5 with SuSE 10.0 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. 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 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). 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. 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...] Gnome/Gtk uses secondary layout. You can easily test this with dvorak layout where e(dit) is on d and f(ile) on y. Right now in kate neither ctrl nor alt shortcut work in Russian layout. (Gnome Desktop with kate-4.5.68-1mdv2011.0) this may well be similar or even identical to BUG 274820 : https://bugs.kde.org/show_bug.cgi?id=274820 (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! 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. (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. 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 |
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)