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