<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 27 March 2014 22:41, Ran Benita <span dir="ltr"><<a href="mailto:ran234@gmail.com" target="_blank">ran234@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Mar 27, 2014 at 09:04:07PM +0100, David Herrmann wrote:<br><div class="">> On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita <<a href="mailto:ran234@gmail.com">ran234@gmail.com</a>> wrote:<br>
> > - Added two new functions, xkb_state_key_get_utf{8,32}(). They<br>
> > combine the operations of xkb_state_key_get_syms() and<br>
> > xkb_keysym_to_utf{8,32}(), and provide a nicer interface for it<br>
> > (espcially for multiple-keysyms-per-level).<br>
><br>
> Slightly off-topic, but looking at the code, you ignore any multi-sym<br>
> values (nsyms != 1). Users of that API might rely on that behavior, so<br>
> have we at some point defined what exactly multi-sym means? Because if<br>
> we add more and more APIs and if the user-base grows, we might at some<br>
> point be unable to make use of multi-symbol behavior. I'm still not<br>
> sure whether nsyms > 1 just means multiple sequential keysyms, or<br>
> whether they should be handled as _one_ atomic combined keysym?<br>
<br>
</div>First, the reason I added these functions is that<br>
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=75892" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=75892</a> made it necessary, I<br>
would otherwise like to avoid adding new API at this point. But given<br>
the situation, I tried to make the best of it.<br>
<br>
I only ignore multiple-keysyms for the utf32 function -- I only added<br>
it to match the existing xkb_keysym_to_utf32() function. I don't think<br>
it makes sense to encode multiple-keysyms into a UTF-32 string, nobody<br>
uses it. A better name would be xkb_keysym_to_unicode_codepoint() or<br>
whatever, but I wanted to keep the existing name.<br>
<br>
For the utf8 function, it is handled correctly, and is actually much<br>
easier to use for multiple-keysyms than the old function. It builds the<br>
string internally and finally ensures it's valid UTF-8.<br>
<br>
Another advantage of adding new functions is that existing users don't<br>
break due to the new behavior, they must opt-in.<br>
<br>
Regarding intended use-case for multiple-keysyms, I consider it mainly<br>
to be for sequences with combining characters - not everything has<br>
precomposed codepoints, so if you want one of these, you don't have a<br>
way to do it with single-keysym, but it still conceptually fits in a<br>
keymap. However for the original intent you have to ask Daniel.</blockquote><div><br></div><div>Yes, it is supposed to be atomic: the usecase was for keymaps (there was one from central Asia - can't remember off the top of my head), where Unicode no longer adds precomposed characters, so some key presses need to generate multiple symbols which should be processed all at once.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> I'm not saying the patch is wrong, in fact, the layout-search logic is<br></div><div class="">
> actually what you wrote for kmscon and I appreciate that. I'm just<br>
> saying that it's a really subtle API difference that can introduce<br>
> weird bugs. Lets see how it works out, but if people start using<br>
> xkb_state_key_get_utf32(), I might send a patch adding an xkb-state<br>
> flag that disables this transformation. Or just force users to not use<br>
> it (which would be unfortunate).<br>
<br>
</div>A flag makes sense; I try to to add stuff when someone really needs it,<br>
not preemptively. Btw, xkb_state_new() doesn't take a flags arg - argh.<br></blockquote><div><br></div><div>Yeah, I'm now regretting not adding that flag param! One for 1.0 perhaps ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But in general this stuff should be the default, we initially tried to<br>
avoid these nonsensical US-centric behavior (let's say intentionally :),<br>
but both the keymaps and existing users actually depend on them, like<br>
the capitalization and Control thing (and they are also there in the<br>
spec).</blockquote><div><br></div><div>Indeed - there've been quite a few people surprised by this, who were expecting the Xlib-style behaviour.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> Btw., same is true for the implicit caps-lock magic in<br>
> xkb_state_key_get_one_sym(). I'm now quite confused whether<br>
> xkb_state_key_get_syms() users have to do caps-lock handling<br>
> explicitly? Or is that done by keymaps?<br>
<br>
</div>Currently to get the implicit capitalization with get_syms(), you have<br>
to do this:<br>
<br>
int nsyms;<br>
const xkb_keysym_t *syms;<br>
xkb_keysym_t sym;<br>
<br>
nsyms = xkb_state_key_get_syms(..., &syms);<br>
if (nsyms == 1) {<br>
sym = xkb_state_key_get_one_sym(...);<br>
syms = &sym;<br>
}<br>
<br>
I imagine the disgust, but given the set of constraints we had I<br>
couldn't think of any way to make this work. New API is still possible,<br>
but then we'd have *three* ways to get keysyms...<br>
<br>
As I may have mentioned, I wanted to change the *keymaps* so the<br>
difference doesn't matter here. I still plan to send some patches for<br>
easy cases, but fixing other cases would require major xkeyboard-config<br>
surgery. So we're stuck with it.</blockquote><div><br></div><div>It's indeed really unpleasant, and definitely the worst corner of our API right now. FWIW, the reason this evolved this way is because xkb_state_key_get_syms returns a pointer which will remain valid and pointing to the same symbols for the life of the state object. Having to do mapping on the fly obviously blows that out of the water, unless we allocate an area for composed symbols and retain that; except that it's not an area, because if you have to grow, it's multiple areas.</div>
<div><br></div><div>Which would be painful and irritating, but I think serves the greater good of harmonising the API and eliminating one of the very few sources of genuine surprise.</div><div><br></div><div>Cheers,</div>
<div>Daniel </div></div></div></div>