[PATCH 18/18] text: Move input_panel interface to input-method

[Yichao Yu]

On Thu, Jan 17, 2013 at 8:24 AM, Jan Arne Petersen
<jpetersen at openismus.com> wrote:
> On 16.01.2013 23:34, Weng Xuetian wrote:
>> On Wednesday 16 January 2013 21:26:55，Jan Arne Petersen :
>>> From: Jan Arne Petersen <jpetersen at openismus.com>
>> So what's the plan for show input panel at the position of the current focused
>> cursor?
>
> Input panel surfaces are introduced by this patch to allow adding
> support for such features. I plan to add an
> input_panel_surface::set_cursor_popup() request for that (or we could
> add a follow_cursor item to the position enum and use ::set_toplevel).
>
>> In that case it's more complicated, in all current implementation, by default
>> is shown at the bottom of the rect, with some offset. And if you take offset
>> into consideration, you will miss the part that in X we can know everything
>> about the screen, input method will want to keep the input panel in one screen
>> in multi screen settings.
>
> The compositor should make sure that the popup is inside a screen (there
> is already some code around which did that for popup surfaces and which
> we could reuse for the use case of input panel popup surfaces).

One concern here, for the surface that is set to following the cursor,
the compositor is free to move it around (the cursor) if the size of
the panel changes. However, for a virtual keyboard panel, I guess it
would be nice if it can popup at a position not really far away but
definitely not right above the cursor (or the user cannot see what
he/she is typing) and it is also nice to let the user move it around.
Is there any plan to support this? (IMHO having a fixed position
request (i.e. bottom center) is not really a great idea...)

>
>> And some fancy implementation use a comic style popup, which have a pointer
>> points to the current position, http://wstaw.org/m/2012/08/31/gs-kimpanel.png
>> . While keep the input panel inside one screen, the pointer will still point
>> to the exact position of current cursor rect.
>
> I would propose to add an input_panel_surface::cursor_position(x, y)
> event (x and y relative to the input panel surface), so that input
> methods can paint the arrow at the right position.

Great! Maybe to ask the input method to explicitly repaint the input
surface in response to this event in order to avoid blinking on the
panel (or if the compositor decide to provide animation of input panel
repaint (like what it is not in e17), this should happen after the
repaint is done.)??

>
> Jan Arne
>
> --
> Jan Arne Petersen
> Openismus GmbH
> http://www.openismus.com
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel