<div dir="ltr">On 4 February 2013 17:59, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">I think what happened is that because writing an input method was not easy and required huge amounts of support code that was not needed to support simple compose or pick-character-by-number operations, these were instead implemented in X using the keyboard api, which had the problem that it had *no* concept of preedit and an assumption that users only typed correct sequences (so the idea of "if they type these two letters, act as though they were not composed" could not be implemented except by a table of every possible pair).</span><br>
</div>
<br>
I would guess the XIM design could support this, but that the fact that any compose-key support would be 90% boiler-plate to implement unused parts of the Asian api and only about 10% actual compose-key probably is what drove the current design of considering it part of the keyboard api.<br>
</blockquote><div><br></div><div style>What? Compose keys in X can only be implemented through input methods.  GTK+ does it using its own internal input method (which is more than capable of doing pre-edit, what with it being part of core GTK+ and all), but xterm and all the other core apps just do it through the default XIM.  There is no 'keyboard api' with composition, full stop.  It's all input method.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It would be really nice if Wayland input methods were designed so that compose key apis were done with this instead of somehow defining the keyboard. The keyboard api should be limited to producing keysyms based on the current set of keys held down, and not handle sequences at all. I think this will require that they be fairly easy to write, and that we have an example compose-key input method from day 1 so nobody is tempted to put it into the keyboard.<br>
</blockquote><div><br></div><div style>Oh, for the love of god - this is what already happens.  wl_keyboard (go have a look at it some day) gives clients the keysyms resulting from pressing one keycode at a time.  There's no composition or filtering, we just pass it all down to the client, and leave composition up to the input methods.  This is why weston-terminal (go try it some day) doesn't support compose keys.  It would've taken all of five seconds to try, and would've handily shown you that pretty much every single sentence in this mail was wrong and/or based on fiction.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another advantage is that if compose keys were done by the input method using preedit, it makes it vastly more likely that programs will actually talk to the input method correctly, even if the programmers do not know or test any Asian languages. This is certainly a problem with current X and Windows applications, as I assume you are aware.</blockquote>
<div><br></div><div style>Another 'if only this were true' that is actually both true and based on a totally invalid premise.  I know it hasn't worked in the last several threads you've been involved in, but I'm going to join the chorus of people asking you to please have the decency to actually read up on things before you start attempting to design replacements for the failures they don't have.  It's getting ridiculous now: at best it's a total waste of everyone's time, and at worst you're hugely misleading a whole bunch of people.</div>
</div></div></div>