Comments on Weston's text interface

[Pekka Vuorela]

On ma, 2012-10-15 at 15:30 +0200, Jan Arne Petersen 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.

And the replies. Do sound quite good. Only some smaller comments inline.

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

Just keep in mind that this capability can change on fly on one editor.
For example password type of field with "show clear text" check box.

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

Makes sense. Does also allow extension protocols to pass other info
before getting committed. 

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

Right, I suppose that synchronous call requirement can be problematic.
Alternatively could have boolean on Text_model::preedit_string to tell
whether preedit should be committed by the application on this type of
situation or even a separate "in case of forced commit" string.