Questions and thoughts about input method protocol

[Jan Arne Petersen]

On 29.01.2013 03:49, Yichao Yu wrote:
> With the comment on the recent patches for the input method protocol,
> it seems that we are finally on the way to support cursor following.
> However I still have some questions about the protocol (and it's
> limitation).
> 
> 1, Is there any plan to support xwayland?

I do not have a plan for that, but it should be possible to add some
protocol so that an input method could tell about a X window and the
cursor position (which it got over some legacy X input method protocol)
and the input panel surface would than be placed correctly on that
xwayland surface.

> 2, Is it possible for the input method to know anything about the client?
> 
> Some famous (Chinese) input methods (on Mac and Windows) support the
> so-called context awareness, in another word, the input method will
> use some information of the client to determine the candidate words
> list (and its order). This may not be that useful for Latin based
> languages (although it may also be good if you want to provide
> spelling hints) but if your are facing a language with 3000-5000
> frequently used characters and frequently used words 10-100 times of
> this number depending on your context, this shouldn't be ridicules at
> all.
> 
> Currently, although I don't know any input method on linux support
> context awareness, it is possible to do this under X since all the
> necessary information is accessible to the input method. These include
> all general information the window system and a plugin running in the
> client's process can know, including (most important and useful)
> window titles (with other WM related properties like icon names,
> application names etc.), pid's (plus host's for X) and window id's
> etc. The pid's and window id's are also very useful for getting more
> information from the underlying system (/proc for example) about the
> client (e.g. command line arguments) and can also be used to provide
> per program or per window input state for some programs (Fcitx support
> both.)
> 
> Right now I don't think there is any way to get these information from
> the input method protocol. It will be a big regression (not as big as
> not supporting cursor following in x clients though) if this cannot be
> supported in wayland.
> 
> NOTE: The "context type" added in the recent patches may also be
> helpful on this but they are different. It is indeed helpful for input
> method to know the user is typing in a url/search bar instead of a
> normal text entry but the stuff you may want to search may be very
> different on amazon and arxiv.

There are two use-cases here:
If you want to add some kind of manual mapping between application and
candidate suggestions used, I would rather add explicit ways for
applications/websites to better specify the content/context of an input
entry.
For candidate suggestions based on previous usage patterns (by the same
user or other users via some remote database) an UID approach as
mentioned by Pekka would be useful.

> 3, Is it possible to let the user move the keyboard panel while
> keeping it off from the cursor position when possible?
> 
> Maybe it is already possible and I just don't fully understand the
> input_panel interface but anyway I guess this should be supported,
> either by the compositor or make it possible to let input methods
> support it.

There is currently no support for that, but it should be possible to add
support for that.

> 4, For running different component of the input method in different processes.
> 
>>From the updated doc string of input_panel, you are saying it is only
> possible for one client to bind to the interface. Well, IMHO, I don't
> really think this is necessary.
> 
> It will be indeed a problem if two input methods both want to handle
> key events on the same seat. This can be easily avoided by only
> allowing one client binding to the input_method interface. The input
> method can just quit/disable wl support/retry later/do what ever it
> want if that bind fails.
> 
> However, for the input_panel interface, I don't really think this is
> necessary. For conflict with another input method, this should be
> already handled by the input_method interface. Also this can increase
> the flexibility of the input method by allowing virtual keyboard and
> input overlay window drawing by two different process (not only just
> in a single process although different with the one binding to the
> input_method interface which get key events).

To the input_panel interface will be bound only by the shell process
(like weston-desktop-shell). input_panel_surfaces can be created by
multiple processes.

> 5, For the proposed input_panel_surface::cursor_position event.
> 
> I guess it will be better to change it to a cursor_rect event which
> also includes the size of the cursor. No?

Yes, that would make more sense.

> 6, Some random stuff of the current interface.
> 
> There seems to be a password context type. I think normally a password
> field will not have input context or is that for using virtual
> keyboard in password field?

Pekka already answered that.

> There seems to be a empty text_model::set_preedit request for the
> client. Shouldn't this be fully controlled by the input method?? (Plus
> there isn't a corresponding event on the input method side.... anyway
> it's just weird for me....)

Yes sorry, I removed it in one of the cleanup commits.

-- 
Jan Arne Petersen
Openismus GmbH
http://www.openismus.com