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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
