As a prelude to trying out some PRs that are currently in-flight, I revisited some the basic test cases to make sure everything else is working first. It isn’t.
When I launch the test chooser with ./gradlew run, I can pick a test case. Most of them actually run. However, I only get mouse input - The keyboard focus remains on the TestChooser window. This means that I can’t get out of the test case without resorting to shenanigans.
Running arch linux, fully up-to-date. Very old nvidia GPU with Nouveau driver (GPU is old enough that I’d need to do some extra config to run nvidea drivers. Not worth it.)
Tested with the following configurations:
Current head w/JDK 11 & 19 (Temurin builds, due to ld.so incompatibility between lwjgl and openjdk builds) as well as openjdk 8 (from before the compatibility problems)
v3.4.0-stable, ditto
v3.1.0-stable w/openjdk 8 (the build script there can’t work on newer jdks)
For the first two bullet points, keyboard focus remains on the TestChooser window. This prevents me from closing the test correctly, and can accidentally trigger a new test case. If I’m smart enough to pull the chooser off to the side so that I can see it, I can kind of key-board navigate and manage to kill windows in sequence to escape the situation. If I fail at that, I end up remoting in from another machine and manually killing the java process.
For the third: In the older configuration, the keyboard output is actually captured by the terminal window that I launched the gradle process from. A CTRL+C command will kill the java process.
I’m very puzzled by this behavior, as I’ve used the test cases in the past, and did not have this issue. I suspect that it isn’t really a JME issue per. se, but I don’t have any idea how this started. Thoughts?
For tests that do not capture the mouse and let you continue to move the system mouse cursor around, if you click the window of the newly opened test app, does focus properly transfer?
I agree with you that it does sound like an OS-related issue.
Yes, using lwgjl2. Haven’t figured out how to test lwjgl3 on the standard examples.
After sleeping on this and coming back to it, I figured out what’s going on. It’s a setting in my window manager for automatically transferring focus to a newly created window, which I have disabled because it’s annoying in other contexts. (My day job is on a windows machine, and the times that I end up typing in the wrong window because I’m moving fast…)
This one threw me because I haven’t experienced it this way before.
Applications that use the mouse as a mouse naturally get focus when you click on something.
Somehow, lwjgl still manages to capture the mouse, even despite “focus-stealing prevention”?
On the positive side, digging into this lead me to learn the keyboard shortcuts for swapping window focus, which I will definitely use regularly.
Addendum: Mouse remains (sort of) captured even when focus is shifted to an unrelated window. I can use the mouse as a mouse across my desktop, but the JME scene still responds to mouse steering as I do so.