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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

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

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [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?

----- [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

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

semyon.sadetsky
In reply to this post by Shashidhara H V

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


Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

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 <[hidden email]>; [hidden email]
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/

 

Thanks and regards,

Shashi

 

Reply | Threaded
Open this post in threaded view
|

Re: <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 [hidden email]; [hidden email]
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/

 

Thanks and regards,

Shashi

 


Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

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.

 

Thanks and regards,

Shashi

 

From: Semyon Sadetsky
Sent: Wednesday, August 23, 2017 12:28 AM
To: Shashidhara Veerabhadraiah <[hidden email]>; [hidden email]
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 [hidden email]; [hidden email]
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/

 

Thanks and regards,

Shashi

 

 

Reply | Threaded
Open this post in threaded view
|

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

semyon.sadetsky

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 [hidden email]; [hidden email]
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 [hidden email]; [hidden email]
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/

 

Thanks and regards,

Shashi

 

 


Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
In reply to this post by Sergey Bylokhov

Hi Sergey, I was only able to add short cut keys in the Microsoft word but not as a system wide short cut key. There was no mechanism that I could find to add a short cut key for a Unicode char!! Can you please tell me the steps to do the same if you are aware of?

 

Thanks and regards,

shashi

 

From: Sergey Bylokhov
Sent: Tuesday, August 22, 2017 8:34 PM
To: Shashidhara Veerabhadraiah <[hidden email]>
Cc: [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

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?

----- [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
In reply to this post by Shashidhara H V
Hi, Shashi.

This is part of this fix, to figure out how it will work for external applications. As you said this functionally can be useful for an onscreen keyboards, which virtually can have any possible keys, but we should check how the applications will react on such keys:
 - Will the application get some kind of keyPress/Release?
 - Will the application get some keyCode for such event?
 - Is it possible to get autorepeat for such keys?(between press/release)

Depending from the answers above we can enhance existed robot API or provide a new one:
like Robot.keyType(char)/etc

----- [hidden email] wrote:
>
>
>

Hi Sergey, I was only able to add short cut keys in the Microsoft word but not as a system wide short cut key. There was no mechanism that I could find to add a short cut key for a Unicode char!! Can you please tell me the steps to do the same if you are aware of?

 

Thanks and regards,

shashi

 

>

From: Sergey Bylokhov
> Sent: Tuesday, August 22, 2017 8:34 PM
> To: Shashidhara Veerabhadraiah <[hidden email]>
> Cc: [hidden email]
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

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?
>
> ----- [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

Hi, I have updated the Webrev to accommodate the comments and here is the new Webrev:

 

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

 

I have separated the Unicode keys input via java robot as a new set of public api’s (this is in similar fashion as how the platform offers the Unicode keys input into the system) and this has been tested on all the platforms using the test file similar to the attached file in the bug. A more proper test file would be put for review in the subsequent reviews.

 

Thanks and regards,

Shashi

 

From: Sergey Bylokhov
Sent: Wednesday, August 30, 2017 2:33 AM
To: Shashidhara Veerabhadraiah <[hidden email]>
Cc: [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi, Shashi.

This is part of this fix, to figure out how it will work for external applications. As you said this functionally can be useful for an onscreen keyboards, which virtually can have any possible keys, but we should check how the applications will react on such keys:
 - Will the application get some kind of keyPress/Release?
 - Will the application get some keyCode for such event?
 - Is it possible to get autorepeat for such keys?(between press/release)

Depending from the answers above we can enhance existed robot API or provide a new one:
like Robot.keyType(char)/etc

----- [hidden email] wrote:
>

>

>

Hi Sergey, I was only able to add short cut keys in the Microsoft word but not as a system wide short cut key. There was no mechanism that I could find to add a short cut key for a Unicode char!! Can you please tell me the steps to do the same if you are aware of?

 

Thanks and regards,

shashi

 

>

From: Sergey Bylokhov
> Sent: Tuesday, August 22, 2017 8:34 PM
> To: Shashidhara Veerabhadraiah <[hidden email]>
> Cc: [hidden email]
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

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?
>
> ----- [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
Hi, Shashi.
One initial question:
What is an int parameter of these methods means, is it a "Unicode code
point"? What encoding utf8/utf16 should be used?

On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

> Hi, I have updated the Webrev to accommodate the comments and here is
> the new Webrev:
>
> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
>
> I have separated the /_Unicode_/ keys input via java robot as a new set
> of /_public_/ api’s (this is in similar fashion as how the platform
> offers the Unicode keys input into the system) and this has been tested
> on all the platforms using the test file similar to the attached file in
> the bug. A more proper test file would be put for review in the
> subsequent reviews.
>
> Thanks and regards,
>
> Shashi
>
> *From:* Sergey Bylokhov
> *Sent:* Wednesday, August 30, 2017 2:33 AM
> *To:* Shashidhara Veerabhadraiah <[hidden email]>
> *Cc:* [hidden email]
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be
> able to use extended key code characters as ? ? ?.
>
> Hi, Shashi.
>
> This is part of this fix, to figure out how it will work for external
> applications. As you said this functionally can be useful for an
> onscreen keyboards, which virtually can have any possible keys, but we
> should check how the applications will react on such keys:
>   - Will the application get some kind of keyPress/Release?
>   - Will the application get some keyCode for such event?
>   - Is it possible to get autorepeat for such keys?(between press/release)
>
> Depending from the answers above we can enhance existed robot API or
> provide a new one:
> like Robot.keyType(char)/etc
>
> ----- [hidden email]
> <mailto:[hidden email]> wrote:
>>
>
>>
>
>>
>
> Hi Sergey, I was only able to add short cut keys in the Microsoft word
> but not as a system wide short cut key. There was no mechanism that I
> could find to add a short cut key for a Unicode char!! Can you please
> tell me the steps to do the same if you are aware of?
>
> Thanks and regards,
>
> shashi
>
>>
>
> *From:*Sergey Bylokhov
>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>> *To:* Shashidhara Veerabhadraiah <[hidden email]
> <mailto:[hidden email]>>
>> *Cc:* [hidden email] <mailto:[hidden email]>
>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be
> able to use extended key code characters as ? ? ?.
>
> 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?
>>
>> ----- [hidden email]
> <mailto:[hidden email]> 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
>


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov
Sent: Wednesday, September 13, 2017 5:22 AM
To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Hi, Shashi.
One initial question:
What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

> Hi, I have updated the Webrev to accommodate the comments and here is
> the new Webrev:
>
> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
>
> I have separated the /_Unicode_/ keys input via java robot as a new
> set of /_public_/ api’s (this is in similar fashion as how the
> platform offers the Unicode keys input into the system) and this has
> been tested on all the platforms using the test file similar to the
> attached file in the bug. A more proper test file would be put for
> review in the subsequent reviews.
>
> Thanks and regards,
>
> Shashi
>
> *From:* Sergey Bylokhov
> *Sent:* Wednesday, August 30, 2017 2:33 AM
> *To:* Shashidhara Veerabhadraiah
> <[hidden email]>
> *Cc:* [hidden email]
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
> be able to use extended key code characters as ? ? ?.
>
> Hi, Shashi.
>
> This is part of this fix, to figure out how it will work for external
> applications. As you said this functionally can be useful for an
> onscreen keyboards, which virtually can have any possible keys, but we
> should check how the applications will react on such keys:
>   - Will the application get some kind of keyPress/Release?
>   - Will the application get some keyCode for such event?
>   - Is it possible to get autorepeat for such keys?(between
> press/release)
>
> Depending from the answers above we can enhance existed robot API or
> provide a new one:
> like Robot.keyType(char)/etc
>
> ----- [hidden email]
> <mailto:[hidden email]> wrote:
>>
>
>>
>
>>
>
> Hi Sergey, I was only able to add short cut keys in the Microsoft word
> but not as a system wide short cut key. There was no mechanism that I
> could find to add a short cut key for a Unicode char!! Can you please
> tell me the steps to do the same if you are aware of?
>
> Thanks and regards,
>
> shashi
>
>>
>
> *From:*Sergey Bylokhov
>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>> *To:* Shashidhara Veerabhadraiah
>> <[hidden email]
> <mailto:[hidden email]>>
>> *Cc:* [hidden email] <mailto:[hidden email]>
>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
>> be
> able to use extended key code characters as ? ? ?.
>
> 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?
>>
>> ----- [hidden email]
> <mailto:[hidden email]> 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
>


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
The java uses UTF16, I guess this new api should use it also, and we
should check that the surrogate pairs will be supported.

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, September 13, 2017 5:22 AM
> To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.
>
> Hi, Shashi.
> One initial question:
> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?
>
> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:
>> Hi, I have updated the Webrev to accommodate the comments and here is
>> the new Webrev:
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
>>
>> I have separated the /_Unicode_/ keys input via java robot as a new
>> set of /_public_/ api’s (this is in similar fashion as how the
>> platform offers the Unicode keys input into the system) and this has
>> been tested on all the platforms using the test file similar to the
>> attached file in the bug. A more proper test file would be put for
>> review in the subsequent reviews.
>>
>> Thanks and regards,
>>
>> Shashi
>>
>> *From:* Sergey Bylokhov
>> *Sent:* Wednesday, August 30, 2017 2:33 AM
>> *To:* Shashidhara Veerabhadraiah
>> <[hidden email]>
>> *Cc:* [hidden email]
>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
>> be able to use extended key code characters as ? ? ?.
>>
>> Hi, Shashi.
>>
>> This is part of this fix, to figure out how it will work for external
>> applications. As you said this functionally can be useful for an
>> onscreen keyboards, which virtually can have any possible keys, but we
>> should check how the applications will react on such keys:
>>    - Will the application get some kind of keyPress/Release?
>>    - Will the application get some keyCode for such event?
>>    - Is it possible to get autorepeat for such keys?(between
>> press/release)
>>
>> Depending from the answers above we can enhance existed robot API or
>> provide a new one:
>> like Robot.keyType(char)/etc
>>
>> ----- [hidden email]
>> <mailto:[hidden email]> wrote:
>>>
>>
>>>
>>
>>>
>>
>> Hi Sergey, I was only able to add short cut keys in the Microsoft word
>> but not as a system wide short cut key. There was no mechanism that I
>> could find to add a short cut key for a Unicode char!! Can you please
>> tell me the steps to do the same if you are aware of?
>>
>> Thanks and regards,
>>
>> shashi
>>
>>>
>>
>> *From:*Sergey Bylokhov
>>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>>> *To:* Shashidhara Veerabhadraiah
>>> <[hidden email]
>> <mailto:[hidden email]>>
>>> *Cc:* [hidden email] <mailto:[hidden email]>
>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
>>> be
>> able to use extended key code characters as ? ? ?.
>>
>> 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?
>>>
>>> ----- [hidden email]
>> <mailto:[hidden email]> 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
>>
>
>
> --
> Best regards, Sergey.
>


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

Hi Sergey, I was able to input the surrogate pairs and got the required output as shown below:

 

 

 

Below is the output after we input the surrogate pairs:

 

 

Thanks and regards,

Shashi

 

 

-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

The java uses UTF16, I guess this new api should use it also, and we should check that the surrogate pairs will be supported.

 

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

>

> Thanks and regards,

> Shashi

>

> -----Original Message-----

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah

> <[hidden email]>; Semyon Sadetsky

> <[hidden email]>; [hidden email]

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

>

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

>

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is

>> the new Webrev:

>> 

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>> 

>> I have separated the /_Unicode_/ keys input via java robot as a new

>> set of /_public_/ api’s (this is in similar fashion as how the

>> platform offers the Unicode keys input into the system) and this has

>> been tested on all the platforms using the test file similar to the

>> attached file in the bug. A more proper test file would be put for

>> review in the subsequent reviews.

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> <[hidden email]>

>> *Cc:* [hidden email]

>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should

>> be able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>> 

>> This is part of this fix, to figure out how it will work for external

>> applications. As you said this functionally can be useful for an

>> onscreen keyboards, which virtually can have any possible keys, but

>> we should check how the applications will react on such keys:

>>    - Will the application get some kind of keyPress/Release?

>>    - Will the application get some keyCode for such event?

>>    - Is it possible to get autorepeat for such keys?(between

>> press/release)

>> 

>> Depending from the answers above we can enhance existed robot API or

>> provide a new one:

>> like Robot.keyType(char)/etc

>> 

>> ----- [hidden email]

>> <[hidden email]> wrote:

>>> 

>> 

>>> 

>> 

>>> 

>> 

>> Hi Sergey, I was only able to add short cut keys in the Microsoft

>> word but not as a system wide short cut key. There was no mechanism

>> that I could find to add a short cut key for a Unicode char!! Can you

>> please tell me the steps to do the same if you are aware of?

>> 

>> Thanks and regards,

>> 

>> shashi

>> 

>>> 

>> 

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> <[hidden email]

>> <[hidden email]>>

>>> *Cc:* [hidden email] <[hidden email]>

>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress

>>> should be

>> able to use extended key code characters as ? ? ?.

>> 

>> 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?

>>> 

>>> ----- [hidden email]

>> <[hidden email]> 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

>> 

>

>

> --

> Best regards, Sergey.

>

 

 

--

Best regards, Sergey.

 

Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

Hi All, Please find the updated webrev containing a new test that is added to test out the software changes that were made under this enhancement.

 

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah
Sent: Thursday, September 21, 2017 11:37 AM
To: Sergey Bylokhov <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi Sergey, I was able to input the surrogate pairs and got the required output as shown below:

 

 

 

Below is the output after we input the surrogate pairs:

 

 

Thanks and regards,

Shashi

 

 

-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

The java uses UTF16, I guess this new api should use it also, and we should check that the surrogate pairs will be supported.

 

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

>

> Thanks and regards,

> Shashi

>

> -----Original Message-----

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah

> <[hidden email]>; Semyon Sadetsky

> <[hidden email]>; [hidden email]

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

>

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

>

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is

>> the new Webrev:

>> 

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>> 

>> I have separated the /_Unicode_/ keys input via java robot as a new

>> set of /_public_/ api’s (this is in similar fashion as how the

>> platform offers the Unicode keys input into the system) and this has

>> been tested on all the platforms using the test file similar to the

>> attached file in the bug. A more proper test file would be put for

>> review in the subsequent reviews.

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> <[hidden email]>

>> *Cc:* [hidden email]

>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should

>> be able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>> 

>> This is part of this fix, to figure out how it will work for external

>> applications. As you said this functionally can be useful for an

>> onscreen keyboards, which virtually can have any possible keys, but

>> we should check how the applications will react on such keys:

>>    - Will the application get some kind of keyPress/Release?

>>    - Will the application get some keyCode for such event?

>>    - Is it possible to get autorepeat for such keys?(between

>> press/release)

>> 

>> Depending from the answers above we can enhance existed robot API or

>> provide a new one:

>> like Robot.keyType(char)/etc

>> 

>> ----- [hidden email]

>> <[hidden email]> wrote:

>>> 

>> 

>>> 

>> 

>>> 

>> 

>> Hi Sergey, I was only able to add short cut keys in the Microsoft

>> word but not as a system wide short cut key. There was no mechanism

>> that I could find to add a short cut key for a Unicode char!! Can you

>> please tell me the steps to do the same if you are aware of?

>> 

>> Thanks and regards,

>> 

>> shashi

>> 

>>> 

>> 

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> <[hidden email]

>> <[hidden email]>>

>>> *Cc:* [hidden email] <[hidden email]>

>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress

>>> should be

>> able to use extended key code characters as ? ? ?.

>> 

>> 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?

>>> 

>>> ----- [hidden email]

>> <[hidden email]> 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

>> 

>

>

> --

> Best regards, Sergey.

>

 

 

--

Best regards, Sergey.

 

Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

Hi Sergey\Semyon, Please do the review for the below bug.

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah
Sent: Thursday, September 21, 2017 2:14 PM
To: Sergey Bylokhov <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi All, Please find the updated webrev containing a new test that is added to test out the software changes that were made under this enhancement.

 

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah
Sent: Thursday, September 21, 2017 11:37 AM
To: Sergey Bylokhov <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi Sergey, I was able to input the surrogate pairs and got the required output as shown below:

 

 

 

Below is the output after we input the surrogate pairs:

 

 

Thanks and regards,

Shashi

 

 

-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

The java uses UTF16, I guess this new api should use it also, and we should check that the surrogate pairs will be supported.

 

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

>

> Thanks and regards,

> Shashi

>

> -----Original Message-----

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah

> <[hidden email]>; Semyon Sadetsky

> <[hidden email]>; [hidden email]

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

>

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

>

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is

>> the new Webrev:

>> 

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>> 

>> I have separated the /_Unicode_/ keys input via java robot as a new

>> set of /_public_/ api’s (this is in similar fashion as how the

>> platform offers the Unicode keys input into the system) and this has

>> been tested on all the platforms using the test file similar to the

>> attached file in the bug. A more proper test file would be put for

>> review in the subsequent reviews.

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> <[hidden email]>

>> *Cc:* [hidden email]

>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should

>> be able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>> 

>> This is part of this fix, to figure out how it will work for external

>> applications. As you said this functionally can be useful for an

>> onscreen keyboards, which virtually can have any possible keys, but

>> we should check how the applications will react on such keys:

>>    - Will the application get some kind of keyPress/Release?

>>    - Will the application get some keyCode for such event?

>>    - Is it possible to get autorepeat for such keys?(between

>> press/release)

>> 

>> Depending from the answers above we can enhance existed robot API or

>> provide a new one:

>> like Robot.keyType(char)/etc

>> 

>> ----- [hidden email]

>> <[hidden email]> wrote:

>>> 

>> 

>>> 

>> 

>>> 

>> 

>> Hi Sergey, I was only able to add short cut keys in the Microsoft

>> word but not as a system wide short cut key. There was no mechanism

>> that I could find to add a short cut key for a Unicode char!! Can you

>> please tell me the steps to do the same if you are aware of?

>> 

>> Thanks and regards,

>> 

>> shashi

>> 

>>> 

>> 

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> <[hidden email]

>> <[hidden email]>>

>>> *Cc:* [hidden email] <[hidden email]>

>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress

>>> should be

>> able to use extended key code characters as ? ? ?.

>> 

>> 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?

>>> 

>>> ----- [hidden email]

>> <[hidden email]> 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

>> 

>

>

> --

> Best regards, Sergey.

>

 

 

--

Best regards, Sergey.

 

Reply | Threaded
Open this post in threaded view
|

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

semyon.sadetsky

Hi Shashi,

The change looks good to me.

You need to get a CSR approved before the push.

--Semyon

On 10/26/2017 09:39 PM, Shashidhara Veerabhadraiah wrote:

Hi Sergey\Semyon, Please do the review for the below bug.

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah
Sent: Thursday, September 21, 2017 2:14 PM
To: Sergey Bylokhov [hidden email]; Semyon Sadetsky [hidden email]; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi All, Please find the updated webrev containing a new test that is added to test out the software changes that were made under this enhancement.

 

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah
Sent: Thursday, September 21, 2017 11:37 AM
To: Sergey Bylokhov <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi Sergey, I was able to input the surrogate pairs and got the required output as shown below:

 

 

 

Below is the output after we input the surrogate pairs:

 

 

Thanks and regards,

Shashi

 

 

-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

The java uses UTF16, I guess this new api should use it also, and we should check that the surrogate pairs will be supported.

 

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

>

> Thanks and regards,

> Shashi

>

> -----Original Message-----

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah

> <[hidden email]>; Semyon Sadetsky

> <[hidden email]>; [hidden email]

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

>

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

>

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is

>> the new Webrev:

>> 

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>> 

>> I have separated the /_Unicode_/ keys input via java robot as a new

>> set of /_public_/ api’s (this is in similar fashion as how the

>> platform offers the Unicode keys input into the system) and this has

>> been tested on all the platforms using the test file similar to the

>> attached file in the bug. A more proper test file would be put for

>> review in the subsequent reviews.

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> <[hidden email]>

>> *Cc:* [hidden email]

>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should

>> be able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>> 

>> This is part of this fix, to figure out how it will work for external

>> applications. As you said this functionally can be useful for an

>> onscreen keyboards, which virtually can have any possible keys, but

>> we should check how the applications will react on such keys:

>>    - Will the application get some kind of keyPress/Release?

>>    - Will the application get some keyCode for such event?

>>    - Is it possible to get autorepeat for such keys?(between

>> press/release)

>> 

>> Depending from the answers above we can enhance existed robot API or

>> provide a new one:

>> like Robot.keyType(char)/etc

>> 

>> ----- [hidden email]

>> <[hidden email]> wrote:

>>> 

>> 

>>> 

>> 

>>> 

>> 

>> Hi Sergey, I was only able to add short cut keys in the Microsoft

>> word but not as a system wide short cut key. There was no mechanism

>> that I could find to add a short cut key for a Unicode char!! Can you

>> please tell me the steps to do the same if you are aware of?

>> 

>> Thanks and regards,

>> 

>> shashi

>> 

>>> 

>> 

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> <[hidden email]

>> <[hidden email]>>

>>> *Cc:* [hidden email] <[hidden email]>

>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress

>>> should be

>> able to use extended key code characters as ? ? ?.

>> 

>> 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?

>>> 

>>> ----- [hidden email]

>> <[hidden email]> 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

>> 

>

>

> --

> Best regards, Sergey.

>

 

 

--

Best regards, Sergey.

 


Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V

Thank you Semyon for the quick review.

 

Thanks and regards,

Shashi

 

From: Semyon Sadetsky
Sent: Friday, October 27, 2017 10:38 AM
To: Shashidhara Veerabhadraiah <[hidden email]>; Sergey Bylokhov <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi Shashi,

The change looks good to me.

You need to get a CSR approved before the push.

--Semyon

On 10/26/2017 09:39 PM, Shashidhara Veerabhadraiah wrote:

Hi Sergey\Semyon, Please do the review for the below bug.

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah
Sent: Thursday, September 21, 2017 2:14 PM
To: Sergey Bylokhov [hidden email]; Semyon Sadetsky [hidden email]; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi All, Please find the updated webrev containing a new test that is added to test out the software changes that were made under this enhancement.

 

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah
Sent: Thursday, September 21, 2017 11:37 AM
To: Sergey Bylokhov <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi Sergey, I was able to input the surrogate pairs and got the required output as shown below:

 

 

 

Below is the output after we input the surrogate pairs:

 

 

Thanks and regards,

Shashi

 

 

-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

The java uses UTF16, I guess this new api should use it also, and we should check that the surrogate pairs will be supported.

 

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

>

> Thanks and regards,

> Shashi

>

> -----Original Message-----

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah

> <[hidden email]>; Semyon Sadetsky

> <[hidden email]>; [hidden email]

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

>

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

>

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is

>> the new Webrev:

>> 

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>> 

>> I have separated the /_Unicode_/ keys input via java robot as a new

>> set of /_public_/ api’s (this is in similar fashion as how the

>> platform offers the Unicode keys input into the system) and this has

>> been tested on all the platforms using the test file similar to the

>> attached file in the bug. A more proper test file would be put for

>> review in the subsequent reviews.

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> <[hidden email]>

>> *Cc:* [hidden email]

>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should

>> be able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>> 

>> This is part of this fix, to figure out how it will work for external

>> applications. As you said this functionally can be useful for an

>> onscreen keyboards, which virtually can have any possible keys, but

>> we should check how the applications will react on such keys:

>>    - Will the application get some kind of keyPress/Release?

>>    - Will the application get some keyCode for such event?

>>    - Is it possible to get autorepeat for such keys?(between

>> press/release)

>> 

>> Depending from the answers above we can enhance existed robot API or

>> provide a new one:

>> like Robot.keyType(char)/etc

>> 

>> ----- [hidden email]

>> <[hidden email]> wrote:

>>> 

>> 

>>> 

>> 

>>> 

>> 

>> Hi Sergey, I was only able to add short cut keys in the Microsoft

>> word but not as a system wide short cut key. There was no mechanism

>> that I could find to add a short cut key for a Unicode char!! Can you

>> please tell me the steps to do the same if you are aware of?

>> 

>> Thanks and regards,

>> 

>> shashi

>> 

>>> 

>> 

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> <[hidden email]

>> <[hidden email]>>

>>> *Cc:* [hidden email] <[hidden email]>

>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress

>>> should be

>> able to use extended key code characters as ? ? ?.

>> 

>> 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?

>>> 

>>> ----- [hidden email]

>> <[hidden email]> 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

>> 

>

>

> --

> Best regards, Sergey.

>

 

 

--

Best regards, Sergey.

 

 

Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
In reply to this post by Shashidhara H V
Hi, Shashi.
  - Do we need to check passed unicode code-point in Robot.java using
checkKeycodeArgument(key);?
  - Can you please clarify how it will work on linux where we will use
code-point as a keycode?
  - It would be good if the names of the parameters will be
unified/corrected, for example:
private native void keyEventUnicode(int javaKeyCode, boolean keydown);
"javaKeyCode" - Is it a java key code or a Unicode code-point?

Why the test is manual? Isn't an application should  recognize this new
functionality automatically? Additionally it would be good to test all
key related listeners(keyTyped/keyPressed/keyReleased).

Debug code in awt_Robot.cpp
if(isUnicode) {printf("In unicode func:%d", jkey);


Also I would like to propose an idea for discussion: probably it would
be better to create only one Robot#type(codePoint) method? What do you
think?

On 26/10/2017 21:39, Shashidhara Veerabhadraiah wrote:

> Hi Sergey\Semyon, Please do the review for the below bug.
>
> Thanks and regards,
>
> Shashi
>
> *From:* Shashidhara Veerabhadraiah
> *Sent:* Thursday, September 21, 2017 2:14 PM
> *To:* Sergey Bylokhov <[hidden email]>; Semyon Sadetsky
> <[hidden email]>; [hidden email]
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be
> able to use extended key code characters as ? ? ?.
>
> Hi All, Please find the updated webrev containing a new test that is
> added to test out the software changes that were made under this
> enhancement.
>
> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/
>
> Thanks and regards,
>
> Shashi
>
> *From:* Shashidhara Veerabhadraiah
> *Sent:* Thursday, September 21, 2017 11:37 AM
> *To:* Sergey Bylokhov <[hidden email]
> <mailto:[hidden email]>>; Semyon Sadetsky
> <[hidden email] <mailto:[hidden email]>>;
> [hidden email] <mailto:[hidden email]>
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be
> able to use extended key code characters as ? ? ?.
>
> Hi Sergey, I was able to input the surrogate pairs and got the required
> output as shown below:
>
> Below is the output after we input the surrogate pairs:
>
> Thanks and regards,
>
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, September 14, 2017 11:33 PM
> To: Shashidhara Veerabhadraiah <[hidden email]
> <mailto:[hidden email]>>; Semyon Sadetsky
> <[hidden email] <mailto:[hidden email]>>;
> [hidden email] <mailto:[hidden email]>
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be
> able to use extended key code characters as ? ? ?.
>
> The java uses UTF16, I guess this new api should use it also, and we
> should check that the surrogate pairs will be supported.
>
> On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:
>
>  > Hi Sergey, Yes it represents the Unicode code point. The encoding is
> same as the window characteristic which is UTF 8 as implemented in Java.
>
>  >
>
>  > Thanks and regards,
>
>  > Shashi
>
>  >
>
>  > -----Original Message-----
>
>  > From: Sergey Bylokhov
>
>  > Sent: Wednesday, September 13, 2017 5:22 AM
>
>  > To: Shashidhara Veerabhadraiah
>
>  > <[hidden email]
> <mailto:[hidden email]>>; Semyon Sadetsky
>
>  > <[hidden email] <mailto:[hidden email]>>;
> [hidden email] <mailto:[hidden email]>
>
>  > Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
> be able to use extended key code characters as ? ? ?.
>
>  >
>
>  > Hi, Shashi.
>
>  > One initial question:
>
>  > What is an int parameter of these methods means, is it a "Unicode
> code point"? What encoding utf8/utf16 should be used?
>
>  >
>
>  > On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:
>
>  >> Hi, I have updated the Webrev to accommodate the comments and here is
>
>  >> the new Webrev:
>
>  >>
>
>  >> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
>
>  >>
>
>  >> I have separated the /_Unicode_/ keys input via java robot as a new
>
>  >> set of /_public_/ api’s (this is in similar fashion as how the
>
>  >> platform offers the Unicode keys input into the system) and this has
>
>  >> been tested on all the platforms using the test file similar to the
>
>  >> attached file in the bug. A more proper test file would be put for
>
>  >> review in the subsequent reviews.
>
>  >>
>
>  >> Thanks and regards,
>
>  >>
>
>  >> Shashi
>
>  >>
>
>  >> *From:* Sergey Bylokhov
>
>  >> *Sent:* Wednesday, August 30, 2017 2:33 AM
>
>  >> *To:* Shashidhara Veerabhadraiah
>
>  >> <[hidden email]
> <mailto:[hidden email]>>
>
>  >> *Cc:* [hidden email] <mailto:[hidden email]>
>
>  >> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
>
>  >> be able to use extended key code characters as ? ? ?.
>
>  >>
>
>  >> Hi, Shashi.
>
>  >>
>
>  >> This is part of this fix, to figure out how it will work for external
>
>  >> applications. As you said this functionally can be useful for an
>
>  >> onscreen keyboards, which virtually can have any possible keys, but
>
>  >> we should check how the applications will react on such keys:
>
>  >>    - Will the application get some kind of keyPress/Release?
>
>  >>    - Will the application get some keyCode for such event?
>
>  >>    - Is it possible to get autorepeat for such keys?(between
>
>  >> press/release)
>
>  >>
>
>  >> Depending from the answers above we can enhance existed robot API or
>
>  >> provide a new one:
>
>  >> like Robot.keyType(char)/etc
>
>  >>
>
>  >> ----- [hidden email]
> <mailto:[hidden email]>
>
>  >> <mailto:[hidden email]> wrote:
>
>  >>>
>
>  >>
>
>  >>>
>
>  >>
>
>  >>>
>
>  >>
>
>  >> Hi Sergey, I was only able to add short cut keys in the Microsoft
>
>  >> word but not as a system wide short cut key. There was no mechanism
>
>  >> that I could find to add a short cut key for a Unicode char!! Can you
>
>  >> please tell me the steps to do the same if you are aware of?
>
>  >>
>
>  >> Thanks and regards,
>
>  >>
>
>  >> shashi
>
>  >>
>
>  >>>
>
>  >>
>
>  >> *From:*Sergey Bylokhov
>
>  >>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>
>  >>> *To:* Shashidhara Veerabhadraiah
>
>  >>> <[hidden email]
>
>  >> <mailto:[hidden email]>>
>
>  >>> *Cc:* [hidden email] <mailto:[hidden email]>
> <mailto:[hidden email]>
>
>  >>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress
>
>  >>> should be
>
>  >> able to use extended key code characters as ? ? ?.
>
>  >>
>
>  >> 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?
>
>  >>>
>
>  >>> ----- [hidden email]
> <mailto:[hidden email]>
>
>  >> <mailto:[hidden email]> 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
>
>  >>
>
>  >
>
>  >
>
>  > --
>
>  > Best regards, Sergey.
>
>  >
>
> --
>
> Best regards, Sergey.
>


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
Hi Sergey, below are my replies:

Thanks and regards,
shashi

-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, October 27, 2017 11:47 AM
To: Shashidhara Veerabhadraiah <[hidden email]>; Semyon Sadetsky <[hidden email]>; [hidden email]
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Hi, Shashi.
  - Do we need to check passed unicode code-point in Robot.java using checkKeycodeArgument(key);?
[Shashi] I think yes. If the key value is zero I believe we don't need to process further.
  - Can you please clarify how it will work on linux where we will use code-point as a keycode?
[Shashi] There is no update being done to the linux source code as I could not find native call which can interpret the Unicode. Hence it will behave same as the original keypress() and keyrelease().
  - It would be good if the names of the parameters will be unified/corrected, for example:
private native void keyEventUnicode(int javaKeyCode, boolean keydown); "javaKeyCode" - Is it a java key code or a Unicode code-point?
[Shashi] Sure will update in the coming pass.

Why the test is manual? Isn't an application should  recognize this new functionality automatically? Additionally it would be good to test all key related listeners(keyTyped/keyPressed/keyReleased).
[Shashi] We need to be sure that the Unicode key indeed displayed as the standard Unicode. There is no other way to confirm that it is indeed been the same standard Unicode that's been displayed.

Debug code in awt_Robot.cpp
if(isUnicode) {printf("In unicode func:%d", jkey);
[Shashi] Sure will update in the coming pass.


Also I would like to propose an idea for discussion: probably it would be better to create only one Robot#type(codePoint) method? What do you think?
[Shashi] It can be done but the only problem is that it is kinda different from the keypress() and keyRelease() functions. If that's fine then it can be done. Please confirm based on that I will produce a new Webrev based on that.

On 26/10/2017 21:39, Shashidhara Veerabhadraiah wrote:

> Hi Sergey\Semyon, Please do the review for the below bug.
>
> Thanks and regards,
>
> Shashi
>
> *From:* Shashidhara Veerabhadraiah
> *Sent:* Thursday, September 21, 2017 2:14 PM
> *To:* Sergey Bylokhov <[hidden email]>; Semyon Sadetsky
> <[hidden email]>; [hidden email]
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
> be able to use extended key code characters as ? ? ?.
>
> Hi All, Please find the updated webrev containing a new test that is
> added to test out the software changes that were made under this
> enhancement.
>
> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/
>
> Thanks and regards,
>
> Shashi
>
> *From:* Shashidhara Veerabhadraiah
> *Sent:* Thursday, September 21, 2017 11:37 AM
> *To:* Sergey Bylokhov <[hidden email]
> <mailto:[hidden email]>>; Semyon Sadetsky
> <[hidden email] <mailto:[hidden email]>>;
> [hidden email] <mailto:[hidden email]>
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
> be able to use extended key code characters as ? ? ?.
>
> Hi Sergey, I was able to input the surrogate pairs and got the
> required output as shown below:
>
> Below is the output after we input the surrogate pairs:
>
> Thanks and regards,
>
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, September 14, 2017 11:33 PM
> To: Shashidhara Veerabhadraiah <[hidden email]
> <mailto:[hidden email]>>; Semyon Sadetsky
> <[hidden email] <mailto:[hidden email]>>;
> [hidden email] <mailto:[hidden email]>
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be
> able to use extended key code characters as ? ? ?.
>
> The java uses UTF16, I guess this new api should use it also, and we
> should check that the surrogate pairs will be supported.
>
> On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:
>
>  > Hi Sergey, Yes it represents the Unicode code point. The encoding
> is same as the window characteristic which is UTF 8 as implemented in Java.
>
>  >
>
>  > Thanks and regards,
>
>  > Shashi
>
>  >
>
>  > -----Original Message-----
>
>  > From: Sergey Bylokhov
>
>  > Sent: Wednesday, September 13, 2017 5:22 AM
>
>  > To: Shashidhara Veerabhadraiah
>
>  > <[hidden email]
> <mailto:[hidden email]>>; Semyon Sadetsky
>
>  > <[hidden email] <mailto:[hidden email]>>;
> [hidden email] <mailto:[hidden email]>
>
>  > Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
> be able to use extended key code characters as ? ? ?.
>
>  >
>
>  > Hi, Shashi.
>
>  > One initial question:
>
>  > What is an int parameter of these methods means, is it a "Unicode
> code point"? What encoding utf8/utf16 should be used?
>
>  >
>
>  > On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:
>
>  >> Hi, I have updated the Webrev to accommodate the comments and here
> is
>
>  >> the new Webrev:
>
>  >>
>
>  >> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
>
>  >>
>
>  >> I have separated the /_Unicode_/ keys input via java robot as a
> new
>
>  >> set of /_public_/ api’s (this is in similar fashion as how the
>
>  >> platform offers the Unicode keys input into the system) and this
> has
>
>  >> been tested on all the platforms using the test file similar to
> the
>
>  >> attached file in the bug. A more proper test file would be put for
>
>  >> review in the subsequent reviews.
>
>  >>
>
>  >> Thanks and regards,
>
>  >>
>
>  >> Shashi
>
>  >>
>
>  >> *From:* Sergey Bylokhov
>
>  >> *Sent:* Wednesday, August 30, 2017 2:33 AM
>
>  >> *To:* Shashidhara Veerabhadraiah
>
>  >> <[hidden email]
> <mailto:[hidden email]>>
>
>  >> *Cc:* [hidden email] <mailto:[hidden email]>
>
>  >> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress
> should
>
>  >> be able to use extended key code characters as ? ? ?.
>
>  >>
>
>  >> Hi, Shashi.
>
>  >>
>
>  >> This is part of this fix, to figure out how it will work for
> external
>
>  >> applications. As you said this functionally can be useful for an
>
>  >> onscreen keyboards, which virtually can have any possible keys,
> but
>
>  >> we should check how the applications will react on such keys:
>
>  >>    - Will the application get some kind of keyPress/Release?
>
>  >>    - Will the application get some keyCode for such event?
>
>  >>    - Is it possible to get autorepeat for such keys?(between
>
>  >> press/release)
>
>  >>
>
>  >> Depending from the answers above we can enhance existed robot API
> or
>
>  >> provide a new one:
>
>  >> like Robot.keyType(char)/etc
>
>  >>
>
>  >> ----- [hidden email]
> <mailto:[hidden email]>
>
>  >> <mailto:[hidden email]> wrote:
>
>  >>>
>
>  >>
>
>  >>>
>
>  >>
>
>  >>>
>
>  >>
>
>  >> Hi Sergey, I was only able to add short cut keys in the Microsoft
>
>  >> word but not as a system wide short cut key. There was no
> mechanism
>
>  >> that I could find to add a short cut key for a Unicode char!! Can
> you
>
>  >> please tell me the steps to do the same if you are aware of?
>
>  >>
>
>  >> Thanks and regards,
>
>  >>
>
>  >> shashi
>
>  >>
>
>  >>>
>
>  >>
>
>  >> *From:*Sergey Bylokhov
>
>  >>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>
>  >>> *To:* Shashidhara Veerabhadraiah
>
>  >>> <[hidden email]
>
>  >> <mailto:[hidden email]>>
>
>  >>> *Cc:* [hidden email] <mailto:[hidden email]>
> <mailto:[hidden email]>
>
>  >>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress
>
>  >>> should be
>
>  >> able to use extended key code characters as ? ? ?.
>
>  >>
>
>  >> 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?
>
>  >>>
>
>  >>> ----- [hidden email]
> <mailto:[hidden email]>
>
>  >> <mailto:[hidden email]> 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
>
>  >>
>
>  >
>
>  >
>
>  > --
>
>  > Best regards, Sergey.
>
>  >
>
> --
>
> Best regards, Sergey.
>


--
Best regards, Sergey.
12