Comments on Weston's text interface

Yichao Yu yyc1992 at
Mon Oct 15 11:05:30 PDT 2012

On Mon, Oct 15, 2012 at 9:30 AM, Jan Arne Petersen
<jpetersen at> 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
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at

More information about the wayland-devel mailing list