Input method and input/output redirect under wayland

[Yichao Yu]

On Fri, Aug 31, 2012 at 4:49 AM, Jan Arne Petersen
<jpetersen at openismus.com> wrote:
> 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).
>

And also a relative position (for this case[1])?
And would it be better if the im-server can at least request for
preferred order of acceptable positioning ways if you want to do it
this way? Clip by the screen is almost always the worst thing, but
either shifting the overlay[1] or position it in another direction (my
previous screen shots) may be a better way depending on the situation.

[1] http://wstaw.org/m/2012/08/31/gs-kimpanel.png

>>>> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel