Re: IME events

Hi,

I'm working with Daniel.

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.

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.

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

>
>> * Query the current IME state (mostly possible anyway using
>> compositionstart/end events)
>
> Gecko has such property if the context can use XPConnect (e.g., from add-ons, not web contents). It can check whether it's between compostionstart and compositionend or not.
>
>> * A way for js apps to define input context: E.g. Is this input field
>> for a person's name, for an address, etc?
>
> I think it also useful for autocomplete feature of browsers. I think that it should not be an API, it should be an attr of the editor element.

Agreed.

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

BTW, "-moz-input-scope" and GeckoTIP seem interesting to me.
https://wiki.mozilla.org/Community:SummerOfCode08:TSF
http://geckotip.mozdev.org/faq.html

Thanks,
Takuya Oikawa

Received on Monday, 22 June 2009 08:58:54 UTC