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