Questions and thoughts about input method protocol

[Yichao Yu]

On Fri, Feb 1, 2013 at 3:40 AM, Jan Arne Petersen
<jpetersen at openismus.com> wrote:
> On 01.02.2013 09:21, Pekka Paalanen wrote:
>> On Thu, 31 Jan 2013 17:45:25 -0500
>> Yichao Yu <yyc1992 at gmail.com> wrote:
>>
>>> On Thu, Jan 31, 2013 at 5:19 PM, Pekka Vuorela <pvuorela at iki.fi> wrote:
>>>> Problem with window titles and all is that they are information not meant to
>>>> input method. Those are meant for the user and can change any time and to
>>>> anything. And using those will require application specific logic in the
>>>> input method, like specific rules for specific application.
>>>> Don't see that feasible except for very special cases.
>>>
>>> They will never change to random things and the only necessary thing
>>> to do is keyword matching. And it will able to work for most cases
>>> unless you have a window title like "window 1".
>>
>> Hi Yu,
>>
>> I have a trivial example of an application that will always have a
>> random window title: a terminal.
>>
>> The window titles of my terminals in X show the current working
>> directory and some other environment variables. There is no way you can
>> use the window title to infer anything useful, especially when it is a
>> matter of user's shell and prompt preferences. It does not say
>> "terminal" or "bash" anywhere. There is no keyword you could match.
>> Also, other apps that run in the terminal, may or may not set the window
>> title to their own random things.
>>
>> Web browsers are actually the same. There is nothing requiring the
>> browser name or website URL to be in the window title. You simply
>> cannot trust it. In fact, in many cases on desktop, there can be an
>> icon next to the title, and in that case it is just waste of space to
>> have the application name in the window title.
>>
>> As you are now creating a new common protocol, you have a chance to
>> design things to be reliable from the start. If you need more
>> information from clients, add explicit protocol for it, and specify
>> exactly what you want, and how it can be used.
>
> In addition please take into account that input methods are not a way to
> fix missing features, bugs, etc in applications. New explicit APIs will

This is not a bug of missing feature in applications.

> need support by toolkits and applications and yes there will be
> applications which will be broken or not input method friendly or
> whatever. But with touch based phones, tablets etc more an more people
> will use input methods (via virtual keyboards) and applications will
> improve their support.

Well, but for such a problem that may not be experienced by non-CJK
users, more input method users doesn't necessarily means more likely
to get fixed.
E.g. for non-cjk input method, there is likely to be only one per
language (which is likely to be a keyboard layout). They normally
never need cursor following window, don't have dozens of internal
states. Even the use of preedit is not that common. Not to mention
improved input experience by allowing the input method to know the
context.

>
> --
> Jan Arne Petersen
> Openismus GmbH
> http://www.openismus.com