Questions and thoughts about input method protocol

[Bill Spitzak]

On 02/03/2013 05:14 AM, Yichao Yu wrote:

>> I suspect because preedit was a pain to support under X it was never tried.
>
> Not at all, especially if you are using im-module or if you don't need
> cursor following. Yes, preedit can be used in some input method/layout
> but other features that I mentioned are rarely used in non-CJK input
> method.
>
>> I hope wayland makes this easy enough that we can get this behavior: 1. you
>> type the compose key, and the cursor changes because a zero-length preedit
>> was sent, so you have visual feedback. Then you type an 'a' and you see an
>> a, perhaps highlighted as preedit. Then you type an 'e' and you see the
>> committed æ. Furthermore if you type 'j' you will in fact commit the 'a' and
>> see 'aj' which is a lot more useful.
>
> That should be just a feature / bug / option of the input method. And
> you should just report a issue to the input method you are using (or
> you can try fcitx and tell us what's the missing feature of
> fcitx-keyboard.)

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.

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.

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.