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