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

[Michael Hasselmann]

On Thu, 2013-01-31 at 09:33 -0800, Bill Spitzak wrote:
> On 01/31/2013 08:44 AM, Jan Arne Petersen 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 direction be determined by using Unicode rules on the new text, 
> with direction override characters if the default rules don't work. This 
> will allow the input method to return mixed-mode text.

I think mixed-mode text is an orthogonal use-case. A common example is
mixing "western" numbers (in reality they are Devanagari numbers) with
RTL text.

You need to place your cursor at the left or right end of a text entry
(actually, right or left of the possibly already existing text, on
focus-in). An explicit text direction event makes it easier than having
to wait and parse for the input method's text (which you can only really
do after receiving the commit string, not while showing the preedit
string). Without the extra event you have to accept annoying UI
adjustments while already typing in text.

You are probably right that we could make clever use of existing events
instead, but I prefer simple-to-use & robust protocols over clever
protocols, even if I pay with redundancy here and there.

> This might require the client to send the input method a large block of 
> "context", such as the entire current paragraph, so that it can figure 
> out the best insertion text so the direction indicators are right.

We already do send surrounding text, no?

>  Since 
> it seems to me this context is very useful for other parts of input 
> methods this may be better than the alternative of the client having to 
> figure out how to merge the UTF-8 insertion into the existing text.

Making use of surrounding text for improving input method enigne results
is another orthogonal use-case.

The text merging always happens on the client side and is already
well-defined with the preedit/commit string interaction. I think it's
assumed that Wayland strings represent Unicode.

I feel as if I am entirely missing the point you're trying to make.

regards,
Michael