[ANNOUNCE] libxkbcommon-0.4.1

[David Herrmann]

Hi

On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita <ran234 at gmail.com> wrote:
> - Added two new functions, xkb_state_key_get_utf{8,32}(). They
>   combine the operations of xkb_state_key_get_syms() and
>   xkb_keysym_to_utf{8,32}(), and provide a nicer interface for it
>   (espcially for multiple-keysyms-per-level).

Slightly off-topic, but looking at the code, you ignore any multi-sym
values (nsyms != 1). Users of that API might rely on that behavior, so
have we at some point defined what exactly multi-sym means? Because if
we add more and more APIs and if the user-base grows, we might at some
point be unable to make use of multi-symbol behavior. I'm still not
sure whether nsyms > 1 just means multiple sequential keysyms, or
whether they should be handled as _one_ atomic combined keysym?

> - The xkb_state_key_get_utf{8,32}() functions now apply Control
>   transformation: when the Control modifier is active, the string
>   is converted to an appropriate control character.
>   This matches the behavior of libX11's XLookupString(3), and
>   required by the XKB specification:
>   http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier
>
>   https://bugs.freedesktop.org/show_bug.cgi?id=75892

So xkb_state_key_get_utf8(state, code) !=
xkb_keysym_to_utf8(xkb_state_key_get_one_sym(state, code))? (at least
for ctrl+<char>)

Could we at least add a note/warning to the documentation? I cannot
find anything here:
http://xkbcommon.org/doc/current/group__state.html#ga0774b424063b45c88ec0354c77f9a247

For instance, for libtsm, I accept combined modifier+keysym+ucs4string
input from the GUI layer and transform that internally. If the upper
layer uses xkb_state_key_get_utf32() instead of xkb_keysym_to_utf32(),
the logic will force the control-seq even though it might be mapped
differently by the vte-layer (for instance, there's stuff like
shifting values by 64 if ALT is pressed, and more legacy crap we need
to support for eternity). Sure, most libtsm code uses the keysym, but
for glyph transformation we have to use the ucs4 value. Imagine the
ctrl+c input was shifted by the term-layer, you still end up with the
\003 glyph, because the ucs4 string was mapped by xkbcommon.

I'm not saying the patch is wrong, in fact, the layout-search logic is
actually what you wrote for kmscon and I appreciate that. I'm just
saying that it's a really subtle API difference that can introduce
weird bugs. Lets see how it works out, but if people start using
xkb_state_key_get_utf32(), I might send a patch adding an xkb-state
flag that disables this transformation. Or just force users to not use
it (which would be unfortunate).

Btw., same is true for the implicit caps-lock magic in
xkb_state_key_get_one_sym(). I'm now quite confused whether
xkb_state_key_get_syms() users have to do caps-lock handling
explicitly? Or is that done by keymaps?

Anyhow, thanks for the release!
David