Input method and input/output redirect under wayland

[Yichao Yu]

On Thu, Aug 30, 2012 at 2:16 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>
>
> Michael Hasselmann wrote:
>
>>> For some input method (especially for CJK), it is important to have
>>> some user interaction before some text is finally committed (e.g.
>>> there might be more than one candidate words for a single input
>>> string), and for better user experience, it is important to show this
>>> window (for user interaction) closed to the cursor and in a way
>>> consistent with the input window.
>>
>>
>> Yes, pre-edit support. Work in progress.
>
>
> I think he is asking for the ability of the input method to draw an
> arbitrary overlay, for instance a popup menu of possible completions.
Yep, that is what i mean.

>
> If it is truly arbitrary then the input method will have to draw it. But
> then it is going to need full information about the position of the cursor
> and the selected text, what the transformation is, what the font is, and
> probably a lot more stuff I can't imagine yet. It would be excessively
> complicated.
Yes it is *truly arbitrary*. And in fact, it need to be updated by
input method at any time (for the case when we use the internet to
provide a better result.) AFAIK, font is not really a problem (it's
better to have consistent font for this overlay window actually) but
yes, full information of the transformation.


>
> Can it instead be limited to a list of pre-edit texts? Then it can be drawn
> by the client, which would be able to reuse it's own popup menu code, and
> blend perfectly into the text display by using the right font and
> transformation. As I imagine it:
>
> 1. The input method sends the client a list of preedit texts, plus an
> indicator of which one is "current". The client then must present this list
> and provide an api so the user can choose one with the pointer.
>
> 2. Input method can, in response to any event, change the list or dismiss
> it. The input method may use text keystrokes to change the selected item
> (for instance if the user types the first letter of one it is the input
> method that moves to that one). This is because the selection text may not
> be determinable from the preedit text.
>
> 3. Client can use pointer events and non-text keystrokes that the input
> method ignores to choose an item. It can then send an event to the input
> method indicating which one was chosen or that the user dismissed the menu.
>
> I believe this will result in much cleaner and correct display of these
> menus. The problem is that the display is going to be limited to simple
> lists of text. Is this ok?

Not really, u might what to have a button to switch pages, select
word, and show some extra information (e.g. current state of the input
method) etc. It's true that all these can be done by the client but
the protocol need to be really complicated and it can unnecessarily
mess up the client's main loop.

And it is also VERY hard to have a consistent experience. (layout,
orientation, location of buttons..... can all be different, which can
really confuse people afaik).