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

Wed May 28 18:11:11 UTC 2014

Hello, Anton.

The fix looks good to me too.

With best regards. Petr.

On May 28, 2014, at 10:04 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Anton,
> 
> Thank you for your hard work. The updated fix looks fine to me.
> 
> --
> best regards,
> Anthony
> 
> On 5/28/2014 9:56 PM, anton nashatyrev wrote:
>> Hello,
>> 
>>     I've checked my old fix and found a problem: the dead keys don't
>> work in the passive client: the KEY_TYPED event doesn't contain the
>> composed char (e.g. contains 'o' instead of 'ô').
>> 
>>     Please take a look at the new fix. I've added both 'characters' and
>> 'charactersIgnoringModifiers' to the NSEvent. The latter is now only
>> used for calculating a VK_ keyCode. For this fix I've checked all the
>> KeyEvent reg tests (auto + manual), tried different combinations you've
>> suggested with the im/IMFTest, tried different input methods for Japan
>> and Chinese locales.
>> 
>>     BTW those double symbols sometimes arise when typing via VNC; with
>> the directly connected keyboard this is not reproducible.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028617
>> The fix: http://cr.openjdk.java.net/~anashaty/8028617/9/webrev.01/
>> <http://cr.openjdk.java.net/%7Eanashaty/8028617/9/webrev.01/>
>> 
>> Thanks!
>> Anton.
>> 
>> On 27.05.2014 15:35, Anthony Petrov wrote:
>>> Hi Anton,
>>> 
>>> Interesting. I'm not sure if 'oô' looks very good, however, I agree
>>> that 'ôô' isn't much better. I suggest to file a follow-up issue to
>>> fix IMs on Mac.
>>> 
>>> What I'm mostly concerned about is how Shift behaves after your fix?
>>> If on FR keyboard you press '[', Shift+'o', what characters does this
>>> produce? And what was before your fix? If you still can type the
>>> capital 'Ô' character, then it's fine.
>>> 
>>> Also, on a DE keyboard, could you try pressing [ and ' keys both w/
>>> and w/o Shift? They should produce the characters üÜ and äÄ
>>> correspondingly. Also, on the DE keyboard, the _ key is very
>>> interesting. W/o Shift it produces 'ß', while with Shift pressed it
>>> should produce '?'. Also, "=" is a dead key on the DE keyboard. You
>>> might want to play with it as well.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 5/27/2014 2:30 PM, anton nashatyrev wrote:
>>>> Hi Anthony,
>>>> 
>>>>     yes, when using dead keys the behavior changes after the fix.
>>>> 
>>>> In the text field when pressing '[', 'o' on FR keyboard:
>>>> before the fix: 'ôô'
>>>> after the fix: 'oô'
>>>> 
>>>> I suppose that both cases are not correct (in the first we get
>>>> duplicated character). Hope to talk to you offline on how to handle both
>>>> problems.
>>>> 
>>>> Thanks!
>>>> Anton.
>>>> 
>>>> On 23.05.2014 20:14, Anthony Petrov wrote:
>>>>> On 5/23/2014 8:04 PM, anton nashatyrev wrote:
>>>>>>     could you please point me to the i18n tests you have mentioned?
>>>>> 
>>>>> test/java/awt/im ...? In both open and closed repos.
>>>>> 
>>>>> 
>>>>>>     from non-English I'd tested only Russian locale. Do you have in
>>>>>> mind some special cases for other locales?
>>>>> 
>>>>> No, RU isn't a particularly interesting layout in this respect. Please
>>>>> try at least DE and FR keyboards. The Q, Y, and Z keys are exchanged
>>>>> on those. They support special characters on OEM keys (such as -=[];"/
>>>>> etc.) Also, they support dead keys. E.g. on a FR kbd, try pressing [
>>>>> and then some other character key. Also try AltGr+7 and then again
>>>>> some other character key. After pressing a dead key, try to press a
>>>>> letter key with the Shift modifier. Etc.
>>>>> 
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>>> 
>>>>>> Thanks!
>>>>>> Anton.
>>>>>> 
>>>>>> On 23.05.2014 19:44, Anthony Petrov wrote:
>>>>>>> Thanks for confirming that. I'm OK with the fix then.
>>>>>>> 
>>>>>>> However, I also suggest to run some i18n tests and also try some
>>>>>>> non-English keyboard layouts (DE, FR, JP, etc.) with special
>>>>>>> characters and dead keys to ensure they aren't broken.
>>>>>>> 
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>> 
>>>>>>> On 5/23/2014 7:39 PM, anton nashatyrev wrote:
>>>>>>>> Anthony,
>>>>>>>> 
>>>>>>>>     yes, the CapsLock works for me as well.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> Anton
>>>>>>>> 
>>>>>>>> On 23.05.2014 19:35, Anthony Petrov wrote:
>>>>>>>>> Hi Anton,
>>>>>>>>> 
>>>>>>>>> If you activate the CAPS LOCK mode and type some characters, will
>>>>>>>>> those be presented as capital letters in Swing/AWT's text fields
>>>>>>>>> and
>>>>>>>>> text areas after your fix? (see [1] for a related FX bug)
>>>>>>>>> 
>>>>>>>>> [1] https://javafx-jira.kenai.com/browse/RT-16616
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>> 
>>>>>>>>> On 5/23/2014 7:14 PM, anton nashatyrev 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.
>>>>>>>> 
>>>>>> 
>>>> 
>> 