Comments on Weston's text interface

[Jan Arne Petersen]

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.

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

> 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