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

[Semyon Sadetsky]

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>; 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/20170822/842c203a/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/20170822/842c203a/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 81096 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/842c203a/image003-0001.jpg>