... which was trying to fix a rarely occurring situation where system
settings from a desktop environment does not set any latin keymap on
X. This is a DE bug and it has a simple workaround (details in the patch).
Ubuntu has fixed this issue sometime between 12.10 -> 14.04. Gnome 3
always appends 'us' layout, even if you have only e.g. 'gr' listed in
keyboard layouts (can be checked via setxkbmap -query). In KDE, the
global system shorcuts seem to stop working as soon as latin keymap
is not the first in the list, which means that KDE users won't be
affected as they will likely always have a latin keymap present in
the list.
This patch removes parts of 2b666d9576,
the parts that in the commit message I was referring to by this quote:
"lookupLatinKeysym() also handles the cases that did not work in Qt4
with XLookupString".
Since finding a latin key is not working by XLookupString() in this
rare case, then it would not work pretty much across the whole desktop.
And users would be more interested at finding a solution that works
across the desktop. We should not workaround this issue. Desktops that
are doing it wrong should learn about this and not repeat the same mistakes
on Wayland systems, where XKB keymap is assembled by compositor and passed
to clients. Clients should work with the provided keymap as is.
The missing-latin-keymap workaround is considered fragile for several
reasons - it might not work with legacy or enterprise X server key codes
and it relies on global _XKB_RULES_NAMES (there might be several connected
keyboards). And theoretical limitation: client might be running in a
restricted environment where we don't have access to keymaps on the
file system.
Change-Id: Ib445b2ea46174248cfa0e5da0eb642cd2a5cf2f6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
1aec1a2d8d