On Sat, Feb 2, 2013 at 4:49 AM, Pekka Vuorela <pvuor...@iki.fi> wrote:
> On 01.02.2013 21:53, Yichao Yu wrote:
>>
>> On Fri, Feb 1, 2013 at 1:48 PM, Pekka Vuorela <pvuor...@iki.fi> wrote:
>>>
>>> On 01.02.2013 00:45, Yichao Yu wrote:
>>>>
>>>>
>>>> On Thu, Jan 31, 2013 at 5:19 PM, Pekka Vuorela <pvuor...@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?The only problem is that there isn't a way right now (which will hopefully be fixed). > > (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.) > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
