Questions and thoughts about input method protocol

Yichao Yu yyc1992 at gmail.com
Fri Feb 1 11:53:28 PST 2013


On Fri, Feb 1, 2013 at 1:48 PM, Pekka Vuorela <pvuorela at iki.fi> wrote:
> On 01.02.2013 00:45, Yichao Yu wrote:
>>
>> On Thu, Jan 31, 2013 at 5:19 PM, Pekka Vuorela <pvuorela at iki.fi> wrote:
>>>
>>> On 31.01.2013 02:54, Yichao Yu wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On Wed, Jan 30, 2013 at 4:09 PM, Pekka Vuorela <pvuorela at iki.fi> wrote:
>
>
>>> I was talking about input method _automatically_ changing to one layout
>>> or
>>> another based on what was used in a specific text editor previously.
>>>
>>> In more detail: I have an application MyChat and I activate there a
>>> conversation text field with you. Wayland input method gets activation
>>> and a
>>> call like set_context("MyChat-Yichao_Yu"), it remembers that I use to
>>> speak
>>> Chinese with you so it enables pinyin automatically.
>>>
>>> Or with a browser, set_context("MyBrowser-www.example.com"), input method
>>> changes prediction to prioritize words I normally use at www.example.com.
>>> That's the same information as in window title, but not using concepts
>>> from
>>> the wrong level. Maybe even the toolkit integration could try to help and
>>> set context as default to executable name or something if application
>>> doesn't override it.
>>
>>
>> That is not the solution and that is far from what a working Chinese
>> input method need in another way. The right way is to let the input
>> method track every input_method_context and store any state
>> internally, as how it is done in any existing input method system.
>
>
> And exactly what I was saying. Input method keeping the state it needs
> internally. Above is only a hint for context.
>

If I understand what you mean is the request/event added is a way to
make im-client and input method collaborate better by sharing some
basic info (like language in use). However, the problem we are having
is it is impossible to keep track of the same input context whenever a
im-client lost focus with the current protocol, therefore, the input
method cannot keep a internal state anywhere. I think Jan already
agrees to add support for it (thx Jan) and we will get what we need
from there.


More information about the wayland-devel mailing list