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.
