Hello, Jan Arne Petersen <[email protected]> writes:
> There is a reference implementation of this version of the protocol in > QtWayland > https://codereview.qt-project.org/#/c/153711/ where the text-input protocol > is used to proxy the > Qt input method of Qt Wayland clients to the Qt input method on compositor > side. Thanks, it is helpful to understand the protocol while rebasing the gtk+/mutter patches. I have a few comments on the protocol: > + <request name="update_state"> [...] > + <arg name="serial" type="uint" summary="used to identify the known > state"/> > + <arg name="flags" type="uint" enum="update_state"/> > + </request> The name "flags" implies that it takes multiple bit flags, but it actually takes a single enum value. Maybe it is better called "state" or "reason"? > + <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? Regards, -- Daiki Ueno _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
