<AWT Dev> [9] Review request for 8028617: Dvorak keyboard mapping not honored when ctrl key pressed

[anton nashatyrev]

Hi Sergey,

     my assumption was not not correct. On Mac we have the following 
algorithm (without details):
- if the NSEvent::character is alphanumeric ASCII char then it is 
directly translated to the java VK_* key code
- else we are using special table for translating Mac NSEvent::keyCode 
to java VK_* code.

     The problem is that NSEvent::character contains special symbols 
when the Ctrl modifier is pressed and we are using our table. All is 
fine with the qwerty layout but for other layouts the mentioned table is 
not valid.

     With the fix the algorithm will remain actual, but with the Ctrl 
modifier we will get the VK_* code with respect to layout (for ASCII 
symbols).

Thanks!
Anton.

On 23.05.2014 20:06, Sergey Bylokhov wrote:
> Will be better to investigate it now, if it is not urgent.
>
> On 5/23/14 7:56 PM, Petr Pchelko wrote:
>> 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 
>> <anton.nashatyrev at oracle.com> 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 
>>>> <anton.nashatyrev at oracle.com> 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 
>>>>>> <anton.nashatyrev at oracle.com> 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.
>
>