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

[Weng Xuetian]

This look much more promising from input method point of view comparing with 
previous version. I tried to implement inputmethod protocol v1 for wayland in 
fcitx quite some time ago, but I never put it in real use because.. it's not 
really practical comparing with what we have in customized im module.

Personally I liked be able to limit the amount of surrounding text .. I had to 
implement that manually in im module before to avoid unnecessarily sending 
large amount of string.

One thing that I dislike in input-method v1 is that input method context is 
destroyed after it lost focus, tbus it's not possible track a window(surface) 
and remember some specific state (e.g. using different engine for different 
surface), is that planned to be improved in the future?

See my other comments below.

On Monday, 14 March 2016 12:58:27 PDT Jan Arne Petersen wrote:
> +    <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 be also 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>
> +
> +
> +    <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).
> +
> +	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>
> +

>From my experience of developing a Qt immodule, Qt's surrounding text is 
actually causing some trouble to me recently because deleteSurroundingText is 
actually behave differently in Qt and Gtk. So I hope this update to protocol 
description should cover this part.

1. will preedit string be counted in surrounding text?
I assume no, because no toolkit currently did this and it would be headache 
for input method engine author if so.

2. what happens to selected text if delete surrounding text happens?
This is never clear and behavior is currently different in different toolkits. 
I hope we can have answer of following questions covered in this protocol, 
I'll also give my suggestion to this answer below.
- what will happen to currently selected string after commit string
  * I expect currently selected string being replaced
- what will happen to currently selected string after deleting surrounding 
text
  * do nothing to currently selected string
- where is the cursor after committing string
  * cursor advance to the send to committed string
- where is the cursor after deleting surrounding text .
  * keep the cursor/anchor as it is if cursor/anchor is outside of the deleted 
text
  * if cursor/anchor is covered by deleted range, move it to the edge of 
deleted range, for example
    suppose we have string: ABCDE, cursor is 1, anchor is 4. If deleting 
surrounding text with (-1, 2), we have CDE, cursor is 0, anchor is 2. If with 
(1, 1), text is ABDE, cursor is 1, anchor is 3.