- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Mon, 13 Sep 2010 16:10:48 +0200
- To: Doug Schepers <schepers@w3.org>
- Cc: DOM public list <www-dom@w3.org>
- Message-ID: <AANLkTikBiYLhT7CBJ56mXfbeSEe8ByjrP+Nr+E4ShmHd@mail.gmail.com>
The short answer is that I do not really know. However, a few minutes Googling it for Windows got me to GetKeyboardLayout<http://msdn.microsoft.com/en-us/library/ms646296(v=VS.85).aspx> and WM_INPUTLANGCHANGE<http://msdn.microsoft.com/en-us/library/ms632629(v=VS.85).aspx>, which certainly sound useful. Andrew Cunningham has expressed doubts that Linux exposes this kind of information in any unified way, given the various input frameworks available there. I have no idea one way or the other. Aharon On Sun, Sep 12, 2010 at 6:03 PM, Doug Schepers <schepers@w3.org> wrote: > Hi, Aharon- > > Just as a data point, can you tell us a bit about the underlying OS support > for generating this information? Is it supported on all major desktop > platforms (Linux, Windows, MacOS), and on major mobile platforms? Do you > know the specific names of the platform methods to access this info? > > How much of a burden on implementations would it be to retrieve this > information for each spawned event? Do the platforms tell the > implementation when this is changed, so that there could be a default value > plugged into the event, rather than queried each time it's needed? > > Thanks- > -Doug > > Aharon (Vladimir) Lanin wrote (on 9/12/10 11:11 AM): > > From what I can see, the message with the exact language of the >> proposal >> (http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0075.html) hasn't >> been >> referenced for issue 119. It's as follows: >> >> Proposal: An additional property in the TextEvent and KeyboardEvent >> DOM3 interfaces to indicate the locale of the keyboard or other input >> device using which the input was generated. When this is unknown (e.g. >> when the input method is paste, or when the implementation can not >> obtain this information from the underlying platform), the property >> should be null (or perhaps undefined, whichever conforms to DOM3 >> conventions better). >> >> Here is a draft for the documentation of the new event attributes, >> striving to conform in style to >> >> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-textevents >> >> In TextEvent: >> >> inputLocale of type DOMString, readonly >> A BCP-47 tag indicating the locale for which the origin of the >> event (whether keyboard, IME, handwriting recognition software, or other >> input mode) is configured, e.g. "en-US". May be null [undefined?] >> when inapplicable or unknown, e.g. for pasted text or when this >> information is not exposed by the underlying platform. >> >> Note: inputLocale does not necessarily indicate the locale of the >> data or the context in which it is being entered. For example, a French >> user often may not switch to an English keyboard when typing English, in >> which case the inputLocale will still indicate French, even though the >> data is actually English. >> >> In KeyboardEvent: >> >> inputLocale of type DOMString, readonly >> A BCP-47 tag indicating the locale for which the keyboard used >> to generate the event is configured, e.g. en-US. May be null >> [undefined?] when unknown, e.g. when this information is not exposed by >> the underlying platform. >> >> Note: inputLocale does not necessarily indicate the locale of the >> text that the user may be keying in. For example, a French user often >> may not switch to an English keyboard when typing English, in which >> case the inputLocale will still indicate French. Nor can it be used to >> definitively calculate the "physical" or "virtual" key associated >> with the event, or the character printed on that key. >> > >
Received on Monday, 13 September 2010 14:11:42 UTC