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

Jan Arne Petersen jpetersen at openismus.com
Fri Feb 1 05:31:53 PST 2013

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.

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.

Jan Arne Petersen
Openismus GmbH

More information about the wayland-devel mailing list