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

[Yichao Yu]

On Thu, Jan 31, 2013 at 2:20 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> On 01/31/2013 10:42 AM, Michael Hasselmann wrote:
>
>> 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
>
>
> It sounds like this "language direction" is for placing the cursor in the
> preedit/commit string? I'm a bit confused as to what you are talking about.
>
> I think the commit/preedit string should contain an actual cursor position,
> it can be between any two bytes in it. There is no reason to limit it to the
> start/end.
>

It already does (although it doesn't make much sense to put the cursor
inside a multi-byte character...), the input method notify the client
for preedit changes, cursor move and commit strings and the client
will than draw the preedit text or commit string and move the cursor
accordingly, there is no need to parse any text in order to do it
right. Neither surrounding text nor the string being commit/set as
preedit is directly related (the input method should already know
enough about where the cursor should be when doing that).

>
>> (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.
>
>
> I sure hope the client can do *exactly* the same thing with the preedit
> versus the commit string. There is no reason for the data to be different.
> The only difference is that the client remembers what text was placed by the
> preedit string so it can delete it on the next preedit or commit or if the
> input method aborts.
>
>
>>> 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?
>
>
> Yes I guessed that was happening. I thought this would contain enough
> information in Unicode for the input method to determine the direction.
>
> My concern is that a stupid client, and input methods who have to insert
> them to make sure, would result in large numbers of direction indicator
> characters being inserted into the text. If the input method as part of the
> preedit/commit strings is allowed to delete some of the bytes of the
> surrounding text, it could then remove redundant direction indicators.
>
> As I see it interaction would be something like this:
>
> 1. Client sends the entire surrounding text to the input method as a single
> block of UTF-8 bytes, plus two byte offsets into it indicating the selected

Well, it is only practical to send limited length of text for
performance issue. And I think the selected region is not really
related to input method. It may be helpful to tell the input method if
some text is selected at the cursor (to be replaced by the commit
string) but that's a separate issue.

> region. This text should be the same unit that is sent to Pango, a paragraph
> (the input method can handle less being sent but might not be as smart). If
> the selected region contains a paragraph break, or is very large, the client
> elides a large chunk in the middle so it is one paragraph.
>
> 2. As user types, input method sends either preedit or commit events. These
> contain:
>  1. two offsets for how to move the two ends of the selected region to get
> the block of bytes to replace (ie it can decide to delete some of the
> surrounding text, and also to not delete all of the selected region).
>  2. A block of bytes of replacement text
>  3. Two offsets into that to indicate a new selected region and cursor
> position.

If what you mean by "selected region" is actually preedit, that should
be a temporary text that get cleared when the text model lost focus.

>
> The only difference between preedit and commit is that the client remembers
> the state before the preedit and restores it before applying the next
> preedit or commit. It might also show the selected region and cursor
> differently.

The only similarity between preedit and commit is that they should be
rendered the same. Unless requested or lost focus, the client should
never change the preedit string or moving the cursor. And preedit is
totally different from selected region.

>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel