[PATCH wayland-protocols v5] text: Create second version of text input protocol

[Daiki Ueno]

Bill Spitzak <spitzak at gmail.com> writes:

> On Fri, Mar 25, 2016 at 12:16 AM, Daiki Ueno <ueno at gnu.org> wrote:
>
>
>  > + <description summary="update state">
>  > + Allows to atomically send state updates from client.
>  > +
>  > + This request should follow after a batch of state updating requests
>  > + like set_surrounding_text, set_content_type, set_cursor_rectangle and
>  > + set_preferred_language.
>
>  This sentence indicates that the request is used for some sort of
>  synchronization between the client and compositor. I'm wondering if it
>  could perform a roundtrip using wl_callback, instead of generating a
>  serial on the client side. Then the serial could later be obtained from
>  the compositor through wl_callback.done. Would that cause any race
>  conditions?
>
>
> It's not a synchronization, all the requests are going from client to server. It is to batch them or
> make them atomic, or as the wl_surface calls it, it is to double-buffer the requests.

Sorry for the belated response.  Just to be clear: the update_state
request itself is not a synchronization, yes.  However, there is an
implicit synchronization where the serial passed by the update_state
request is sent back to the client by the subsequent events like
preedit_string or commit_string.  This is to ensure the validity of the
states set by the preceding set_* requests.

I'm actually not sure which is better: using client-generated serials or
roundtrip, nor whether it is possible to avoid the statefulness.  Even
then, I guess an explicit roundtrip here would make the implementation a
bit easier.

Regards,
-- 
Daiki Ueno