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

[Yichao Yu]

On Fri, Feb 1, 2013 at 8:31 AM, Jan Arne Petersen
<jpetersen at openismus.com> wrote:
> On 01.02.2013 13:43, Yichao Yu wrote:
>> On Fri, Feb 1, 2013 at 3:25 AM, Jan Arne Petersen
>> <jpetersen at openismus.com> wrote:
>>> On 31.01.2013 23:49, Weng Xuetian wrote:
>>>> On Thursday 31 January 2013 20:50:00，Jan Arne Petersen :
>>>>> 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.
>>>> Not the per-widget case, but if you see the implementation of XIM in Qt 4.8,
>>>> it implements per window input context. And I also take the same approach for
>>>> fcitx, in both Qt4 and Qt5 version, and really see the benefit. Here is a use
>>>> case.
>>>>
>>>> One people use instant message with two different people, one you want to use
>>>> Chinese, and the other you want to use German. Here comes some knowledge that
>>>> know by only user, not the application. So, it is possible to let input method
>>>> to use Chinese in that window, and German in another window.
>>>
>>> Well and the idea of the language API is to just solve that. An IM
>>> client can just store the last language you used to write to some person.
>>
>> This is just an example and the point is only language is totally not
>> enough. There can be more than one input method for a single language
>> and there are dozens of different state a input method may want to
>> store for each context, including those that is hard to represent as
>> strings.
>
> It is a bad example in this case then, because language is just much
> better stored on client side. It can be also be used for client side
> spell checking language. It can be used to assign a language to a
> (aggregated) contact person on client side, so you can use it for all
> ways contacting the person, instant messaging, emails, facebook etc.

Well, I think the exact language in use is totally determined by the
input method. The client have no way to know when there is a input
method switching. That's why I agree adding a text_model::language
event can be useful (when a input method switching happens). I think
it will indeed be useful for the client to maintain a id/preferred
language that will not be lost even after the client restarted (i.e.
impossible to track by input_context). The input method may then be
able to set a initial state accordingly but anything after that is not
sth the client can control.

>
> But yes, as I wrote in another email I will have a look at Chinese input
> methods and will consider adding state to input contexts.

Hopefully not only a property on the input_method_context since some
states are really hard to stringify/standardized if not impossible.

>
> --
> Jan Arne Petersen
> Openismus GmbH
> http://www.openismus.com
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel