Questions and thoughts about input method protocol

[Pekka Vuorela]

On 01.02.2013 21:53, Yichao Yu wrote:
> 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:
>>>> 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.

I have never in this thread suggested adding current language as 
information passed to input method nor any other basic info more. I have 
described a method for application to _identify_ a specific context for 
input forever, regardless of when the application gets shutdown or 
restarted. Language and prediction prioritization have been examples how 
input method can _internally_ store state for particular editing targets 
using the editor identifier.

The other discussion I interpreted as identifying run-time unique 
instances of different editors. E.g. starting two instances of MyEditor 
will have something on input method interface allowing to distinguish 
between them. Can be used e.g. for restoring input method type when 
re-focusing a specific text entry. Right?

(To be noted that there are two variations here for language state use 
case: one keeping it per application/editor and other for keeping it for 
separate run-time instances.)