Questions and thoughts about input method protocol

[Weng Xuetian]

On Wednesday 30 January 2013 23:09:20，Pekka Vuorela :
> On 29.01.2013 04:49, Yichao Yu wrote:
> > Hi,
> > 
> > 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 believe it is important to support using input method in x clients
> > running on xwayland. IMHO, the input method can still use xim or it's
> > own protocol to get key event from and send input result (as well as
> > preedit etc.) to the client running on xwayland with no problem.
> > However, I cannot see a perfect solution to make cursor following
> > works using the proposed way to locate the input overlay surface.
> > 
> > For application using xim, maybe it is possible to let xwayland handle
> > the events and then forward them to the text-model. However, first of
> > all, this cannot work for x client talking with input method using a
> > private protocol and it will be a HUUUUGE regression if we force all x
> > clients to use the broken xim (application frozen, wrong support of
> > cursor following and preedit etc.). Moreover, since xim support is so
> > different in different applications, the input method sometimes have
> > to do some hack on xim, which will not very likely be something we
> > want to add in xwayland.
> > 
> > (Maybe adding some interface to interact with xwayland to set cursor
> > position on certain x window surfaces?)
> 
> X based input methods are using X windowing, so wouldn't they just
> continue working for X apps? (Provided that xwayland has the ability to
> put windows into absolute positions). Translation between wayland text
> <-> XIM doesn't seem worthwhile to me.
> 
> > 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.
> 
> Not wanting to ridicule chinese input needs, but fetching window title,
> executable name and/or application parameters to alter behavior is a
> _huge_ hack. Going deeper into knowing what url is visible in a browser
> is even worse. Does not take much effort to break that kind of
> functionality.
> 
> I would try to find better ways to achieve targeted goals. One feature
> I've myself been thinking is virtual keyboard used with messaging app
> knowing what language, or type of language, the recipient is speaking
> and adjusting prediction/layout based on that. That could be done by
> having locale in text editor's state, but alternatively could also be
> editor setting a globally unique identifier (integer, string?) as state
> for text fields, after which text input side could learn what language
> got used. Similarly for chinese input such mechanism could be used to
> remember preferences. Out-of-the box amazon and arxiv wouldn't make
> difference, but after some use they would. To support this, the toolkits
> and applications would also need some enhancements, though.

So, at least, is it possible to let input method server to track different 
input contxt?

The application should keep the input context alive upon it's lifetime (or the 
surface is alive), if I didn't understand it wrong, when application lost its 
focus, the input method will totally lost the track of the state. It is 
important to keep track the status of an application, there is some per 
context info need to be kept as long as the application is alive.

Your idea is very adhoc and it won't scale if input method want to store keep 
custom data.

For example, input method server will want to keep different context to use 
different engine, the language name is simply not enough. Or, user want to 
temporarily disable the word completion for this application, but keep it 
enable for another application. There can be tens of different state 
(generated from input method server side) that input method want to track 
with.

Even the old XIM have done this right, Create a input context, and keep it as 
long as application is alive, then application exit, destroy it. And each 
input context have a unique identifier, which can be used to distinguish what 
input context are connectted inut method.

Regards
Xuetian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130131/6290d29f/attachment.pgp>