[PATCH RFC] Add language and text-direction to text protocol

[Yichao Yu]

On Thu, Jan 31, 2013 at 2:59 PM, Yichao Yu <yyc1992 at gmail.com> wrote:
> On Thu, Jan 31, 2013 at 2:50 PM, Jan Arne Petersen
> <jpetersen at openismus.com> wrote:
>> On 31.01.2013 18:00, Yichao Yu wrote:
>>> On Thu, Jan 31, 2013 at 11:44 AM, Jan Arne Petersen
>>> <jpetersen at openismus.com> wrote:
>>>> From: Jan Arne Petersen <jpetersen at openismus.com>
>>>>
>>>> The proposed API allows to send the language and text-direction for
>>>> inserted text from an input-method to an application.
>>>
>>> Can't really see why text-direction (of the input window) is useful,
>>> shouldn't that be a property of the language?
>
> O sorry, I though the text_direction was a request from the client. If
> it is used to tell the client of the language and the text direction
> in-use, it makes perfectly sense for me.

And I totally agree with sending a separate text_direction event to
the client. If someone need to decide the text_direction from language
code, it should be the input method instead of the client.

>
>>
>> Usually it can be just deduced from the language but I remember the case
>> of entering phone numbers, which were also LTR-numbers in RTL-languages.
>>
>>>> It also allows an application to specify a preferred language for
>>>> the input. This could be used by an application to set a language
>>>> by context or to request the last used language after an input
>>>> entry regains focus.
>>>
>>> I believe the input method have better knowledge of the language in
>>> use and being able to remember that on a per context state? (or do you
>>> mean the context will be destroyed when the text_model lost focus??)
>>
>> Currently the context is state-less but even when we add state there, in
>> Qt, for example, there is currently just one input context per
>> application not one per widget.
>
> The whole point is not about distinguishing different clients, it's
> about tracking the state. It doesn't matter how many input context an
> application created, but the input method must be able to know if it
> is dealing with a same input_context and restore states accordingly.
> (well the client is able to destroy this by recreate a context
> whenever it get focus but that is definitely a bug.) A state less
> input method context is plain wrong.
>
> P.S. if you are looking at ibus-qt, you may want to have a look at
> qt's xim and fcitx immodule, both of them create input context per
> main window.
>
>>
>> --
>> Jan Arne Petersen
>> Openismus GmbH
>> http://www.openismus.com