Re: IME events

On Sat, Jun 20, 2009 at 1:51 AM, Masayuki Nakano <masayuki@d-toybox.com>wrote:

> On 2009/06/18 19:11, Takuya Oikawa wrote:
>
>> On Tue, Jun 16, 2009 at 11:56 AM, Masayuki Nakano<masayuki@d-toybox.com>
>>  wrote:
>>
>>>
>>> On 2009/06/15 13:52, Daniel Danilatos wrote:
>>>
>>>>
>>>> IME API
>>>>
>>>> * Control the IME Candidate window (get/set position, ability to prevent
>>>> it from showing up at all, etc)
>>>>
>>>
>>> Applications cannot control the candidate window position via TSF,
>>> probably. However, if browsers implement to render the candidate window
>>> themselves, we can. But gecko doesn't have such plan. Because most users
>>> don't happy. The candidate window should have native looks of the IME.
>>>
>>
>> Yes, it's true.  TSF's UIless mode
>> (http://msdn.microsoft.com/en-us/library/aa966970.aspx) provides you
>> to disable the candidate window.  So, the browsers can implement to
>> render the candidate window themselves.
>>
>> For most of the cases, as you said, there is not so strong need to
>> have browsers render the candidate window.  However, if the browsers
>> also have the function to control the candidate window and its
>> function is published as JavaScript to Web applications, Web
>> applications may use it.  For example, as some might have already
>> pointed out, Search suggest (i.e. Google Suggest or Yahoo! Suggest)
>> cannot handle the conflict of UI (overwrapping UIs of the suggest
>> window and IME's candidate window) now, but if Browsers' JavaScript
>> can control the behavior, they will probably use it.
>>
>
> The candidate window is not just a list of the candidate strings at ATOK.
> ATOK gives some advices of the selected word to the users. And also users
> can access to the word meaning of dictionaries. So, I think that the Web App
> developers should not kill such IME features.


I know.  MS-IME also has such features (annotations, usage/meanings, etc.).
 However, the most basic feature that all IMEs should have is the Japanese
conversion.  I don't say that Web Apps can kill those additional/rich
functions.  What I want to say is that it would be better to have Web Apps
(via Browsers) control the behavior of IME including the control of the
position of the candidate window or even enabling/disabling the candidate
window.  If we have such features, even in the worst case that we don't have
any other solutions, Web Apps can still give users the Japanese conversion
candidates and unconflicting UI.  This is my intention behind this proposal.



>  Or, as TSF's UIless mode is mostly used by game titles, if web-based
>> (browser-based) applications become popular, they also would like to
>> disable the IME's candidate window.
>>
>
> I'm not sure that it makes the users happy. Do the users input comfortable
> without IME's candidate window?


For such limited scenario, users seem happy as their main goal is to play
game titles where it's very rare to have richer functionalities of IMEs.
 What they need to do with IMEs is to type Japanese.


>  And also we cannot control it on Cocoa, probably. Cocoa applications
>>> should implement |firstRectForCharacterRange| of NSTextInput protocol. And
>>> IMEs can decide the candidate window position by its result.
>>>
>>
>> I'm not sure the implementation of Cocoa.  What I discussed with
>> Daniel was that we should consider both short-term solution and
>> long-term solution.  For the latter, we should involve platform/OS
>> developers who are responsible for input framework and browser vendors
>> to discuss the use cases and solutions.  We are aware that it takes
>> long.
>>
>
> Right.
>
> Basically, I believe that we should not limit/change the behavior of IMEs
> more than the *users* needed. There are many IMEs, IME frameworks, OSs and
> devices. I think that some IME APIs for web applications cannot support on
> some environments that includes new products that will be coming in the
> future. Web applications should not choose the environments by the IME
> management.


Agreed. That's why I think we need to have some consensus or standard for
all of these different layers even though it takes long.  I think it's okay
to have Web Apps control the behavior of IMEs because local applications can
do today.  Of course, having such functionalities in Web Apps (via Browsers)
don't mean that it's recommended.  However, for some scenarios which
controlling the IMEs' behaviors is the only option, we should have any
means, I think.


>  IMEs can use this information
>>>> to provide better suggestions. The TSF api allows properties to be
>>>> specified on text, perhaps some of this should be exposed in HTML?
>>>> Thoughts welcome.
>>>>
>>>
>>> Does TSF have the feature? Which interface and method support it?
>>>
>>
>> I think one of the appropriate API is SetInputScope.
>> http://msdn.microsoft.com/en-us/library/ms840434.aspx
>> and the pre-defined contexts are here.
>> http://msdn.microsoft.com/en-us/library/ms840430.aspx
>>
>
> Thank you for the information!
>
> --
> Masayuki Nakano <masayuki@d-toybox.com>
> Manager, Internationalization, Mozilla Japan.
>