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

Submitted by Dorota Czaplejewicz on April 9, 2018, 2:20 p.m.

Details

Message ID 20180409162053.2e388249@movable.Speedport_W_723V_1_45_000
State Superseded
Headers show
Series "text-input: Add v3 of the text-input protocol" ( rev: 2 ) in Wayland (DEPRECATED)

Not browsing as part of any series.

Commit Message

Dorota Czaplejewicz April 9, 2018, 2:20 p.m.
On Sun, 11 Mar 2018 20:30:14 +0100
Carlos Garnacho <carlosg@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@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

Hi,

this proposal sparked some interest on Purism side and led to brainstorming in the Sway project.

https://github.com/swaywm/wlroots/pull/776

We managed to implement the protocol and test it out with a simple demo. As a result, the original proposal changed shape a bit (attached), and both wlroots [0,1] and GTK [2] gained branches supporting the new version.

Speaking for Purism, we're interested in getting this text protocol finalized and support upstreamed into libraries. Comments very welcome.

Cheers,
Dorota

[0] https://github.com/swaywm/wlroots/pull/776
[1] rootston demo: https://code.puri.sm/dorota.czaplejewicz/wlroots/src/text_input_test
[2] https://code.puri.sm/dorota.czaplejewicz/gtk

---
 Makefile.am                                    |   1 +
 unstable/text-input/text-input-unstable-v1.xml | 459 ++++++++++---------------
 2 files changed, 192 insertions(+), 268 deletions(-)

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@  unstable_protocols =								\
 	unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml		\
 	unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml			\
 	unstable/text-input/text-input-unstable-v1.xml				\
+	unstable/text-input/text-input-unstable-v3.xml				\
 	unstable/input-method/input-method-unstable-v1.xml			\
 	unstable/xdg-shell/xdg-shell-unstable-v5.xml				\
 	unstable/xdg-shell/xdg-shell-unstable-v6.xml				\
diff --git a/unstable/text-input/text-input-unstable-v1.xml b/unstable/text-input/text-input-unstable-v1.xml
index 29a217e..f5d43e7 100644
--- a/unstable/text-input/text-input-unstable-v1.xml
+++ b/unstable/text-input/text-input-unstable-v1.xml
@@ -1,51 +1,68 @@ 
 <?xml version="1.0" encoding="UTF-8"?>
-<protocol name="text_input_unstable_v1">
 
+<protocol name="text_input_unstable_v3">
   <copyright>
     Copyright © 2012, 2013 Intel Corporation
-
-    Permission is hereby granted, free of charge, to any person obtaining a
-    copy of this software and associated documentation files (the "Software"),
-    to deal in the Software without restriction, including without limitation
-    the rights to use, copy, modify, merge, publish, distribute, sublicense,
-    and/or sell copies of the Software, and to permit persons to whom the
-    Software is furnished to do so, subject to the following conditions:
-
-    The above copyright notice and this permission notice (including the next
-    paragraph) shall be included in all copies or substantial portions of the
-    Software.
-
-    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-    DEALINGS IN THE SOFTWARE.
+    Copyright © 2015, 2016 Jan Arne Petersen
+    Copyright © 2017, 2018 Red Hat, Inc.
+    Copyright © 2018 Purism SPC
+
+    Permission to use, copy, modify, distribute, and sell this
+    software and its documentation for any purpose is hereby granted
+    without fee, provided that the above copyright notice appear in
+    all copies and that both that copyright notice and this permission
+    notice appear in supporting documentation, and that the name of
+    the copyright holders not be used in advertising or publicity
+    pertaining to distribution of the software without specific,
+    written prior permission.  The copyright holders make no
+    representations about the suitability of this software for any
+    purpose.  It is provided "as is" without express or implied
+    warranty.
+
+    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+    THIS SOFTWARE.
   </copyright>
 
-  <interface name="zwp_text_input_v1" version="1">
+  <interface name="zwp_text_input_v3" version="1">
     <description summary="text input">
-      An object used for text input. Adds support for text input and input
-      methods to applications. A text_input object is created from a
-      wl_text_input_manager and corresponds typically to a text entry in an
-      application.
+      The zwp_text_input_v3 interface represents text input and input methods
+      associated with a seat. It provides enter/leave events to follow the
+      text input focus for a seat.
 
-      Requests are used to activate/deactivate the text_input object and set
+      Requests are used to enable/disable the text-input object and set
       state information like surrounding and selected text or the content type.
-      The information about entered text is sent to the text_input object via
-      the pre-edit and commit events. Using this interface removes the need
-      for applications to directly process hardware key events and compose text
-      out of them.
-
-      Text is generally UTF-8 encoded, indices and lengths are in bytes.
-
-      Serials are used to synchronize the state between the text input and
-      an input method. New serials are sent by the text input in the
-      commit_state request and are used by the input method to indicate
-      the known text input state in events like preedit_string, commit_string,
-      and keysym. The text input can then ignore events from the input method
-      which are based on an outdated state (for example after a reset).
+      The information about the entered text is sent to the text-input object
+      via the pre-edit and commit_string events.
+
+      Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+      have to always point to the first byte of an UTF-8 encoded code point.
+      Lengths are not allowed to contain just a part of an UTF-8 encoded code
+      point.
+
+      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.
+
+      State is sent by the state requests (set_surrounding_text,
+      set_content_type and set_cursor_rectangle) and a commit request.
+      After an enter event or disable request all state information is
+      invalidated and needs to be resent by the client.
+
+      This protocol defines requests and events necessary for regular clients
+      to communicate with an input method. The zwp_input_method protocol
+      defines the interfaces necessary to implement standalone input methods.
+      If a compositor implements both interfaces, it will be the arbiter of the
+      communication between both.
 
       Warning! The protocol described in this file is experimental and
       backward incompatible changes may be made. Backward compatible changes
@@ -57,89 +74,87 @@ 
       interface version number is reset.
     </description>
 
-    <request name="activate">
-      <description summary="request activation">
-	Requests the text_input object to be activated (typically when the
-	text entry gets focus).
-
-	The seat argument is a wl_seat which maintains the focus for this
-	activation. The surface argument is a wl_surface assigned to the
-	text_input object and tracked for focus lost. The enter event
-	is emitted on successful activation.
-      </description>
-      <arg name="seat" type="object" interface="wl_seat"/>
-      <arg name="surface" type="object" interface="wl_surface"/>
-    </request>
-
-    <request name="deactivate">
-      <description summary="request deactivation">
-	Requests the text_input object to be deactivated (typically when the
-	text entry lost focus). The seat argument is a wl_seat which was used
-	for activation.
+    <request name="destroy" type="destructor">
+      <description summary="Destroy the wp_text_input">
+       Destroy the wp_text_input object. Also disables all surfaces enabled
+       through this wp_text_input object.
       </description>
-      <arg name="seat" type="object" interface="wl_seat"/>
     </request>
 
-    <request name="show_input_panel">
-      <description summary="show input panels">
-	Requests input panels (virtual keyboard) to show.
+    <enum name="enable_flags" bitfield="true">
+      <description summary="enable flags">
+       Enable flags is a bitmask to allow to modify the behavior of the text
+       input.
       </description>
-    </request>
+      <entry name="none" value="0x0" summary="no special behavior"/>
+      <entry name="can_show_preedit" value="0x1" summary="hints that the UI is capable of showing pre-edit text"/>
+      <entry name="toggle_input_panel" value="0x2" summary="requests toggling input panel (eg. on-screen keyboard)"/>
+    </enum>
 
-    <request name="hide_input_panel">
-      <description summary="hide input panels">
-	Requests input panels (virtual keyboard) to hide.
+    <request name="enable">
+      <description summary="Request text input to be enabled">
+        Requests text input on a surface.
       </description>
+      <arg name="flags" type="uint" enum="enable_flags" summary="details of the enable request"/>
     </request>
 
-    <request name="reset">
-      <description summary="reset">
-	Should be called by an editor widget when the input state should be
-	reset, for example after the text was changed outside of the normal
-	input method flow.
+    <request name="disable">
+      <description summary="Disable text input on a surface">
+        Explicitly disable text input in a surface (typically when there is no
+        focus on any text entry inside the surface).
       </description>
     </request>
 
     <request name="set_surrounding_text">
       <description summary="sets the surrounding text">
-	Sets the plain surrounding text around the input position. Text is
-	UTF-8 encoded. Cursor is the byte offset within the
-	surrounding text. Anchor is the byte offset of the
-	selection anchor within the surrounding text. If there is no selected
-	text anchor, then it is the same as cursor.
+       Sets the surrounding plain text around the input position. Text is
+       UTF-8 encoded. Cursor is the byte offset within the surrounding text.
+       Anchor is the byte offset of the selection anchor within the
+       surrounding text. If there is no selected text, anchor is the same as
+       cursor.
+
+       Make sure to always send some text before and after the cursor
+       except when the cursor is at the beginning or end of text.
+
+       There is a maximum length of wayland messages so text can not be
+       longer than 4000 bytes.
+
+       Values set with this request are double-buffered. They will get applied
+       on the next zwp_text_input_v3.commit request.
+
+       The initial value for text is an empty string, and the initial values for
+       cursor and anchor are 0.
       </description>
       <arg name="text" type="string"/>
-      <arg name="cursor" type="uint"/>
-      <arg name="anchor" type="uint"/>
+      <arg name="cursor" type="int"/>
+      <arg name="anchor" type="int"/>
     </request>
 
-    <enum name="content_hint">
+    <enum name="content_hint" bitfield="true">
       <description summary="content hint">
-	Content hint is a bitmask to allow to modify the behavior of the text
-	input.
+       Content hint is a bitmask to allow to modify the behavior of the text
+       input.
       </description>
-      <entry name="none" value="0x0" summary="no special behaviour"/>
-      <entry name="default" value="0x7" summary="auto completion, correction and capitalization"/>
-      <entry name="password" value="0xc0" summary="hidden and sensitive text"/>
-      <entry name="auto_completion" value="0x1" summary="suggest word completions"/>
-      <entry name="auto_correction" value="0x2" summary="suggest word corrections"/>
+      <entry name="none" value="0x0" summary="no special behavior"/>
+      <entry name="completion" value="0x1" summary="suggest word completions"/>
+      <entry name="spellcheck" value="0x2" summary="suggest word corrections"/>
       <entry name="auto_capitalization" value="0x4" summary="switch to uppercase letters at the start of a sentence"/>
       <entry name="lowercase" value="0x8" summary="prefer lowercase letters"/>
       <entry name="uppercase" value="0x10" summary="prefer uppercase letters"/>
       <entry name="titlecase" value="0x20" summary="prefer casing for titles and headings (can be language dependent)"/>
       <entry name="hidden_text" value="0x40" summary="characters should be hidden"/>
       <entry name="sensitive_data" value="0x80" summary="typed text should not be stored"/>
-      <entry name="latin" value="0x100" summary="just latin characters should be entered"/>
+      <entry name="latin" value="0x100" summary="just Latin characters should be entered"/>
       <entry name="multiline" value="0x200" summary="the text input is multiline"/>
     </enum>
 
     <enum name="content_purpose">
       <description summary="content purpose">
-	The content purpose allows to specify the primary purpose of a text
-	input.
+       The content purpose allows to specify the primary purpose of a text
+       input.
 
-	This allows an input method to show special purpose input panels with
-	extra characters or to disallow some characters.
+       This allows an input method to show special purpose input panels with
+       extra characters or to disallow some characters.
       </description>
       <entry name="normal" value="0" summary="default input, allowing all characters"/>
       <entry name="alpha" value="1" summary="allow only alphabetic characters"/>
@@ -149,237 +164,145 @@ 
       <entry name="url" value="5" summary="input an URL"/>
       <entry name="email" value="6" summary="input an email address"/>
       <entry name="name" value="7" summary="input a name of a person"/>
-      <entry name="password" value="8" summary="input a password (combine with password or sensitive_data hint)"/>
-      <entry name="date" value="9" summary="input a date"/>
-      <entry name="time" value="10" summary="input a time"/>
-      <entry name="datetime" value="11" summary="input a date and time"/>
-      <entry name="terminal" value="12" summary="input for a terminal"/>
+      <entry name="password" value="8" summary="input a password (combine with sensitive_data hint)"/>
+      <entry name="pin" value="9" summary="input is a numeric password (combine with sensitive_data hint)"/>
+      <entry name="date" value="10" summary="input a date"/>
+      <entry name="time" value="11" summary="input a time"/>
+      <entry name="datetime" value="12" summary="input a date and time"/>
+      <entry name="terminal" value="13" summary="input for a terminal"/>
     </enum>
 
     <request name="set_content_type">
       <description summary="set content purpose and hint">
-	Sets the content purpose and content hint. While the purpose is the
-	basic purpose of an input field, the hint flags allow to modify some
-	of the behavior.
+       Sets the content purpose and content hint. While the purpose is the
+       basic purpose of an input field, the hint flags allow to modify some
+       of the behavior.
 
-	When no content type is explicitly set, a normal content purpose with
-	default hints (auto completion, auto correction, auto capitalization)
-	should be assumed.
+       Values set with this request are double-buffered. They will get applied
+       on the next zwp_text_input_v3.commit request.
+
+       The initial value for hint is none, and the initial value for purpose
+       is normal.
       </description>
-      <arg name="hint" type="uint"/>
-      <arg name="purpose" type="uint"/>
+      <arg name="hint" type="uint" enum="content_hint"/>
+      <arg name="purpose" type="uint" enum="content_purpose"/>
     </request>
 
     <request name="set_cursor_rectangle">
+      <description summary="set cursor position">
+       Sets the cursor outline as a x, y, width, height rectangle in surface
+       local coordinates.
+
+       Allows the compositor to put a window with word suggestions near the
+       cursor.
+
+       Values set with this request are double-buffered. They will get applied
+       on the next zwp_text_input_v3.commit request.
+
+       The initial values describing a cursor rectangle are invalid. That means
+       the pending cursor rectangle values must be set before the first commit
+       request.
+      </description>
       <arg name="x" type="int"/>
       <arg name="y" type="int"/>
       <arg name="width" type="int"/>
       <arg name="height" type="int"/>
     </request>
 
-    <request name="set_preferred_language">
-      <description summary="sets preferred language">
-	Sets a specific language. This allows for example a virtual keyboard to
-	show a language specific layout. The "language" argument is an RFC-3066
-	format language tag.
+    <request name="commit">
+      <description summary="commit state">
+       Text input state (content purpose, content hint, surrounding text,
+       cursor rectangle) is conceptually double-buffered. Protocol requests
+       modify the pending state, as opposed to the current state in use by the
+       input method. A commit request atomically applies all pending state,
+       replacing the current state. After commit, the new pending state is as
+       documented for each related request.
 
-	It could be used for example in a word processor to indicate the
-	language of the currently edited document or in an instant message
-	application which tracks languages of contacts.
+       The current and pending state never changes unless noted otherwise.
       </description>
-      <arg name="language" type="string"/>
-    </request>
-
-    <request name="commit_state">
-      <arg name="serial" type="uint" summary="used to identify the known state"/>
-    </request>
-
-    <request name="invoke_action">
-      <arg name="button" type="uint"/>
-      <arg name="index" type="uint"/>
     </request>
 
     <event name="enter">
       <description summary="enter event">
-	Notify the text_input object when it received focus. Typically in
-	response to an activate request.
+       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="surface" type="object" interface="wl_surface"/>
     </event>
 
     <event name="leave">
       <description summary="leave event">
-	Notify the text_input object when it lost focus. Either in response
-	to a deactivate request or when the assigned surface lost focus or was
-	destroyed.
-      </description>
-    </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.
 
-    <event name="modifiers_map">
-      <description summary="modifiers map">
-	Transfer an array of 0-terminated modifier names. The position in
-	the array is the index of the modifier as used in the modifiers
-	bitmask in the keysym event.
-      </description>
-      <arg name="map" type="array"/>
-    </event>
+       The leave notification is sent before the enter notification
+       for the new focus.
 
-    <event name="input_panel_state">
-      <description summary="state of the input panel">
-	Notify when the visibility state of the input panel changed.
+       When the seat has the keyboard capability the text-input focus follows
+       the keyboard focus.
       </description>
-      <arg name="state" type="uint"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
     </event>
 
     <event name="preedit_string">
       <description summary="pre-edit">
-	Notify when a new composing text (pre-edit) should be set around the
-	current cursor position. Any previously set composing text should
-	be removed.
-
-	The commit text can be used to replace the preedit text on reset
-	(for example on unfocus).
-
-	The text input should also handle all preedit_style and preedit_cursor
-	events occurring directly before preedit_string.
+       Notify when a new composing text (pre-edit) should be set around the
+       current cursor position. Any previously set composing text should
+       be removed.
       </description>
-      <arg name="serial" type="uint" summary="serial of the latest known text input state"/>
-      <arg name="text" type="string"/>
-      <arg name="commit" type="string"/>
-    </event>
-
-    <enum name="preedit_style">
-      <entry name="default" value="0" summary="default style for composing text"/>
-      <entry name="none" value="1" summary="style should be the same as in non-composing text"/>
-      <entry name="active" value="2"/>
-      <entry name="inactive" value="3"/>
-      <entry name="highlight" value="4"/>
-      <entry name="underline" value="5"/>
-      <entry name="selection" value="6"/>
-      <entry name="incorrect" value="7"/>
-    </enum>
-
-    <event name="preedit_styling">
-      <description summary="pre-edit styling">
-	Sets styling information on composing text. The style is applied for
-	length bytes from index relative to the beginning of the composing
-	text (as byte offset). Multiple styles can
-	be applied to a composing text by sending multiple preedit_styling
-	events.
-
-	This event is handled as part of a following preedit_string event.
-      </description>
-      <arg name="index" type="uint"/>
-      <arg name="length" type="uint"/>
-      <arg name="style" type="uint"/>
-    </event>
-
-    <event name="preedit_cursor">
-      <description summary="pre-edit cursor">
-	Sets the cursor position inside the composing text (as byte
-	offset) relative to the start of the composing text. When index is a
-	negative number no cursor is shown.
-
-	This event is handled as part of a following preedit_string event.
-      </description>
-      <arg name="index" type="int"/>
+      <arg name="text" type="string" allow-null="true"/>
+      <arg name="cursor" type="uint"/>
     </event>
 
     <event name="commit_string">
-      <description summary="commit">
-	Notify when text should be inserted into the editor widget. The text to
-	commit could be either just a single character after a key press or the
-	result of some composing (pre-edit). It could also be an empty text
-	when some text should be removed (see delete_surrounding_text) or when
-	the input cursor should be moved (see cursor_position).
-
-	Any previously set composing text should be removed.
-      </description>
-      <arg name="serial" type="uint" summary="serial of the latest known text input state"/>
-      <arg name="text" type="string"/>
-    </event>
+      <description summary="text commit">
+       Notify when text should be inserted into the editor widget. The text to
+       commit could be either just a single character after a key press or the
+       result of some composing (pre-edit).
 
-    <event name="cursor_position">
-      <description summary="set cursor to new position">
-	Notify when the cursor or anchor position should be modified.
+       The text argument could be also null if some text is removed (see
+       zwp_text_input_v3.delete_surrounding_text).
 
-	This event should be handled as part of a following commit_string
-	event.
+       Any previously set composing text should be removed.
       </description>
-      <arg name="index" type="int"/>
-      <arg name="anchor" type="int"/>
+      <arg name="text" type="string" allow-null="true"/>
     </event>
 
     <event name="delete_surrounding_text">
       <description summary="delete surrounding text">
-	Notify when the text around the current cursor position should be
-	deleted.
-
-	Index is relative to the current cursor (in bytes).
-	Length is the length of deleted text (in bytes).
+       Notify when the text around the current cursor position should be
+       deleted. Before_length and after_length is the length (in bytes) of text
+       before and after the current cursor position (excluding the selection)
+       to delete.
 
-	This event should be handled as part of a following commit_string
-	event.
+       This event should be handled as part of a following commit_string or
+       preedit_string event.
       </description>
-      <arg name="index" type="int"/>
-      <arg name="length" type="uint"/>
-    </event>
-
-    <event name="keysym">
-      <description summary="keysym">
-	Notify when a key event was sent. Key events should not be used
-	for normal text input operations, which should be done with
-	commit_string, delete_surrounding_text, etc. The key event follows
-	the wl_keyboard key event convention. Sym is an XKB keysym, state a
-	wl_keyboard key_state. Modifiers are a mask for effective modifiers
-	(where the modifier indices are set by the modifiers_map event)
-      </description>
-      <arg name="serial" type="uint" summary="serial of the latest known text input state"/>
-      <arg name="time" type="uint"/>
-      <arg name="sym" type="uint"/>
-      <arg name="state" type="uint"/>
-      <arg name="modifiers" type="uint"/>
-    </event>
-
-    <event name="language">
-      <description summary="language">
-	Sets the language of the input text. The "language" argument is an
-	RFC-3066 format language tag.
-      </description>
-      <arg name="serial" type="uint" summary="serial of the latest known text input state"/>
-      <arg name="language" type="string"/>
-    </event>
-
-    <enum name="text_direction">
-      <entry name="auto" value="0" summary="automatic text direction based on text and language"/>
-      <entry name="ltr" value="1" summary="left-to-right"/>
-      <entry name="rtl" value="2" summary="right-to-left"/>
-    </enum>
-
-    <event name="text_direction">
-      <description summary="text direction">
-	Sets the text direction of input text.
-
-	It is mainly needed for showing an input cursor on the correct side of
-	the editor when there is no input done yet and making sure neutral
-	direction text is laid out properly.
-      </description>
-      <arg name="serial" type="uint" summary="serial of the latest known text input state"/>
-      <arg name="direction" type="uint"/>
+      <arg name="before_length" type="uint" summary="length of text before current cursor position"/>
+      <arg name="after_length" type="uint" summary="length of text after current cursor position"/>
     </event>
   </interface>
 
-  <interface name="zwp_text_input_manager_v1" version="1">
+  <interface name="zwp_text_input_manager_v3" version="1">
     <description summary="text input manager">
-      A factory for text_input objects. This object is a global singleton.
+      A factory for text-input objects. This object is a global singleton.
     </description>
 
-    <request name="create_text_input">
-      <description summary="create text input">
-	Creates a new text_input object.
+    <request name="destroy" type="destructor">
+      <description summary="Destroy the wp_text_input_manager">
+       Destroy the wp_text_input_manager object.
       </description>
-      <arg name="id" type="new_id" interface="zwp_text_input_v1"/>
     </request>
-  </interface>
 
+    <request name="get_text_input">
+      <description summary="create a new text input object">
+       Creates a new text-input object for a given seat.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_text_input_v3"/>
+      <arg name="seat" type="object" interface="wl_seat"/>
+    </request>
+  </interface>
 </protocol>

Comments

On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> On Sun, 11 Mar 2018 20:30:14 +0100
> 
> Carlos Garnacho <carlosg@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.
As an long-time input method developer and CJK user, I'd prefer to keep the 
styling. In Chinese or Japanese, partially converted text are common and 
styling is useful to help user to distinguish which text is currently being 
converted. [1] But for the sake of in-app consistency, I'd say we don't need 
that much capability about styling though. Among all input methods supported 
by fcitx [2], only underline/highlight is being commonly used. Recently I 
started to use some strike style in only one single input method though, it 
can also be useful in certain cases.

> > 
> > - 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.
Let input method itself to send any key event is somewhat an important 
feature. Common use cases includes "sending backspace key via OSK", or 
"simulating another keyboard layout". Fcitx (5, which is under developlment) 
provides ability to use a keyboard layout without changing the system global 
layout, which can be extremely helpful for users using multiple layout. For 
example,  the hotkey key binding would keep the same while they can still 
using the custom layout (e.g. position of ctrl + z is different under us/de).

I assume that you mean that it is replaced by creating sythatical key event  
via compositor and sending them via wl_keyboard? I'm not so sure if that 
works, especially when there is no real phyiscal keyboard.

[1] https://i.imgur.com/MpibNVi.png
[2] https://fcitx-im.org/
On Wed, 11 Apr 2018 11:26:22 -0700
Weng Xuetian <wengxt@gmail.com> wrote:

> On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> > On Sun, 11 Mar 2018 20:30:14 +0100
> > 
> > Carlos Garnacho <carlosg@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.  
> As an long-time input method developer and CJK user, I'd prefer to keep the 
> styling. In Chinese or Japanese, partially converted text are common and 
> styling is useful to help user to distinguish which text is currently being 
> converted. [1] But for the sake of in-app consistency, I'd say we don't need 
> that much capability about styling though. Among all input methods supported 
> by fcitx [2], only underline/highlight is being commonly used. Recently I 
> started to use some strike style in only one single input method though, it 
> can also be useful in certain cases.

I think this use case is covered. For indicating what's currently being changed, this protocol is using "preedit string". In GTK, the preedit text is displayed with an underline, making is always clear what the suggestion pertains to.
> 
> > > 
> > > - 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.  
> Let input method itself to send any key event is somewhat an important 
> feature. Common use cases includes "sending backspace key via OSK", or 
> "simulating another keyboard layout". Fcitx (5, which is under developlment) 
> provides ability to use a keyboard layout without changing the system global 
> layout, which can be extremely helpful for users using multiple layout. For 
> example,  the hotkey key binding would keep the same while they can still 
> using the custom layout (e.g. position of ctrl + z is different under us/de).
> 
> I assume that you mean that it is replaced by creating sythatical key event  
> via compositor and sending them via wl_keyboard? I'm not so sure if that 
> works, especially when there is no real phyiscal keyboard.
> 
I read it the same way. At the same time, I also don't see a reason to duplicate the keyboard interface in another protocol - the compositor can tell the application that there's a regular (but virtual) keyboard connected and send events using the regular wl_keyboard protocol.

Cheers,
Dorota

> [1] https://i.imgur.com/MpibNVi.png
> [2] https://fcitx-im.org/
> 
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
(forgot to reply to the list)

On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
> On Wed, 11 Apr 2018 11:26:22 -0700
> 
> Weng Xuetian <wengxt@gmail.com> wrote:
> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> > > On Sun, 11 Mar 2018 20:30:14 +0100
> > > 
> > > Carlos Garnacho <carlosg@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.
> > 
> > As an long-time input method developer and CJK user, I'd prefer to keep
> > the
> > styling. In Chinese or Japanese, partially converted text are common and
> > styling is useful to help user to distinguish which text is currently
> > being
> > converted. [1] But for the sake of in-app consistency, I'd say we don't
> > need that much capability about styling though. Among all input methods
> > supported by fcitx [2], only underline/highlight is being commonly used.
> > Recently I started to use some strike style in only one single input
> > method though, it can also be useful in certain cases.
> 
> I think this use case is covered. For indicating what's currently being
> changed, this protocol is using "preedit string". In GTK, the preedit text
> is displayed with an underline, making is always clear what the suggestion
> pertains to.
I think you can take a closer look at [1].

"葵あ" is the complete preedit text. The input method is converting "葵" and 
giving the candidates for it, the あ part is not yet handled by input method 
(but typed by user and appears in the preedit). That's why "葵" is being 
highlighted.

In a single CJK text composition, CJK people would type the full sentence 
ahead instead of word by word because this helps input method to understand 
the whole context and improve the prediction. 

[1] https://i.imgur.com/MpibNVi.png
Hi!,

On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian <wengxt@gmail.com> wrote:
> (forgot to reply to the list)
>
> On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
>> On Wed, 11 Apr 2018 11:26:22 -0700
>>
>> Weng Xuetian <wengxt@gmail.com> wrote:
>> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
>> > > On Sun, 11 Mar 2018 20:30:14 +0100
>> > >
>> > > Carlos Garnacho <carlosg@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.
>> >
>> > As an long-time input method developer and CJK user, I'd prefer to keep
>> > the
>> > styling. In Chinese or Japanese, partially converted text are common and
>> > styling is useful to help user to distinguish which text is currently
>> > being
>> > converted. [1] But for the sake of in-app consistency, I'd say we don't
>> > need that much capability about styling though. Among all input methods
>> > supported by fcitx [2], only underline/highlight is being commonly used.
>> > Recently I started to use some strike style in only one single input
>> > method though, it can also be useful in certain cases.
>>
>> I think this use case is covered. For indicating what's currently being
>> changed, this protocol is using "preedit string". In GTK, the preedit text
>> is displayed with an underline, making is always clear what the suggestion
>> pertains to.
> I think you can take a closer look at [1].
>
> "葵あ" is the complete preedit text. The input method is converting "葵" and
> giving the candidates for it, the あ part is not yet handled by input method
> (but typed by user and appears in the preedit). That's why "葵" is being
> highlighted.

IIUC, is あ simply unhighlighted till handled by the IM (and the
suggestion menu changes accordingly)? do preedit text styles in other
fcitx IMs convey the same or different info?

I wonder if we are missing some on-the-wire state, rather than text
styling support per se. And given the can of worms styling brings in
(hard to know how to stand out from the IM side, a11y and color
blindness issues, ...), I would personally rather have a hint system
than let the IM meddle with a foreign UI.

>
> In a single CJK text composition, CJK people would type the full sentence
> ahead instead of word by word because this helps input method to understand
> the whole context and improve the prediction.

I'm no CJK expert, so this might not apply neatly, but note there is a
set_surrounding_text request to help IM get context outside the
preedit string. This may even be combined with
delete_surrounding_text+commit_string to alter text outside preedit,
too.

Cheers,
  Carlos
On Thu, Apr 12, 2018 at 12:13:49AM +0200, Carlos Garnacho wrote:
> Hi!,
> 
> On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian <wengxt@gmail.com> wrote:
> > (forgot to reply to the list)
> >
> > On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
> >> On Wed, 11 Apr 2018 11:26:22 -0700
> >>
> >> Weng Xuetian <wengxt@gmail.com> wrote:
> >> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> >> > > On Sun, 11 Mar 2018 20:30:14 +0100
> >> > >
> >> > > Carlos Garnacho <carlosg@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.
> >> >
> >> > As an long-time input method developer and CJK user, I'd prefer to keep
> >> > the
> >> > styling. In Chinese or Japanese, partially converted text are common and
> >> > styling is useful to help user to distinguish which text is currently
> >> > being
> >> > converted. [1] But for the sake of in-app consistency, I'd say we don't
> >> > need that much capability about styling though. Among all input methods
> >> > supported by fcitx [2], only underline/highlight is being commonly used.
> >> > Recently I started to use some strike style in only one single input
> >> > method though, it can also be useful in certain cases.
> >>
> >> I think this use case is covered. For indicating what's currently being
> >> changed, this protocol is using "preedit string". In GTK, the preedit text
> >> is displayed with an underline, making is always clear what the suggestion
> >> pertains to.
> > I think you can take a closer look at [1].
> >
> > "葵あ" is the complete preedit text. The input method is converting "葵" and
> > giving the candidates for it, the あ part is not yet handled by input method
> > (but typed by user and appears in the preedit). That's why "葵" is being
> > highlighted.
> 
> IIUC, is あ simply unhighlighted till handled by the IM (and the
> suggestion menu changes accordingly)? do preedit text styles in other
> fcitx IMs convey the same or different info?

"葵あ" is both part of the pre-edit string, thus would be highlighted by
e.g. GTK+ as far as I know, what we probably want is a semantical way to
communicate that one part of the pre-edit string is currently being
"fine grained". For example, take the following longer string:

賣煎盤

Which means "sell frying pan". What I meant to write, however, was "buy
keyboard", which with some input method is typed in exactly the same
way. To correct the pre-edit string, I'll need to go through the various
parts of the pre-edit string, and a way to highlight what is being fine
grained I think is what is being asked for by Xuetian.

In the above, what the input method might do is first let me correct
賣, letting me select 買. This should be indicated by somehow making me
aware I'm poking at the first character. If it's smart enough, it'd
later let me fine grain the last two characters as one "word", letting
me select "鍵盤", and in this case, both the second and third character
should be highlighted in some way.

Currently in GTK+ with I-bus under gnome-shell, this is currently done
by guessing what character I'm correcting.

> 
> I wonder if we are missing some on-the-wire state, rather than text
> styling support per se. And given the can of worms styling brings in
> (hard to know how to stand out from the IM side, a11y and color
> blindness issues, ...), I would personally rather have a hint system
> than let the IM meddle with a foreign UI.

I think some hint, or some how communicating what is going on without
forcing the toolkit to draw in some specific way, is better as well.

> 
> >
> > In a single CJK text composition, CJK people would type the full sentence
> > ahead instead of word by word because this helps input method to understand
> > the whole context and improve the prediction.
> 
> I'm no CJK expert, so this might not apply neatly, but note there is a
> set_surrounding_text request to help IM get context outside the
> preedit string. This may even be combined with
> delete_surrounding_text+commit_string to alter text outside preedit,
> too.

With CJK, the whole sentance would normally live in the pre-edit for
quite some time before being committed, as described above, so any
surrounding text doesn't make much difference here.


Jonas

> 
> Cheers,
>   Carlos
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Thu, 12 Apr 2018 10:35:04 +0200
Jonas Ådahl <jadahl@gmail.com> wrote:

> On Thu, Apr 12, 2018 at 12:13:49AM +0200, Carlos Garnacho wrote:
> > Hi!,
> > 
> > On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian <wengxt@gmail.com> wrote:  
> > > (forgot to reply to the list)
> > >
> > > On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:  
> > >> On Wed, 11 Apr 2018 11:26:22 -0700
> > >>
> > >> Weng Xuetian <wengxt@gmail.com> wrote:  
> > >> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:  
> > >> > > On Sun, 11 Mar 2018 20:30:14 +0100
> > >> > >
> > >> > > Carlos Garnacho <carlosg@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.  
> > >> >
> > >> > As an long-time input method developer and CJK user, I'd prefer to keep
> > >> > the
> > >> > styling. In Chinese or Japanese, partially converted text are common and
> > >> > styling is useful to help user to distinguish which text is currently
> > >> > being
> > >> > converted. [1] But for the sake of in-app consistency, I'd say we don't
> > >> > need that much capability about styling though. Among all input methods
> > >> > supported by fcitx [2], only underline/highlight is being commonly used.
> > >> > Recently I started to use some strike style in only one single input
> > >> > method though, it can also be useful in certain cases.  
> > >>
> > >> I think this use case is covered. For indicating what's currently being
> > >> changed, this protocol is using "preedit string". In GTK, the preedit text
> > >> is displayed with an underline, making is always clear what the suggestion
> > >> pertains to.  
> > > I think you can take a closer look at [1].
> > >
> > > "葵あ" is the complete preedit text. The input method is converting "葵" and
> > > giving the candidates for it, the あ part is not yet handled by input method
> > > (but typed by user and appears in the preedit). That's why "葵" is being
> > > highlighted.  
> > 
> > IIUC, is あ simply unhighlighted till handled by the IM (and the
> > suggestion menu changes accordingly)? do preedit text styles in other
> > fcitx IMs convey the same or different info?  
> 
> "葵あ" is both part of the pre-edit string, thus would be highlighted by
> e.g. GTK+ as far as I know, what we probably want is a semantical way to
> communicate that one part of the pre-edit string is currently being
> "fine grained". For example, take the following longer string:
> 
> 賣煎盤
> 
> Which means "sell frying pan". What I meant to write, however, was "buy
> keyboard", which with some input method is typed in exactly the same
> way. To correct the pre-edit string, I'll need to go through the various
> parts of the pre-edit string, and a way to highlight what is being fine
> grained I think is what is being asked for by Xuetian.
> 
> In the above, what the input method might do is first let me correct
> 賣, letting me select 買. This should be indicated by somehow making me
> aware I'm poking at the first character. If it's smart enough, it'd
> later let me fine grain the last two characters as one "word", letting
> me select "鍵盤", and in this case, both the second and third character
> should be highlighted in some way.
> 
> Currently in GTK+ with I-bus under gnome-shell, this is currently done
> by guessing what character I'm correcting.
> 
> > 
> > I wonder if we are missing some on-the-wire state, rather than text
> > styling support per se. And given the can of worms styling brings in
> > (hard to know how to stand out from the IM side, a11y and color
> > blindness issues, ...), I would personally rather have a hint system
> > than let the IM meddle with a foreign UI.  
> 
> I think some hint, or some how communicating what is going on without
> forcing the toolkit to draw in some specific way, is better as well.

In a follow-up discussion on #sway-devel between Weng and others, this was the general sentiment. I'm planning to submit an updated draft within the week.

--Dorota
> 
> >   
> > >
> > > In a single CJK text composition, CJK people would type the full sentence
> > > ahead instead of word by word because this helps input method to understand
> > > the whole context and improve the prediction.  
> > 
> > I'm no CJK expert, so this might not apply neatly, but note there is a
> > set_surrounding_text request to help IM get context outside the
> > preedit string. This may even be combined with
> > delete_surrounding_text+commit_string to alter text outside preedit,
> > too.  
> 
> With CJK, the whole sentance would normally live in the pre-edit for
> quite some time before being committed, as described above, so any
> surrounding text doesn't make much difference here.
> 
> 
> Jonas
> 
> > 
> > Cheers,
> >   Carlos
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel