views:

189

answers:

1

We want to quickly prototype widgets in Java. We overlay them on top of a display written in a proprietary 3rd party graphics package. We find that the Java GUI steals keyboard focus away from the window manager.

The window manager is fvwm, I've tried configuring it so the Java app is setup not to get focus, and furthermore if it ever does get focus to take it away and give it to the other GUI.

If I run this with the Java app it doesn't work (whenever the mouse is over the Java GUI it has keyboard focus)- if I swap some standard X GUI widget (XEyes) in place of the Java GUI it works like a charm. This lends some creedence to the claim (maintained by the people at fvwm) that Java is not respecting the ICCCM.

I'm wondering if other people have solved this problem and if so how. So far I have a few choices for how to try and fix this:

1) twiddle Java settings, hoping that if I turn off focus there maybe it will hand back focus control to the window manager (so far I've tried "setFocusable(false)" on the parent JFrame. This didn't work. A thread "http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/awt.html#gdaao" indicated I should instead do "Window.setFocusableWindowState(false)" The GUI in question hasn't been redone in a Window yet but I'm also not completely convinced that Java will relenquish the focus

2) make low level X calls in the Java program using JNI. I think this would probably work, but, I've never played much with low level X. I'm unsure what calls I should be using (XtSetKeyboardFocus() is supposed to be dangerous to call...) or how I can identify the GUI's I'm operating on (in this respect fvwm was nice since they had a GUI that allowed you to click on another GUI and find out its "name" and "class")

3) use a "stronger" window manager. Some window managers that don't use ICCCM might be able to deal with Java better. Of course, there are a plethora of managers, and I'm not sure what to concentrate on. Likewise many seem to be short on specifying focus by app (most seem only to care about broad policies).

+1  A: 

Finally the prototype was reworked in a JWindow rather than a JFrame, and when that JWindow had setFocusableWindowState(false) called on it Java did hand back focus... problem solved.

Dan S