Questions and thoughts about input method protocol

[Pekka Vuorela]

On 31.01.2013 19:54, Weng Xuetian wrote:
> On Wednesday 30 January 2013 23:09:20，Pekka Vuorela :

>> I would try to find better ways to achieve targeted goals. One feature
>> I've myself been thinking is virtual keyboard used with messaging app
>> knowing what language, or type of language, the recipient is speaking
>> and adjusting prediction/layout based on that. That could be done by
>> having locale in text editor's state, but alternatively could also be
>> editor setting a globally unique identifier (integer, string?) as state
>> for text fields, after which text input side could learn what language
>> got used. Similarly for chinese input such mechanism could be used to
>> remember preferences. Out-of-the box amazon and arxiv wouldn't make
>> difference, but after some use they would. To support this, the toolkits
>> and applications would also need some enhancements, though.
>
> So, at least, is it possible to let input method server to track different
> input contxt?
>
> The application should keep the input context alive upon it's lifetime (or the
> surface is alive), if I didn't understand it wrong, when application lost its
> focus, the input method will totally lost the track of the state. It is
> important to keep track the status of an application, there is some per
> context info need to be kept as long as the application is alive.
>
> Your idea is very adhoc and it won't scale if input method want to store keep
> custom data.
>
> For example, input method server will want to keep different context to use
> different engine, the language name is simply not enough. Or, user want to
> temporarily disable the word completion for this application, but keep it
> enable for another application. There can be tens of different state
> (generated from input method server side) that input method want to track
> with.
>
> Even the old XIM have done this right, Create a input context, and keep it as
> long as application is alive, then application exit, destroy it. And each
> input context have a unique identifier, which can be used to distinguish what
> input context are connectted inut method.

It feels there is some confusion in above.

First, editor state is something the application will send and update 
for focused editor. Only way that gets lost is application shutting down.

Second, the language tracking was only one possible use on the input 
method side. Some might want to do that, many others not. It is not 
visible on protocols in any way.