Summary: | Multiple keyboard layouts: Modifier keys behavioral option | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Drew Fisher <drew.m.fisher> |
Component: | general | Assignee: | Andriy Rysin <arysin> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | bluedzins, h.klene, karl.may0, kde-2011.08, lippert.tobias, mmullins, randall.leeds, wolfgang.brehm |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Log of xev events when pressing key shortcuts |
Description
Drew Fisher
2007-12-17 06:51:39 UTC
I also use Dvorak mainly and QWERTY occasionally. I tried this out, and I found that running "setxkbmap us" switches the layouts appropriately. That is, after running "setxkbmap us", in Konsole, Control-Shift-(dvorak)N opens a new tab; if I use the kde applet to switch layouts, it sends the Control-Shift-N keycode to the application running in the konsole. I ran xev, and I attached what it printed (I pressed the same (physical) key for both: Control-Shift-(Dvorak)N / Control-Shift-(QWERTY)L ). Note it's not a direct copy of xev's output; there are some comments added by me in there. I ran "setxkbmap -print" before and after switching keyboard layouts: # before switching - still in us/dvorak layout xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc(pc105)+us(dvorak)+us:2" }; xkb_geometry { include "pc(pc104)" }; }; # after switching to US using kxkb xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc(pc105)+us(dvorak)+us:2" }; xkb_geometry { include "pc(pc104)" }; }; # after switching to US using setxkbmap xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc(pc105)+us" }; xkb_geometry { include "pc(pc104)" }; }; Steps to reproduce: 1) Go to System Settings -> Regional -> Keyboard layout. 2) Add a different keyboard layout to your list 3) Switch layouts using the flag icon in the panel 4) Use keyboard shortcuts in Qt and KDE applications Workaround: Use "setxkbmap" manually to switch keyboard layouts. Created attachment 22589 [details]
Log of xev events when pressing key shortcuts
I just noticed that Qt applications behave the same way as described above while in a Gnome environment using the Gnome keyboard switcher. This baffles me. I don't quite personally understand how xkb works with multiple layouts defined simultaneously. It seems that Qt tries to find shortcut key in current group first and then goes inactive ones. While GTK apps always start searching with group 0. It means that if you define your layout as setxkbmap -layout us,us -variant ,dvorak -option grp:ctrl_shift_toggle when group 2 (dvorak) is active in Qt it will drive the shortcuts while in GTK the default group (us) will be used instead. I am switching this to kdelibs as it's not a switcher problem (and I'd say it's more gtk problem rather than Qt's). This actually sounds more like a feature than a bug! Many keyboard shortcuts were chosen not because of the meaning of the letter, but because of their position on the keyboard (Ctrl- Z X C V come to mind). I stopped using Dvorak because it was important to me to keep my keyboard shortcuts consistent across systems (not on every computer that I use can I configure Dvorak, like at the library). Also, users of multiple keyboard layouts (English and Hebrew or Russian, for instance) may want consistent keyboard shortcuts across layouts. I propose that this feature/bug be optional. There are a lot of people who are demanding this feature in Mozilla, for instance: https://bugzilla.mozilla.org/show_bug.cgi?id=69230 *** Bug 165543 has been marked as a duplicate of this bug. *** *** Bug 273836 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 350816 *** |