Input method and input/output redirect under wayland

[Jan Arne Petersen]

On 08/31/2012 01:06 AM, Yichao Yu wrote:
>> The im server would not get the cursor location itself but just request
>> to get its overlay window positioned at the cursor.
>>
> 
> What about the relative position to the cursor?
> 
> For example, the overlay window might contain both a "preedit" and a
> vertical candidate list (which is pretty common) and suppose the input
> surface is close to the edge of the screen. Obviously, we want to put
> the overlay window inside the screen (if possible). So who will be in
> charge of the window positioning?
> 
> AFAIK, the im server (as a wayland client) cannot do this because it
> has no idea where the edge of the screen is, and if we let the
> compositor position the window, the im server will not be able to set
> the orientation of the overlay window accordingly. For example, when
> it is closed to the bottom[1] or not[2]. This is actually the simplest
> case, things can be more tricky if the overlay window is too large
> (can happen if the screen is small and if you choose to position
> candidate words horizontally). Someone (either the compositor or the
> imserver) MUST know the both size of the window and the edge of the
> screen in order to position the overlay correctly, and the im-server
> MUST at least know the relative position to the cursor in order to set
> the content of the overlay window correctly. So isn't it better to add
> some interaction between compositor and im-server here?

The compositor will send an event to the im-server telling the im-server
where the cursor is relative to the overlay surface (i.e. bottom-left,
top-left etc).

>>> I am also interested in whether this information can be passed and
>>> used by another process (another wayland client)? It is possible now
>>> to draw the input method interface by another process examples are
>>> kimpanel[1] and kimtoy[2] both of which use a custom dbus protocol to
>>> get information from the im server and draw the overlay window for it.
>>> This is important for having a native user interface (kimpanel use
>>> plasma-widget), keeping the im-server simple and reducing its
>>> dependence (it doesn't need to worry about rendering or theming or any
>>> kinds of eye candy etc.).
>>>
>>> Is it possible to add support for this (let a separate wayland client
>>> to render the inteface)? Many im framework (including Fcitx and IBus)
>>> already support this and it'll also be a lot easier for us to port our
>>> imf to wayland (and keep X support at the same time) if this feature
>>> can be supported.
>>
>> I have not really thought about input methods distributed over multiple
>> processes/clients yet. But we will find a way to make it work.
> 
> For Fcitx, it is not that crucial since we have "classic ui" which is
> in process (although kimpanel looks a LOOOOT better IMO). But IBus
> will definitely require this feature. It is multi-process itself and
> it gets input (from xim for example) and draw the interface in
> different processes which communicate with each other through a
> private dbus server... It is very likely to be a disaster for ibus if
> this information cannot pass across processes/wayland client.

Maybe I was not clear enough, but one of my goals is to make Wayland
input method work with IBus. So there will be definitely a solution and
I already have some ideas in mind how to make it work.

> Also, what about the support for toolkit specific im-module? Can the
> im-server get any information about the input surface and how to draw
> the overlay correctly if it communicate with the (im) client through a
> private protocol. (which is the case for most im server right now
> afaik.)

No. It does not make sense to have a wayland and private protocol in
parallel (with the need to synchronize between them etc). With the
wayland protocol in place I do not see a need for an additional private
protocol anyways.

Regards
Jan Arne Petersen