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.
