I believe that at least in most cases this workaround will be skipped
after the fix, however for some keys it might be still actual. I'm not
sure here...
On 23.05.2014 19:40, Petr Pchelko wrote:
No, we are using the workaround now: the character is calculated from the
keyboard scan-code (which is also received in the NSEvent) when the
NSEvent::characters is empty. Thus we are still getting the right character in
the querty layout, but having a problem with others (e.g. when the Ctrl-e is
pressed on the dvorak layout (E corresponds to qwerty 'D') we are getting
Ctrl+d.)
Go we still need this workaround after your fix?
With best regards. Petr.
On May 23, 2014, at 7:35 PM, anton nashatyrev <[email protected]>
wrote:
Hello Petr,
yes, I've run java/awt/event/KeyEvent tests from both open/closed parts:
there were a number of fails on a clean build, but no new fails found with a
fixed version (even one of them became 'passed').
I couldn't invent any automatic regression tests since the problem is
reproducible only with non-querty layouts.
No, we are using the workaround now: the character is calculated from the
keyboard scan-code (which is also received in the NSEvent) when the
NSEvent::characters is empty. Thus we are still getting the right character in
the querty layout, but having a problem with others (e.g. when the Ctrl-e is
pressed on the dvorak layout (E corresponds to qwerty 'D') we are getting
Ctrl+d.)
Thanks!
Anton.
On 23.05.2014 19:23, Petr Pchelko wrote:
Hello, Anton.
Did you run all the KeyEvent-related regression tests?
May be we could right a regression test for this one? From your evaluation I
have an impression that Ctrl+Key combination is now broken in normal layout
too? Is this correct?
Thank you.
With best regards. Petr.
On May 23, 2014, at 7:14 PM, anton nashatyrev <[email protected]>
wrote:
Hello,
could you please review the following fix:
fix: http://cr.openjdk.java.net/~anashaty/8028617/9/webrev.00/
<http://cr.openjdk.java.net/%7Eanashaty/8028617/9/webrev.00/>
bug: https://bugs.openjdk.java.net/browse/JDK-8028617
Problem: Dvorak keyboard mapping not honored when Ctrl key pressed
Evaluation:
The problem is in the AWTView.m:deliverJavaKeyEventHelper(): for taking
a character we use NSEvent::characters which works fine until the Ctrl modifier
is pressed. In this case the 'charaters' returns empty string. The typed
character is then calculated via key code using the standard keyboard layout.
Of course that doesn't work for any other layout including DVORAK.
Fix: We should use NSEvent::charactersIgnoringModifiers property instead
(especially taking into account that sun.lwawt.macosx.event.NSEvent constructor
parameter name is 'charactersIgnoringModifiers')
Thanks!
Anton.
