<AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Semyon Sadetsky semyon.sadetsky at oracle.com
Wed Aug 23 15:01:29 UTC 2017


On 08/22/2017 09:32 PM, Shashidhara Veerabhadraiah wrote:

> Hi Semyon, As I see the case there are multiple paths to display 
> characters onto a window, either by physical keyboard, soft keyboard 
> or simulating a key event. I think the simulating a key event provides 
> a superset of the keys that can be simulated whereas other methods 
> provides only a subset of this superset.
>
> This superset is enabled via the platform provided api which was 
> designed to handle or produce the superset of key events. We simulate 
> the key events via the Java Robot. Now this robot does not honor the 
> non-ascii chars because of the very implementation. After this change 
> that barrier is opened up to provide access to other languages as 
> well. One can input decimal values of non-ascii chars thro’ robot and 
> get them displayed on to the window.
>
It is enabled by some platforms. I am not sure that this is equivalent 
to the normal user interaction to the GUI. Since this is not a true 
emulation and it cannot be uses for testing because in that case the 
event sequence would be different from the real one.

--Semyon
>
> Thanks and regards,
>
> Shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, August 23, 2017 12:28 AM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 
> be able to use extended key code characters as ? ? ?.
>
> Because press/release keycodes are not the same as characters. 
> Character is produced from keycode or sequence of keycodes according 
> to the selected kayboard layout.
>
> --Semyon
>
> On 08/22/2017 11:30 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi, Why not if the platform offers a way to simulate Unicode
>     keyboard events? Here the platform api offers to accept decimal
>     values or code values as input though a real keyboard may not be
>     able to generate the same and converts it into a displayable
>     Unicode char.
>
>     Thanks and regards,
>
>     shashi
>
>     *From:*Semyon Sadetsky
>     *Sent:* Tuesday, August 22, 2017 10:03 PM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>;
>     awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress
>     should be able to use extended key code characters as ? ? ?.
>
>     Hi,
>
>     Are you sure that keyPress/keyRelease should emulate UTF8 symbols?
>     Physical keyboard cannot produces so many keycodes with a single
>     press/release.
>
>     --Semyon
>
>     On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote:
>
>         Hi All, Please review fix for the /_enhancement_/ wherein the
>         robot key press of non-ascii were interpreted as question marks.
>
>         Issue: The robot key press events was handling only the ascii
>         inputs and ignored the other Unicode inputs. Either it was
>         throwing illegal argument exception in windows or does nothing
>         on the mac for those Unicode inputs.
>
>         Solution and fix: The platform specific api’s was unable
>         handle the non-ascii inputs. I have modified the api’s to
>         accept the non-ascii inputs and correspondingly send the
>         message to the window to print the non-ascii characters as
>         well. Below is the picture of how the non-ascii inputs are
>         considered and printed onto the window.
>
>         The solution spans across windows and mac platform and still
>         in search of a solution for the Linux platform. The solution
>         implements key scanning only upon existing valid ascii key was
>         /_not_/ found and assumes it as Unicode key and sends the
>         event to event queue to be processed as Unicode keys.
>         Different formats are being used by different platform
>         implementation of Unicode. For ex., per the below Unicode
>         list, in the case of windows and mac, the key input can take
>         decimal values whereas on Linux it can only take the Code values.
>
>         On Linux, I was able to get the KeySym of Unicode keys but was
>         unable to fake the key event as there was no mechanism
>         available for the same(which sends the key event to window).
>         Please let me know if there is any such mechanism available to
>         simulate Unicode key events on Linux platform. Hence I think
>         to raise a bug for the Linux platform and close this
>         JDK-8148344 bug.
>
>         Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
>
>         Webrev:
>         http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/>
>
>         Thanks and regards,
>
>         Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170823/ee3c539b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4356 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170823/ee3c539b/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 81009 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170823/ee3c539b/image003-0001.jpg>


More information about the awt-dev mailing list