[Wayland-bugs] [Bug 754110] inconsistent interpretation of preserved modifiers with xkbcommon

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=754110

--- Comment #30 from Ran Benita <ran234 at gmail.com> ---
If we go the libxkbcommon route, I'd suggest the following:

Add new xkb_state_key_get_consumed_mods2 which takes a `enum xkb_consume_mode`
parameter. One mode would be `XKB_CONSUME_MODE_XKB` (existing behavior), then
we can add `XKB_CONSUME_MODE_DANIEL` for your suggested behavior (name is
debatable :), maybe `XKB_CONSUME_MODE_GTK` for current GTK behavior, and more
if (when) people complain. The existing function is same as calling 2 with
`XKB_CONSUME_MODE_XKB`, for backward compatibility. The other existing
functions `xkb_state_mod_index_is_consumed`,
`xkb_state_mod_mask_remove_consumed` can be deprecated without replacement as
far as I'm concerned.

Even though doing this while still working transparently with older
libxkbcommon is nice, I don't like the suggestion to add a flag to the context
for this - doesn't make sense there. And maybe you want to pass the xkb_state
to some other code which wants a different mode? So users of new API would need
to add the appropriate >= or autoconf stuff as usual.

I prefer mode to flags, because I think that if we ever add more than one flag
they will probably not compose anyway. And a "mode" is easier to talk about.

What do you think? Once we have some code which implements the new "modes" we
can see how they work out in practice.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20160121/9168b012/attachment.html>