summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatthias Clasen <mclasen@redhat.com>2012-09-09 18:49:18 -0400
committerMatthias Clasen <mclasen@redhat.com>2012-09-09 18:49:18 -0400
commit1533e67ae40d938a6ee805eab5581922f4b97459 (patch)
treebe834872efbd68ce03e1b2ec5a95e5cd68206bfb
parentb4ddf24234ccc26647bce8808e9824f268d597b8 (diff)
downloadgtk+-1533e67ae40d938a6ee805eab5581922f4b97459.tar.gz
Try harder to discriminate Shift-F10 and F10
A change in xkeyboard-config 2.4.1 made it so that function keys now have a shift level which has the same symbol, but 'eats' the shift modifier. This would ordinarily make it impossible for us to discriminate between these key combinations. This commit tries harder to discriminate in 2 ways: - XKB has a mechanism to tell us when a modifier should not be consumed even though it was used in determining the level. We now respect such 'preserved' modifiers. This does not fix the Shift-F10 vs F10 problem yet, since xkeyboard-config does not currently mark Shift as preserved for function keys. - Don't consume modifiers that do not change the symbol. For the function keys, the symbol on the shift level is the same as the base level, so we don't consider Shift consumed. For more background on the xkeyboard-config change, see https://bugs.freedesktop.org/show_bug.cgi?id=45008 https://bugzilla.gnome.org/show_bug.cgi?id=661973
-rw-r--r--gdk/x11/gdkkeys-x11.c27
1 files changed, 18 insertions, 9 deletions
diff --git a/gdk/x11/gdkkeys-x11.c b/gdk/x11/gdkkeys-x11.c
index 0a20605da2..75fc68f07c 100644
--- a/gdk/x11/gdkkeys-x11.c
+++ b/gdk/x11/gdkkeys-x11.c
@@ -1263,6 +1263,8 @@ MyEnhancedXkbTranslateKeyCode(register XkbDescPtr xkb,
int found = 0;
for (i=0,entry=type->map;i<type->map_count;i++,entry++) {
+ if (!entry->active || syms[col+entry->level] == syms[col])
+ continue;
if (mods_rtrn) {
int bits = 0;
unsigned long tmp = entry->mods.mask;
@@ -1271,23 +1273,30 @@ MyEnhancedXkbTranslateKeyCode(register XkbDescPtr xkb,
bits++;
tmp >>= 1;
}
- /* We always add one-modifiers levels to mods_rtrn since
- * they can't wipe out bits in the state unless the
- * level would be triggered. But return other modifiers
- *
- */
+ /* We always add one-modifiers levels to mods_rtrn since
+ * they can't wipe out bits in the state unless the
+ * level would be triggered. But not if they don't change
+ * the symbol (otherwise we can't discriminate Shift-F10
+ * and F10 anymore). And don't add modifiers that are
+ * explicitly marked as preserved, either.
+ */
if (bits == 1 || (mods&type->mods.mask)==entry->mods.mask)
- *mods_rtrn |= entry->mods.mask;
+ {
+ if (type->preserve)
+ *mods_rtrn |= (entry->mods.mask & ~type->preserve[i].mask);
+ else
+ *mods_rtrn |= entry->mods.mask;
+ }
}
-
- if (!found&&entry->active&&((mods&type->mods.mask)==entry->mods.mask)) {
+
+ if (!found && ((mods&type->mods.mask) == entry->mods.mask)) {
col+= entry->level;
if (type->preserve)
preserve= type->preserve[i].mask;
if (level_rtrn)
*level_rtrn = entry->level;
-
+
found = 1;
}
}