<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 25, 2016 at 8:16 AM Daiki Ueno <<a href="mailto:ueno@gnu.org">ueno@gnu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Jan Arne Petersen <<a href="mailto:janarne@gmail.com" target="_blank">janarne@gmail.com</a>> writes:<br>
<br>
> There is a reference implementation of this version of the protocol in QtWayland<br>
> <a href="https://codereview.qt-project.org/#/c/153711/" rel="noreferrer" target="_blank">https://codereview.qt-project.org/#/c/153711/</a> where the text-input protocol is used to proxy the<br>
> Qt input method of Qt Wayland clients to the Qt input method on compositor side.<br>
<br>
Thanks, it is helpful to understand the protocol while rebasing the<br>
gtk+/mutter patches.<br>
<br>
I have a few comments on the protocol:<br>
<br>
> +    <request name="update_state"><br>
[...]<br>
> +      <arg name="serial" type="uint" summary="used to identify the known state"/><br>
> +      <arg name="flags" type="uint" enum="update_state"/><br>
> +    </request><br>
<br>
The name "flags" implies that it takes multiple bit flags, but it<br>
actually takes a single enum value.  Maybe it is better called "state"<br>
or "reason"?<br></blockquote><div><br></div><div> Yes reason is better. I will update it.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> +      <description summary="update state"><br>
> +     Allows to atomically send state updates from client.<br>
> +<br>
> +     This request should follow after a batch of state updating requests<br>
> +     like set_surrounding_text, set_content_type, set_cursor_rectangle and<br>
> +     set_preferred_language.<br>
<br>
This sentence indicates that the request is used for some sort of<br>
synchronization between the client and compositor.  I'm wondering if it<br>
could perform a roundtrip using wl_callback, instead of generating a<br>
serial on the client side.  Then the serial could later be obtained from<br>
the compositor through wl_callback.done.  Would that cause any race<br>
conditions?<br></blockquote><div><br></div><div>Yes indeed great idea. I will replace all client generated serials with wl_display_sync() and use only compositor side generated serials for enter/leave/input_method_changed like everywhere else in Wayland.</div><div><br></div><div>I will send an updated protocol and updated QtWayland reference implementation soon.</div><div><br></div><div>Thanks very much,</div><div>Jan Arne</div></div></div>