Bug 154212 - Multiple keyboard layouts: Modifier keys behavioral option
Summary: Multiple keyboard layouts: Modifier keys behavioral option
Status: RESOLVED DUPLICATE of bug 350816
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Andriy Rysin
URL:
Keywords:
: 165543 273836 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-17 06:51 UTC by Drew Fisher
Modified: 2018-10-02 12:36 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Log of xev events when pressing key shortcuts (5.29 KB, text/plain)
2007-12-17 07:38 UTC, Matt Mullins
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Fisher 2007-12-17 06:51:39 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 4.1.3 20070929 
OS:                Linux

I use multiple keyboard layouts, specifically, US English, Dvorak, and left-handed Dvorak.  When I am using a layout other than the one at the top of the list in the Keyboard Layout systemsettings module, I obtain some unusual behavior from KDE apps.  Specifically, when I use modifier keys (Ctrl, Ctrl+Shift) to perform keyboard shortcuts, the keystroke is interpreted as though the active keyboard layout were the top one listed in systemsettings.

For instance, if I have QWERTY set as the default layout, then switch to dvorak by clicking the flag icon in the system tray, open up Konsole, and press Ctrl-Shift-(dvorak n), it is interpreted as Ctrl-Shift-(QWERTY l), since the two have the same physical key.  This means that instead of opening a new tab, Konsole splits-screen.  Interestingly, Konsole still handles Ctrl-(character) correctly.  I would guess this is because Konsole handles such keystrokes internally, as part of the vt102 emulator.

All KDE apps that I have tested have this behavior.  Another example: Konqueror will treat a Ctrl-(dvorak T) as a Ctrl-K, since the QWERTY K is the dvorak t.

I suspect this may be a QT4 bug, since this behavior is also present in wpa_gui (from wpa_supplicant), but is not exhibited in firefox or other X11 apps that do not use QT4.  I am using Kubuntu's shipped QT4 libraries (version 4.3.2-0ubuntu3.1).

Ideally, the KDE apps would recognize keystrokes with modifier keys as in the currently selected layout, rather than the default layout.
Comment 1 Matt Mullins 2007-12-17 07:37:31 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.
Comment 2 Matt Mullins 2007-12-17 07:38:56 UTC
Created attachment 22589 [details]
Log of xev events when pressing key shortcuts
Comment 3 Matt Mullins 2007-12-17 08:09:54 UTC
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.
Comment 4 Andriy Rysin 2008-04-13 05:53:05 UTC
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).
Comment 5 Dotan Cohen 2008-10-14 13:00:13 UTC
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
Comment 6 Jekyll Wu 2011-09-28 10:04:33 UTC
*** Bug 165543 has been marked as a duplicate of this bug. ***
Comment 7 Holger 2018-10-02 12:30:21 UTC
*** Bug 273836 has been marked as a duplicate of this bug. ***
Comment 8 Holger 2018-10-02 12:36:47 UTC

*** This bug has been marked as a duplicate of bug 350816 ***