Version: 1.2.1 (using KDE 3.1.1) Installed from: Gentoo Compiler: gcc version 3.2.2 OS: Linux (i686) release 2.4.20-ck4 When I type in english layout, kword recognises keybindings such as Ctrl-B (bold) alright, but when i switch to cyrillic it goess off typing cyrillic letters ([How to reproduce] e.g. Ctrl-B becomes an "
Subject: Re: New: kword does not recognise keybindings when keyboard layout is switched to cyrillic On Wednesday 26 March 2003 12:20, you wrote: > When I type in english layout, kword recognises keybindings such as Ctrl-B (bold) alright, but when i switch to cyrillic it goess off typing cyrillic letters ([How to reproduce] e.g. Ctrl-B becomes an "
> Does this problem happen with e.g. Ctrl+A too? Yep, it types "
Subject: Re: kword does not recognise keybindings when keyboard layout is switched to cyrillic Ok, so this is either a Qt bug or an X bug. > keycode 56 = b B Huh. This really makes me wonder where X gets the 'letter' from. Can you test in a non-Qt application? Say xedit or gedit?
You probably also tested the xmodmap command while your keyboard layout was the en_US one. I recommend testing it in cyrillic mode as well.
Cyrillic mode test: xev output (^b): $ xev KeyPress event, serial 22, synthetic NO, window 0x3a00001, root 0x3a, subw 0x0, time 9514696, (135,41), root:(139,597), state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x3a00001, root 0x3a, subw 0x0, time 9515316, (135,41), root:(139,597), state 0x14, keycode 56 (keysym 0x6c9, Cyrillic_i), same_screen YES, XLookupString gives 1 bytes: "
Subject: Re: kword does not recognise keybindings when keyboard layout is switched to cyrillic On Monday 31 March 2003 08:20, you wrote: > $ xmodmap -pke | grep 56 > keycode 56 = Cyrillic_i Cyrillic_I This still looks correct (only two items, not more). > But, umm, how do I enable proper xmodmap keybindings without (too much/too ugly) > kxkb/xmodmap haxory? kxkb loads the keybindings, xmodmap is merely a way to query them. Did you test non-Qt applications as I suggested? I need to know if I should report this as a Qt bug, or if it's an X problem.
[I hope Konqueror is pasting this in UTF-8] I have done the tests myself and I can trigger the exact same problem as described. I've run `setxkbmap ru' and run xev: I got the same results. Here are several results in different programs: - In kedit hitting Ctrl+B in my normal keyboard (us_intl+inet(acpi)) makes the cursor go to the left. With the ru keymap, и gets inserted. - In Emacs (X11) or xedit, cyrillic input simply doesn't work. If I try from an UTF-8 environment, both insert weird non-related characters instead of going to the right. - In XEmacs, it barks "C-Cyrillic_i is not defined" - In Gnomemeeting (hey, it's the only GNOME app I have), it inserts the same symbol as hitting и. Environment: KDE HEAD 20030312, Emacs 21.2, XEmacs 21.4.12, xedit from XFree86 4.3.0. In all cases LANG=pt_BR or LANG=pt_BR.UTF-8. I'm sorry, but I don't see a way out. When you do Ctrl+B in a Cyrillic keymap, the system interprets it as a Ctrl+и instead, when it interprets at all. A possible solution would be to detect when non-latin symbols are being used along with modifier keys and then interpret not the symbol, but the keycode. One must also have in mind there that there are keyboard mappings like AZERTY and QWERTZ which change positions of the latin letters as well.
This is an X 4.3.0 problem it seems, can anyone confirm this is not the case with X 4.2.0?
*** Bug 57857 has been marked as a duplicate of this bug. ***
This is due to one-group layouts introduced in XFree86 4.3 If your layout in not in $oldlayouts or $nonlatin in rules/xfree86 file then it not longer includes "us" group by defaul, thus it does not generate latin symbols any more. This should be fixed somewhere deep in Qt/KDE, but I don't see easy way out. The only this one can help himself is putting his layout into $oldlayouts or $nonlatin lists in rules/xfree86, in first case old symbols/<layout> file will be used, in second case will be taken new one-group layout from symbols/pc/<layout> but "us" group will be added to it, so there'll be chance to use old hotkeys.
> This is due to one-group layouts introduced in XFree86 4.3 thanks for the info! hope someone will dig it up. i'll try and test it in the evening...
ok, this issue is addessed in CVS, in layout configuration you can enable 'Include latin layout' option and latin shortcuts should start working back event in your non-latin layout. As in old good XFree 4.2 :) I need some testing on this, please try it and send me comments.
*** Bug 69458 has been marked as a duplicate of this bug. ***