Hello, Anton. The fix looks good to me too.
With best regards. Petr. On May 28, 2014, at 10:04 PM, Anthony Petrov <[email protected]> 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. >>>>>>>> >>>>>> >>>> >>
