On Mon, Oct 15, 2012 at 9:30 AM, Jan Arne Petersen <[email protected]> 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 > 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. 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 > http://www.openismus.com > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
