[PATCH 0/5] Input method support cleanup

[Yichao Yu]

On Thu, Jan 31, 2013 at 4:00 PM, Yichao Yu <yyc1992 at gmail.com> wrote:
> 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.)

And in this way, there will be no need for the compositor to worry
about whether to reset the state on focus changes or whether to show
the input panel for different context, as the input method will be
able to track this state (along with dozens of other states) if the
input_context is not stateless anymore. It will also be a lot more
flexible in this way.

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