Input Method Support for Wayland

[Jan Arne Petersen]

Hi,

sorry for the late response, I was on vacation for some days.

On 06/21/2012 11:33 PM, Kristian Høgsberg wrote:
> The protocol looks good, with the caveat that I don't fully understand
> all the preedit stuff.  Most crucial is the text_model interface,
> since that's what all apps are going to interface with.  A few thoughts:
>
>   - Should text_model.activate take a surface so we can hide the OSK if
>     that surface disappears or we focus another surface that doesn't
>     have an active text_model?  Maybe after a slight timeout, in case
>     we give focus to another surface that also needs the OSK.  Or is
>     that what the surface arg is for in input_method.create_text_model,
>     and those things are just not hooked up?  What about enter/leave
>     type events for when another surface is focused (and the text_model
>     deactivated by the compositors)?

I am not sure yet if the surface belonging to the text_model should be 
specified on activate or on creation (like now). In both cases it still 
needs to be hooked up.

>   - input_method.commit_string should only be available to im
>     providers.  As it is now, any client can bind to input_method and
>     start injecting text to whoever has the active text_model.  Could
>     we move it to the intput_panel interface?

Yes, there must not be a mixed interface which handles client and 
im-provider requests (it was just the easiest place to put the 
create_text_model factory method for the demo).

>   - The text_model is specific to a wl_seat, isn't it?  A wl_seat is
>     roughly (at least for the purpose of this) a keyboard focus, and if
>     we support multiple keyboard foci, they'd each need a text_model,
>     no?

Each wl_seat (or keyboard focus) would have an active text_model.

>   - is set_micro_focus a way to indicate the cursor location in the
>     text?  We have a simple "text_cursor_position" protocol so the
>     screen zoom can track the text cursor, it sounds like we should use
>     this request instead?

It seems to be basically the same thing. It would make sense to let 
screen zoom use text_model to get the cursor position.

>   - How would it work if an OSK wants to hide itself (like a
>     discard/close button in the keyboard)?  I guess we can just either
>     destroy the surface and attach a NULL buffer.

I could imagine some performance problems when destroying/recreating the 
surface on every hide/show, but attaching a NULL buffer should work fine.

>   - We don't use the output arg in input_panel.set_surface

The im-provider might want to decide on which wl_output the keyboard 
should be displayed (but needs to be hooked up still).