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

Weng Xuetian wengxt at gmail.com
Thu Jan 31 14:49:29 PST 2013

On Thursday 31 January 2013 20:50:00,Jan Arne Petersen :
> 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?
> 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.
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 

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.

Though there is only one QInputContext / QPlatformInputContext , but you can 
also expose it as "multi" input context to the input method server.

What input context should be ?
IMHO, input context should be the smallest element that will have different 
property in application, 1 context? or 2 context? It should be decided by 
application, not by changing the property of input context every time.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130131/6dfd7b85/attachment.pgp>

More information about the wayland-devel mailing list