Re: Newt, wrong keycode for # key?
Posted by
Xerxes Rånby on
Dec 02, 2014; 2:00pm
URL: https://forum.jogamp.org/Newt-wrong-keycode-for-key-tp4033690p4033692.html
NEWT is designed to map KeyChar to Unicode as close as possible
The keyCode mapping follows a US/ANSI mechanical keyboard layout by
design in order to have the same physical key position mapping on
all systems. [1]
keyCode 92 in decimal is thus mapped to keyChar unicode UTF-16 0xC5
\ [2]
if you use a non US/ANSI keyboard, lets pretend you use a UK/ISO
keyboard layout and press the key labeled in UK # (located close to
return)
then NEWT will give you the US/ANSI keySymbol: 39 because that maps
to UTF-16 0x27 '
on the US/ANSI keyboard # is located on the 3 digit key.
The US/ANSI Keyboard layout looks like this:
http://en.wikipedia.org/wiki/Keyboard_layout#mediaviewer/File:ANSI_Keyboard_Layout_Diagram_with_Form_Factor.svg
There exist three major mechanical keyboard maps ANSI, ISO and JIS
NEWT is currently designed to return ANSI keyCodes for all
keyboards.
This is a ANSI to ISO and ANSI to JIS mechanical key map problem.
[3]
I do not think the operating system can detect the mechanical
keyboard map because the keyboard do not know what kind of
mechanical map it is or what is printed on the keys.
This is the reason why operating systems have to ask the user for
the mechanical and national layout during os installation.
[1]
https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/newt/event/KeyEvent.html
[2]
http://www.unicode.org/charts/PDF/U0000.pdf
[3]
http://en.wikipedia.org/wiki/Keyboard_layout#Mechanical.2C_visual_and_functional_layouts
Cheers
Xerxes
Den 2014-12-02 13:43, Cygnus [via
jogamp] skrev:
Hello, I work on a team that uses JOGL and Newt for a
Java game.
We received a report from players about the key bindings having
issues with the “#” key, it registers as a backslash with the
keybind system. At first we thought it was maybe down to keyboard
layout but after testing it became clear the problem is not caused
by the layout and only affects Newt (keycode correctly returns 520
in AWT).
I put together a simple Newt test application with a basic
KeyListener:
public class TestKeyListener implements KeyListener {
@Override
public void keyReleased(KeyEvent e) {}
@Override
public void keyPressed(KeyEvent e) {
System.out.println("keyCode: " + e.getKeyCode() +
", keyChar: "+ e.getKeyChar() + ", modifiers: " + e.getModifiers()
+ ", keySymbol: " + e.getKeySymbol());
}
}
I then tried it on a couple of different machines (Windows 7 and
Mac OS X Yosemite) to check it wasn't a problem with one specific
platform. The result for the “#” key always returned:
keyCode: 92, keyChar: #, modifiers: 0, keySymbol: 39
The character is correct but keyCode 92 matches VK_BACK_SLASH
(0x5C). The VK_NUMBER_SIGN (0x23) is hard defined 35 so the result
this really doesn't seem to make sense, even the keySymbol if that
was intended to be used instead doesn't match up.
On the flip side backslash (like most keys) behaves correctly:
keyCode: 92, keyChar: \, modifiers: 0, keySymbol: 92
are you sure that both US/ANSI ' and \ key returned keyCode 92?
if that is the case then that is a bug.
I traced it as far back as I could with the Eclipse debugger on a
Windows machine, it comes through from the native side to
WindowDriver.sendKeyEvent(short, int, short, short, char) with
keyCode 92 already.
I've not seen a bug report for it so I'm unsure if this behaviour
is intentional but it seems a strange thing to chose to do.