Comments on Weston's text interface

[Yichao Yu]

On Mon, Oct 15, 2012 at 9:30 AM, Jan Arne Petersen
<jpetersen at openismus.com> wrote:
> Hi,
>
> On 10/02/2012 10:29 PM, Pekka Vuorela wrote:
>> As mentioned earlier, I've been checking out a bit how the input method
>> interface "text" has been proceeding in Weston. Nice stuff on the editor
>> and virtual keyboard apps. Based on those, I came up with bunch of
>> questions, suggestions and comments.
>
> Thanks for all the suggestions.
>
>> First, how does this and normal hardware keyboard events play along?
>>
>> Text_model description says "Using this interface removes the need for
>> applications to directly process hardware key events and compose text
>> out of them." Does it mean that for input methods composing hardware key
>> events, application will still receive the events but can, and should,
>> discard them, or that hardware keyboard events used for input
>> composition will be filtered out?
>>
>> Also there's separate text_model::key event the virtual keyboard uses
>> for sending non-textual input. I wonder if that's really needed or could
>> wl_keyboard::key be used instead to keep things simpler. Composition
>> then filtering out key events consumed by it. (There could be some very
>> special apps wanting both input method input and key events creating it,
>> but not necessarily important need enough.)
>
> Filtering out key events which are consumed by input methods seems to be
> the best solution. I will try to reuse the wl_keyboard interface if
> possible.

Just want to make sure. Is it possible for input method to filter out
a keyevent and send back another one? Should be similiar to the case
when you press a non-letter key on a virtual keyboard right?

>
>> To keep hardware keyboard based input in mind, I think it would make
>> sense to implement input method using such in addition to the virtual
>> keyboard. As an example Gtk+ has this nice "simple" input context which
>> tracks when user presses ctrl-shift-u and allows to enter unicode value
>> as preedit after that. Something similar would be nice.
>
> Yes, that is on my list.
>
>> Then to separate requests and events.
>>
>> Text_model::set_surrounding_text. Sometimes, e.g. on terminal, the
>> surrounding text is not available. How does input method know that's the
>> case compared to surrounding text being just an empty string?
>
> Having some kind of capabilities flags for something like that would be
> good.
>
>> Related: input method needs for widget state information tend to
>> increase occasionally and when coupling editor and keyboard tighter
>> together. Any idea how extensions and new information should be added
>> when needed? Requirement could be input method knowing when an atomic
>> state change is fully passed on.
>
> I think we should have an explicit commit request (as it was added to
> wl_surface in
> http://lists.freedesktop.org/archives/wayland-devel/2012-October/005762.html)
> also in the text_model to allow atomic state changes when we add more
> state information.
>
>> Text_model::activate is vague on what activation means. Signals that
>> input method in general will be accepted? Could need additional request
>> for showing virtual keyboard in that case. Some apps might want to e.g.
>> require additional mouse click on focused widgets to request the virtual
>> keyboard.
>
> I would not mind to split activate into focus-in and showing an input panel.
>
>> Text_model::reset could have a text_model::commit request in addition.
>> Reset is nice on editor::set_text() cases while commit when removing
>> focus or moving cursor around.
>
> Yes, that would be really useful, it would just need to be synchronous,
> so that the text is commited at the old cursor position before the
> cursor is moved to a new position.

So is it possible for input method to distinguish between a commit and
a commit_on_unfocus event. The latter one is not always wanted.

>
>> Text_model::set_micro_focus. Expect name comes from Qt4. Maybe change to
>> set_cursor_rectangle as was done for Qt5?
>
> There is also text_cursor_position::notify currently, which is basically
> the same, we will need to unify that.
>
>> Text_model::set_preedit. For allowing Harmattan style word activation?
>> I'd tend to skip this for now. Input method should have better knowledge
>> on what parts of text could be activated and should be able to do that
>> with interfaces given to it. Yes, will have problems editing rich text
>> (oh joy), but that could be solved separately.
>
> Yes, I agree.
>
>> Text_model::preedit_styling. How should this event be consumed to avoid
>> rendering without and with the styling? Could include styling
>> information already in preedit event?
>
> Instead of an explicit commit, I would propose to emit the styling
> events before the preedit_string event they belong to is emitted.
>
>> Text_model::preedit_string. Index is passed as uint. What if input
>> method doesn't want a cursor shown? Could be also considered as styling
>> information since it's only a visual cursor.
>
> Yes we could have it separate as a styling like information.
>
>> Text_mode::commit_string. Commonly cursor stays at the end of committed
>> text. How about changing type to int and being relative to end of
>> inserted text, so 0 could be the common value?
>
> Good idea. I will implement that.
>
> Thanks
> Jan Arne
>
> --
> Jan Arne Petersen
> Openismus GmbH
> http://www.openismus.com
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel