<div dir="ltr"><span>Hi,</span><div><br></div><div>Thanks for the feedback.</div><div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 24, 2016, 00:55 Weng Xuetian <<a href="mailto:wengxt@gmail.com" target="_blank">wengxt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This look much more promising from input method point of view comparing with<br>
previous version. I tried to implement inputmethod protocol v1 for wayland in<br>
fcitx quite some time ago, but I never put it in real use because.. it's not<br>
really practical comparing with what we have in customized im module.<br>
<br>
Personally I liked be able to limit the amount of surrounding text .. I had to<br>
implement that manually in im module before to avoid unnecessarily sending<br>
large amount of string.<br>
<br>
One thing that I dislike in input-method v1 is that input method context is<br>
destroyed after it lost focus, tbus it's not possible track a window(surface)<br>
and remember some specific state (e.g. using different engine for different<br>
surface), is that planned to be improved in the future?<br></blockquote></div></div><div></div><div><br></div><div>Yes, I first want to get the text protocol ready. But yes the input-method protocol will be completely redesigned also.</div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
See my other comments below.<br>
<br>
On Monday, 14 March 2016 12:58:27 PDT Jan Arne Petersen wrote:<br>
> + <event name="commit_string"><br>
> + <description summary="commit"><br>
> + Notify when text should be inserted into the editor widget. The text to<br>
> + commit could be either just a single character after a key press or the<br>
> + result of some composing (pre-edit). It could be also an empty text<br>
> + when some text should be removed (see delete_surrounding_text) or when<br>
> + the input cursor should be moved (see cursor_position).<br>
> +<br>
> + Any previously set composing text should be removed.<br>
> + </description><br>
> + <arg name="serial" type="uint" summary="serial of the latest known<br>
> text input state"/> + <arg name="text" type="string"/><br>
> + </event><br>
> +<br>
> +<br>
> + <event name="delete_surrounding_text"><br>
> + <description summary="delete surrounding text"><br>
> + Notify when the text around the current cursor position should be<br>
> + deleted.<br>
> +<br>
> + Index is relative to the current cursor (in bytes).<br>
> + Length is the length of deleted text (in bytes).<br>
> +<br>
> + This event should be handled as part of a following commit_string<br>
> + or preedit_string event.<br>
> + </description><br>
> + <arg name="index" type="int"/><br>
> + <arg name="length" type="uint"/><br>
> + </event><br>
> +<br>
<br>
>From my experience of developing a Qt immodule, Qt's surrounding text is<br>
actually causing some trouble to me recently because deleteSurroundingText is<br>
actually behave differently in Qt and Gtk. So I hope this update to protocol<br>
description should cover this part.<br></blockquote></div></div><div><br></div><div>Yes there are currently indeed differences between toolkits but i am not sure we can really unify them with these protocol completely but we should indeed document the expected behavior for input widget. We might also want to add some kind of capabilities request, where the client can provide supported features.</div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1. will preedit string be counted in surrounding text?<br>
I assume no, because no toolkit currently did this and it would be headache<br>
for input method engine author if so.<br></blockquote></div></div><div><br></div><div>Yes it should not. We can document that.</div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. what happens to selected text if delete surrounding text happens?<br>
This is never clear and behavior is currently different in different toolkits.<br></blockquote></div></div><div><br></div><div>Yes there are differences between Qt, Gtk+, EFL or Android in this regard.</div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I hope we can have answer of following questions covered in this protocol,<br>
I'll also give my suggestion to this answer below.<br>
- what will happen to currently selected string after commit string<br>
* I expect currently selected string being replaced<br></blockquote><div><br></div><div>That happens in all above toolkits. But for Gtk+ (in contrast to the other three toolkits) current selection does not get replaced for pre-edit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- what will happen to currently selected string after deleting surrounding<br>
text<br>
* do nothing to currently selected string<br></blockquote><div><br></div><div>Note that we support delete surrounding only in combination with pre-edit/commit (so I expect toolkits to behave the same as commit/pre-edit)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- where is the cursor after committing string<br>
* cursor advance to the send to committed string<br></blockquote><div><br></div><div>That is in all above toolkits the case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- where is the cursor after deleting surrounding text .<br>
* keep the cursor/anchor as it is if cursor/anchor is outside of the deleted text<br>
* if cursor/anchor is covered by deleted range, move it to the edge of<br>
deleted range, for example<br>
suppose we have string: ABCDE, cursor is 1, anchor is 4. If deleting<br>
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.<br></blockquote><div><br></div><div>I think it helps to redefine delete_surrounding in a way similar to Android delete_surrounding(before_length, after_length), which deletes around the current cursor (or selection).<br></div><div><br></div><div>I will update the protocol for that.</div><div><br></div><div>Thanks</div><div>Jan Arne</div></div></div></div>