Re: [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 
; awt-dev@openjdk.java.net
*Subject:* Re:  [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/


Thanks and regards,

Shashi

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

[Shashidhara Veerabhadraiah]

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 ; 
awt-dev@openjdk.java.net
Subject: Re:  [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: HYPERLINK 
"http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/

 

Thanks and regards,

Shashi

 

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

[Semyon Sadetsky]

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/ 



Thanks and regards,

Shashi

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

[Sergey Bylokhov]

Hi, Shashi. 
Can you check how this Robot API will work when the application will have a 
shortcut for such key? Will such shortcuts will work after this fix? 

- shashidhara.veerabhadra...@oracle.com 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/ 



Thanks and regards, 

Shashi

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

[Shashidhara Veerabhadraiah]

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/

 

Thanks and regards,

Shashi

Re: [10] Review Request: 8186474 WColor class is superseded by the SystemColor and should be removed

[Alexander Zvegintsev]

Looks fine

Thanks,
Alexander.

On 19/08/2017 07:34, Sergey Bylokhov wrote:

Hello,
Please review the simple cleanup for jdk10.

Long time ago AWT used WColor class to access the native colors, but since then 
we integrated a public API via SystemColor class.
So WColor class became obsolete and can be removed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8186474
Webrev can be found at: http://cr.openjdk.java.net/~serb/8186474/webrev.01