Thanks for the clarifications, the fix looks good to me. > 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… Could you please file a new P4 bug to investigate this?
Thank you. With best regards. Petr. On May 23, 2014, at 7:54 PM, anton nashatyrev <[email protected]> wrote: > 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. >
