Re: IME events

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.

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

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

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

Received on Friday, 19 June 2009 16:53:31 UTC