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
<[email protected]> 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
<[email protected]> 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
<[email protected]> 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.
