Does the proposed input methods support clients being able to show
intermediate results? This is certainly useful to make "dead keys" less
"dead", and I am under the impression that it is very useful for some
Asian entry systems.
X11 tried to do this with an input-method-controlled overlay, but this
was incredibly complex and messy and did not really work. I think
however that the clients can draw this, and often it will be trivial to
support it.
Assuming there is an input method doing compose-key, here is what I
would expect to happen if the user types compose,a,e to make æ:
1. User presses & releases compose key.
2. User types 'a'. Input method then sends 'a' to the client. Client
inserts it into the text as though the user typed it, but remembers it
came from the input method. This gives the user a preview of what they
typed, which I have found to be much better than normal "dead key" behavior.
3. User types 'e'. Input method sends a message to replace the previous
input with 'æ'. The client then deletes the 'a' and inserts the 'æ'.
If at step 3 the user typed 'x' (and assuming ax is not a compose
sequence) the input method could then choose how to handle the error:
1. Input method says to also insert an 'x', resulting in "ax" (my
preference).
2. Input method says to replace the previous input with 'x'.
3. Input method says to replace the previous input with nothing
(matching what X11 compose key does).
Is there anything like this in wayland's input method design?
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
