Description
Created by: ChristopherCanfield
Description
Under the default renderer, when a non-printable key is pressed, the key variable is set to CODED (0xffff). The sketch developer can then check the keyCode variable against one of the Processing key code constants (UP/DOWN/LEFT/RIGHT/ALT/CONTROL/SHIFT), or against the java.awt.event.KeyEvent constants if other key codes are needed (e.g., Function keys). This behavior matches the keyCode reference documentation.
When using the JOGL renderers (P2D/P3D), the key variable is correctly set to CODED when one of the seven keys above are pressed, or when the Windows key is pressed. However, pressing any other non-printable key sets the key variable to zero, rather than CODED, which differs from the behavior of the default renderer and the keyCode documentation (though the documentation does warn about differences between platforms). The keyCode variable is correctly set to the NEWT key code, though.
While this is very minor, this difference in whether key is set to CODED or not is a bit confusing at first, especially if a Processing user starts with the default renderer, and then switches to the P2D/P3D renderer as they gain more knowledge.
Expected Behavior
Whether the key variable is set to CODED or not should be consistent between the default renderer and the P2D/P3D renderers. All other behavior, such as the differences in keyCode values between renderers, remains the same as before.
Current Behavior / Steps to Reproduce
- Run the simple program below with the default renderer.
- Press F1. The output is:
key=65535
keyCode=112
- Run the program using either P2D or P3D:
size(1280, 720, P2D); - Press F1. The output is
key=0
keyCode=97
The difference between renderers for keyCode is expected and documented, but the difference for whether key is set to CODED or not is not expected.
void setup() {
size(1280, 720);
}
void draw() {
}
void keyPressed() {
println("key=" + (int) key);
println("keyCode=" + keyCode);
}Your Environment
- Processing version: 4.0b4 (also tested 4.0b2 and 3.5.4; same results).
- Operating System and OS version: Windows 10 Home build 19043.1466
Possible Causes / Solutions
One low-impact way to make the key == CODED behavior consistent between the three core renderers, while keeping all other behavior the same as before, is to edit four lines in PSurfaceJOGL.java:
- In the
PsurfaceJOGL.isPCodedKeyprivate static method (line 1109), add a second parameter for whether the key is a printable key:
- 1109: private static boolean isPCodedKey(short code) {
+ 1109: private static boolean isPCodedKey(short code, boolean isPrintableKey) {- If the key is not a printable key, and is also not a hacky key (checking for this is necessary to ensure the previous behavior remains the same), return true:
- 1117: code == com.jogamp.newt.event.KeyEvent.VK_WINDOWS;
+ 1117: code == com.jogamp.newt.event.KeyEvent.VK_WINDOWS ||
+ 1118: (!isPrintableKey && !isHackeyKey(code));- Pass
nativeEvent.isPrintableKey()toisPCodedKey(short, boolean)in two locations, and remove the isHackyKey check in one location, since it would now duplicate the check within isPCodedKey:
- 1065: if (isPCodedKey(code)) {
+ 1065: if (isPCodedKey(code, nativeEvent.isPrintableKey())) {- 1093: if (!isPCodedKey(code) && !isHackyKey(code)) {
+ 1093: if (!isPCodedKey(code, nativeEvent.isPrintableKey()) {With these changes, the five hacky keys (backspace, tab, enter, escape, and delete) work the same as before, as do the seven key constants listed above in the first section. And the CODED functionality becomes consistent between the default renderer and P2D/P3D.
Thank you for considering this, and for your work on Processing. I’ve been using it to make fun projects with my six year-old son for the past month, after using it for personal projects for years, and he loves it.
Chris Canfield