Input focus stuck in SDK application window


Trying to get started with jMonkey SDK. But every time I compile + run something, my input focus is stuck in the SDK window and blocks everything else while the window of the compiled package (e.g. jme3test.helloworld) is hovering in front, not receiving any mouse or keyboard events except for mouse pointer position. Neither does anything else (except the SDK - I can see my keyboard input happily typing away in the source or output sub-window while I’m desperately trying to close the “helloworld” and/or get focus back to my DE), so I have to change to a different tty and killall java to get things working again.

Any Idea how to fix that?

Product Version: jMonkeyEngine SDK 3.0RC2
Java: 1.7.0_17; OpenJDK 64-Bit Server VM 23.7-b01
System: Linux version 3.8.4-1-ck running on amd64; UTF-8; en_US (jmonkeyplatform)

Little bit more specific please?

Is what I described a well known problem? Couldn’t find anything on it.

No. I’d try switching the LAF first.

Ok, thanks!
… “trying random stuff” it is… :smiley:

  • Same Problem with other LAF
  • Same Problem with oracle JDK
  • Same Problem with other graphics card + driver
  • Deactivated most of my DE (compiz, window decorator, panel, most custom settings including nvidia etc) => problem got worse, application window stopped receiving mouse polling
  • Switched to a clean xfce4 session => problem “reversed”: I’m stuck in the “jme3test.helloworld” and it catches (almost) all input. As jme3test.helloworld receives keyboard events though, so I can end it with esc which is a lot better.
  • Tried again with my standard DE, this time running java / jme3test.helloworld manually from vt. Same problem as in OP, but thanks to keyboard focus staying in the vt, I can kill the VM with ctrl+c.
  • Located part of the reason for the original problem: compiz focus stealing prevention. With that deactivated, I get the same behaviour in my DE as in vanilla xfce4. Which is still sort of bad, but at least I don’t have to kill any processes.

So… guess this turned out NOT to be a problem with the jMonkeys IDEapplication (other applications that call the jar, p.e. a terminal, are affected in the same way) but a problem with the jme3test.helloworld (or engine / standard engine settings). Looks to me like that app sort of tries to catch input events in a way that’s a little “brutal” for my taste (had no such problems when I tried various basic libwjgl & other “hello-worlds” with comparable functionality as the jme3test.helloworld).

Will this probably turn out to be something that I’m supposed to be handling better later (like in less simplistic applications: don’t restrict the mouse to the window and catch only keys that are associated with something) once I get to know jmonkey or does it sound like a problem that is part of the stuff that jmonkey handles for me and will affect all applications (unless workarounds are implemented)?

Its most probably an issue with the LWJGL/system interaction but LWJGL is due to be replaced by JOGL anyway. The continuing amount of issues on both Linux and Mac in terms of windowing and as in this case input (most of it is focusing “hacks” due to the gl/windowing integration) is one reason for that.

oops, that last edit was too slow:

me wrote: edit: Tried more window managers, everywhere the same and I'm confused. Have not been able to figure out why jme3test.helloworld keeps various window managers from doing their job and where I should "complain" about that xD (java/xorg/jmonkey/all-existing-window-managers?) - is jmonkey somehow deliberately using raw input directly with native libs or something like that?

Guess that means I should try around with LWJGL a little more then before I go bother the “Xorg People”…? Not sure if java/lwjgl should even be able/allowed to “steal” input from the WM (unless it deliberately used an override or something that was designed specificly to access hardware on a lower lvl [or something])…

If you don’t want the jme app to catch the mouse when its active then turn that off with inputManager.setCursorVisible(true)

After looking around some more, I get the impression that this is a common problem with Xlib not feeling responsible for what happens between its layer and the WM (letting other applications / toolkits walk all over the WM) which leaves the responsibility to respect the WM’s needs at a per-application level.

“inputManager.setCursorVisible(true)” helps only a little… everything is still sort of “glitchi” and it’s hard to p.e. get out of the java application without closing it - especially if it runs on its own workspace all alone - but I should be able to figure out the rest on my own as get more familiar with everything.

1 Like

In Retrospect: Noticed that I have no Problems whatsoever if I use a Canvas + JME: works a LOT better for my Desktop than anything I’ve been able to achieve with just plain JME. Also the window-manager is very “happy” because he can resize those windows :wink: