Questions and thoughts about input method protocol

[Daniel Stone]

On 4 February 2013 17:59, Bill Spitzak <spitzak at gmail.com> wrote:

> 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).
>
> 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.
>

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.


> 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.
>

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.


> 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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130205/3124e636/attachment.html>