<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - inconsistent interpretation of preserved modifiers with xkbcommon"
href="https://bugzilla.gnome.org/show_bug.cgi?id=754110#c27">Comment # 27</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - inconsistent interpretation of preserved modifiers with xkbcommon"
href="https://bugzilla.gnome.org/show_bug.cgi?id=754110">bug 754110</a>
from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> <span class="fn">Carlos Garnacho</span></a>
</span></b>
<pre>The bit counting (and why I think Daniel things it's not such a general fix)
was added because I'm not sure what's best to do if there's more than one
modifier pressed in the mask, I see 2 plausible options:
- Checking all the combinations of the enabled bits, because a subset of those
might be triggering a different keysym.
- Checking only "all bits enabled" vs "all bits disabled", that might be enough
to let us know whether the current combination of modifiers was actually
consumed, but I don't know how widely this assumption applies.
So I added the 1bit-only check as both options collapse together in that case,
and it coincides with the cases we most usually see in GTK+ clients, where
two-modifiers keybindings are not that common, and definitely not with keys in
the CTRL+ALT group anyway, it is worth noting that keys in other groups (eg.
"ALPHABETIC") will still work fine because libxkbcommon and GTK+ seem to agree
on what the consumed modifiers are.
Anyway, I'll be happy if a better way to handle this is devised, any "we
sometimes don't fully trust xkbcommon" change will come across as specific.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>