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? _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
