[PATCH 0/5] Input method support cleanup

[Yichao Yu]

On Thu, Jan 31, 2013 at 3:18 PM, Jan Arne Petersen
<jpetersen at openismus.com> wrote:
> On 31.01.2013 16:38, Yichao Yu wrote:
>> On Thu, Jan 31, 2013 at 9:52 AM, Jan Arne Petersen
>> <jpetersen at openismus.com> wrote:
>>> From: Jan Arne Petersen <jpetersen at openismus.com>
>>>
>>> Another series of input method support patches. Mostly some
>>> cleanups in the protocol:
>>>
>>> * Remove some unused requests events (set_preedit etc)
>>>
>>> * Add a commit request to allow to batch different state
>>>   changes on application side together. That needs some more
>>>   documentation (also how it works in the other direction on
>>>   preedit_string and commit_string events).
>>>
>>
>> Does it mean asking the input method to commit what it have now?
>
> That request is used the other way around telling the input method that
> it should handle the state (surrounding text, preferred language,
> content purposes/hints) sent by the application at one atomic point.
> Similar to wl_surface::commit.

I c. Waiting for more documentation then. :P

>
>>> * Add show/hide input panel requests to allow not always shwoing
>>>   input panels when activated (for example requiring an extra touch).
>>
>> Is this a per-text_model state and will it be remembered after the
>> text_model is reset? What's the difference between not activating a
>> text_model and not showing the input panel? And what about the
>> proposed input overlay window? That's something the client should
>> never ever want to hide.
>
> Some toolkits like EFL and Qt allow a focused text field (which can get
> text by hardware keyboard) but require an extra touch (or whatever) to
> show a virtual keyboard.
>
> I guess we should have a input_panel::set_always_show request for such
> input overlay windows related to input from a hardware keyboard. Would
> be also useful for an input panel which shows extra symbol keys for a
> mobile phone hardware keyboard.

I think similar functionality can also be implemented purely by the
input method and I agree it is also important to support toolkit(s)
that has such feature. I am just wondering if the map/unmap needs to
be handled directly by the compositor or is it just enough to simply
pass the event to the input method so that it can respond equally when
a client request to show the virtual keyboard and when the user
request the virtual keyboard to be shown directly to the input method
(e.g. by a pressing small cursor following  button as I mentioned.)

>
> --
> 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