Hi Sergey, So if a user wants to input Unicode U+00E5(alt + a in mac but it's not the same as in windows), user should say that "keyUnicode(229)". Without using this, user can input the same via the keyPress(alt)+keyPress(a) assuming locale is en_US and this works only for the mac and it may require different key combinations on different platforms and it may work only for a subset of the entire Unicode set because of the limited number of hardware keys. Moreover system locale being common shared setting across system, changing it internally is not advisable because other java application may need to set it to a different locale via core java api's. Hence there is only way to input the unicode keys i.e., via the new api keyUnicode(Unicode point). I assume you agree to this. Please comment if you disagree to this.
Assuming to agree to above, keyCode in KeyEvent refers to the virtual key codes as defined in their respective platform implementation. Since my change brings in the Unicode key input we don't need to set the keyCode but a new field unicodeKey which would contain the respective Unicode key that was input at the start. This brings an entire new sequence of change which does not impact in any way with the existing keyPress()/keyRelease() mechanism. Hope am clear here or we can discuss this over the coming Wednesday call. Please correct me if I am wrong anywhere here. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, April 24, 2018 10:52 AM To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com>; awt-dev@openjdk.java.net Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. On 23/04/2018 21:28, Shashidhara Veerabhadraiah wrote: > [Shashi] Yes it was checked without my changes in. Robot key events is a > different method of input compared to the external input method. Robot > Unicode key input api uses the Unicode code point as input and our keyboard > language remains same. So for ex., keyboard language is set to US and if we > want to input Russian language(Cyrillic U+0400 onwards) into a component, we > can use the newly formed Unicode input api. Otherwise in the case of external > input method, we would need to change the keyboard language to Russian and > then input only Russian keys using the physical keys and switch back to US > keyboard style to input the US symbols. The later way is not required to be > done by the current robot Unicode implementation. Hence with this > implementation the user can simply say as "keyUnicode(1024)"(U+0400) without > changing the keyboard language. You describe two different cases: - If you generate an event for some char like 'å' in the current locale and can obtain which keyCode is assigned to this char, then it is the same as generate event for this keyCode. In this case the changes in classes other than Robot are not necessary. - If you generate an event for some char like 'å' in some other(not currently used locale) and cannot obtain which keyCode is assigned to this char, then it is the same as generate "type" event for Chinese char. In this case the changes in classes other than Robot are not necessary, because it should work in the current java apps(On macOS this character "å" may be generated by "alt+a" in US locale).
