Whether the key variable is set to CODED or not is inconsistent between the default renderer and P2D/P3D

[processing-bot]

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

1. Run the simple program below with the default renderer.
2. Press F1. The output is:

key=65535
keyCode=112

3. Run the program using either P2D or P3D: size(1280, 720, P2D);
4. 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:

1. In the PsurfaceJOGL.isPCodedKey private 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) {

2. 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));

3. Pass nativeEvent.isPrintableKey() to isPCodedKey(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

[processing-bot]

Created by: benfry

Thanks for looking into it and the thorough writeup. Will try this out when I have a moment and see about getting it into the next release.

[processing-bot]

Created by: ChristopherCanfield

Thank you!

[processing-bot]

Created by: benfry

Thanks again, just merged your suggestions in for beta 6; we'll see how it goes!

[processing-bot]

Created by: ChristopherCanfield

Thank you for implementing this!

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.