[wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Sun, 11 Mar 2018 20:30:14 +0100
Carlos Garnacho <carlosg at gnome.org> wrote:

> This new protocol description is a vast simplification over v2, highlights
> are:
> - All pre-edit text styling is gone, the protocol doesn't seem the place
>   to convey UI state. Clients are in better knowledge of how to make the
>   pre-edit string distinguishable from regular text.
> - No input panel (OSK) state nor covered rectangle events. This leaks
>   assumptions about the coordinate space of windows, and clients aren't
>   fully capable of handling all possible situations (eg. if the OSK fully
>   covers the surface). At the very least it could be split into a generic
>   protocol of its own, this version of the protocol simply doesn't get
>   into this business, compositors are still free to handle situations where
>   the keyboard focus rectangle is covered by the input panel.
> - Less state is to be kept on compositors. Clients must now reissue all
>   applying IM state whenever the surface gains focus (or internal focus
>   changes), instead of state requests being independent from focus.
> - No set_preferred_language request for clients, modern desktops have
>   generally moved towards session-wide IM settings, it seems hard to
>   conciliate this piece of information flowing in both directions.
> - There is no event to send keysyms. The handling ought to be by all means
>   identical to wl_keyboard's, compositors might just use that interface.
> 
> Signed-off-by: Carlos Garnacho <carlosg at gnome.org>
> ---
> 
> Hey,
> 
> Belatedly, here's my proposed v3 of the text-input protocol, a rename of
> what is implemented on gnome-shell/gtk+. It basically is a
> (over?)simplification compared to v2, the main difference besides the
> punted functionality is the simplified messaging flow, state is considered
> reset after enter/leave, or on .disable requests from the client, all
> new state must be submitted afterwards.
> 
> Some of the removed things are maybe debatable (eg. the keysym event,
> or language preference request/signal, although I don't see that working
> out of the box widely, highly toolkit specific at best). For stuff like
> the old input_panel_state request to do client-side UI magic to keep
> keyboard focus visible I'm personally more opinionated though :).
> 
> Comments?
> 
> Cheers,
>   Carlos

...

> +      Focus moving throughout surfaces will result in the emission of
> +      zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
> +      surface must perform zwp_text_input_v3.enable and
> +      zwp_text_input_v3.disable requests as the keyboard focus moves across
> +      editable and non-editable elements of the UI. Those two requests are not
> +      expected to be paired with each other, the compositor must be able to
> +      handle consecutive series of the same request.
What does it mean if there are several consecutive "enable" events? Should the compositor treat the second and next as an implicit "disable" events? Or should the input method stay open, which makes some sense if the input method presents a popup?

...

> +    <event name="enter">
> +      <description summary="enter event">
> +       Notification that this seat's text-input focus is on a certain surface.
> +
> +       When the seat has the keyboard capability the text-input focus follows
> +       the keyboard focus.
> +      </description>
> +      <arg name="serial" type="uint" summary="serial"/>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +    </event>
> +
> +    <event name="leave">
> +      <description summary="leave event">
> +       Notification that this seat's text-input focus is no longer on
> +       a certain surface. The client should reset any preedit string previously
> +       set.
> +
> +       The leave notification is sent before the enter notification
> +       for the new focus.
I read this to mean that there can be only one surface in the "entered" state at a time. What is the purpose of serial number in the enter and leave events if there's only one surface to keep track of?

Cheers,
Dorota
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180329/29f36198/attachment-0001.sig>