There are some hotkeys that do not work when the cmd key is specified (macOS)

[misaki-eymard]

Description:
There are some hotkeys that don't work properly when the cmd key is specified in the hotkey, as if the key had been pressed multiple times.

--- General ---

• Pan Drag
• Zoom Drag
• Pan Move
• Zoom Move

--- Playback ---

• Timeline Pan Drag
• Timeline Pan Move
• Timeline Frame Drag
• Timeline Frame Move

Here is a video shows the issue:
https://github.com/EsotericSoftware/spine-editor/assets/85478846/a0284b08-fdd2-42c0-98a6-1678b728f91a

Also, although it will not behave as if the key has been pressed multiple times, the following hotkeys will no longer be recognized when cmd is specified.

--- Tools ---

• Last Tool

Here is a video shows the issue:
https://github.com/EsotericSoftware/spine-editor/assets/85478846/b3636e3e-9ab4-4b8f-b29a-3d14cb4fb6de

Expected behavior:
Even if you specify the cmd key, the hotkey will still be recognized normally.

Steps to reproduce:

1. Open Spine 4.2.29 on Mac PC.
2. Make sure you can drag and pan while holding down the J key in the viewport.
3. Open the hotkeys.txt file and edit Pan Drag: J to Pan Drag: cmd + J.
4. Reload the hotkeys file and press cmd + J when the viewport is active. Then you will notice that Pan Drag is no longer working.

The version of Spine in which this problem was found:
Spine 4.2.29

[davidetan]

The issue here seems to be connected to the fact that while keeping pressed cmd + KEY:

• LWJGL: behaves like if additional key are pressed
• JGLFW: continuously report a key down and key up events

If we keep a single key press, without modifer cmd, in KeyNames.java:

• LWJGL: just outputs 1 charachter (DefaultLwjglInput set Keyboard.enableRepeatEvents(false). If I set it to true, it continuosly outputs the same character).
• JGLFW: continuosly outputs character.

---

Moreover, if I overwrite the key method in GlfwInputProcessor like this:

public void key (long w, int key, int scancode, int action, int modifiers) {
	switch (action) {
	case GLFW_PRESS -> System.out.println("GLFW_PRESS");
	case GLFW_RELEASE -> System.out.println("GLFW_RELEASE");
	case GLFW_REPEAT -> System.out.println("GLFW_REPEAT");
	}
}

and run a basic example of JGLFW that just set the callback key like the above function, I have different behaviour.

In editor repo if I keep pressed cmd + KEY, I get:

GLFW_PRESS -> cmd
GLFW_PRESS -> j
GLFW_RELEASE -> j
GLFW_PRESS -> j
GLFW_RELEASE -> j
GLFW_PRESS -> j
...
GLFW_RELEASE -> j
GLFW_PRESS -> j
GLFW_RELEASE -> j
GLFW_RELEASE -> cmd

In the basic JGLFW example if I keep pressed cmd + KEY, I get:

GLFW_PRESS -> cmd
GLFW_PRESS -> j
GLFW_REPEAT -> j
GLFW_REPEAT -> j
...
GLFW_REPEAT -> j
GLFW_RELEASE -> j
GLFW_RELEASE -> cmd

The difference is that in the editor we have libgdx in the middle.
So, I have to try with a plain libgdx example.

[davidetan]

Further debugging leads me here: badlogic/jglfw@6625d36
That cause a key release, and not repeat, when a key is kept pressed along with cmd modifier.

[davidetan]

If we just keep the else branch of the commit above, we don't have this bug.

In any case, when the code enters that if, it continuously generates GLFW_RELEASE events, this is why we have the strange behaviour showed above, that is:

• alternate GLFW_PRESS, GLFW_RELEASE for the key kept pressed along with cmd

rather than just GLFW_RELEASE.

The bug that custom sendEvent fixes, does not need of the additional attempt, if the app is not GLFWApplication.
Because at least in java, when we call java.awt.Toolkit.getDefaultToolkit() in JglfwApplication#initialize, it initializes Apple AWT that initializes our NSApp, extending it as a NSApplicationAWT.
We received the keyUp event because Apple AWT does the sendEvent fix for us: https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L373

So, after that I'm confident in removing the if above and just leave the else branch because:

• In case we have a GLFWApplication, our jglfw does the sendEvent fix.
• In case we have a NSApplication, Apple does the sendEvent fix.

Or, if we want to keep the thing similar as possible, we could change the internal if like this:

if (![NSApp isKindOfClass:[GLFWApplication class]] && ![NSStringFromClass([NSApp class]) isEqualToString:@"NSApplicationAWT"])