[PATCH 00/13] Clean up text protocol and move to wayland

[Jan Arne Petersen]

On 03/08/2013 09:17 PM, Pekka Vuorela wrote:
> On 19.02.2013 20:26, Jan Arne Petersen wrote:
>> From: Jan Arne Petersen <jpetersen at openismus.com>
>>
>> This series finalizes the first version of the text protocol and
>> moves it from Weston to Wayland, so that it can be implemented in
>> toolkits.
>>
>> It adds the missing language/text-direction support to the
>> protocol.
>>
>> text_model gets renamed to wl_text_input, text_model_factory to
>> wl_text_input_manager.
>>
>> There is also a small fix on the preedit-style enum and
>> wl_text_input::commit is renamed to ::commit_state to make it more
>> clear what is commited. There are also some small documentation fixes.
> 
> Hadn't myself commented on the actual content yet, but not including the
> last commit for removing whole interface from Weston side: looks good to
> me.
> 
> I think the actual moving should be done separately for allowing the
> intended stable version to live some time in master first. No matter how
> ready it seems.

Yes, I agree. And one could also try them out easier with installable
protocol files:
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007488.html

> Before moving to Wayland, one thing that I'd like to be covered good is
> the good old synchronization problem.
> 
> Suppose input method commits "a", then "b", and then decides via some
> error correction mechanisms that the text should in fact be "dc". Thus
> the editor should finally get delete_surrounding_text + commit with new
> string. Now, depending on system load, at the last step input method
> might have received no state updates, state update after "a" or the
> final state update after "ab". With this and some variations, the state
> can be needed for sending replacements and further events.
> 
> I might be a bit lost again with the serials, so could go through the
> scenario to ensure it works. At least state updating commit/commit_state
> doesn't have a serial argument, so how does the input method know if it
> has received the final updated state?

Yes, i think that is an important point. Thanks that you brought that
up. The most important point is, to require as less synchronization as
possible.

So in the default case the input method should be able to know by itself
the new surrounding text and cursor position of an input widget after a
commit/replace.

Synchronization is then only required in two cases: First external
changes to the text/cursor position of an input widget (by
clicking/touching on a widget or setting the text to some new value
independent of input from the input method). Second non-default-handling
of input method events (change text on commit, do not delete text on
request, move cursor to different position than requested).

We have the first case covered by reset (with the serial), the
commit-on-reset string in pre-edit and the client usually just dropping
all unprocessed events from the input-method which happened before the
reset.
Since we have commit_state now it might make sense to update the serial
there instead of in the reset request (so we make sure the input method
has all the new state available). Instead of including a serial in
different events we could also add an explicit reset-received event.

> Also how should it work if application filters out "b" as illegal
> character? Should commit_state be always called after new input or
> should there perhaps be some synchronization no-op request on text
> protocol side?

That is the second case, and is not really covered yet, but I agree that
we should think how it should be handled best before we put the text
protocol into Wayland.

In contrast to the reset-case it is not so clear what would be the best
thing to do here.

We should collect some use-cases and decide how to best handle it on
input editor and input method side, and figure out the best API/protocol
approach to achieve this.

So the first case "a", "b", replace with "dc" should just work without
synchronization.

The second case would be "a", "b" (filtered out), replace with "dc". I
guess in this case the input editor should ignore also the replace event
(what is with other kinds of events? what is with events after
replace?). And the input method needs to be informed about the final state.

Regards,
Jan Arne

-- 
Jan Arne Petersen
Openismus GmbH
http://www.openismus.com