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

[Pekka Vuorela]

On 18.03.2013 16:21, Jan Arne Petersen wrote:
> On 03/08/2013 09:17 PM, Pekka Vuorela wrote:

>> 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.

Input method predicting how surrounding text changes sounds good to me. 
What it requires is that there's a mechanism to distinguish for which 
action sent there's an state update coming. So that predicted state 
after "a"+"b" don't get overwritten with an update for "a".

For that the synchronization no-op, or extra commit_state with updated 
serial or similar, is required too, so input method won't get stuck on 
wrongly predicted state in case "b" was discarded by the editor.

I suspect on some cases the input method might want to be absolutely 
sure and maybe even block further events before acknowledgement for 
actions is received. Above enables also that.

For ignoring replace event I'm not sure. Input method really wanting to 
make a change would need to re-send replacement, then again waiting for 
pending state updates would do the same thing with the expense of small 
delay on non-filtered case.

If I could also request some more documentation for the serial values. 
Looking back at them only from protocol definitions, I'm not quite sure 
who creates them and when the values are incremented and when passed back.