Comments on Weston's text interface
pvuorela at iki.fi
Mon Oct 15 12:35:11 PDT 2012
On ma, 2012-10-15 at 15:30 +0200, Jan Arne Petersen wrote:
> 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
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
> 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.
More information about the wayland-devel