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

[Jan Arne Petersen]

Hi,

Thanks for the feedback.


On Thu, Mar 24, 2016, 00:55 Weng Xuetian <wengxt at gmail.com> wrote:

> 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?
>

Yes, I first want to get the text protocol ready. But yes the input-method
protocol will be completely redesigned also.


> 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.
>

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.


> 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.
>

Yes it should not. We can document that.

2. what happens to selected text if delete surrounding text happens?
> This is never clear and behavior is currently different in different
> toolkits.
>

Yes there are differences between Qt, Gtk+, EFL or Android in this regard.

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
>

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.


> - what will happen to currently selected string after deleting surrounding
> text
>   * do nothing to currently selected string
>

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)


> - where is the cursor after committing string
>   * cursor advance to the send to committed string
>

That is in all above toolkits the case.


> - 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.
>

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).

I will update the protocol for that.

Thanks
Jan Arne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160326/f197fb42/attachment.html>