Comments on Weston's text interface

[Pekka Vuorela]

Hi guys,

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.

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

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.

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?

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.

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.

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.

Text_model::set_micro_focus. Expect name comes from Qt4. Maybe change to
set_cursor_rectangle as was done for Qt5? 

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.

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?

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.

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?