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

[Anthony Petrov]

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