I've been using jmedesktop for awhile, but while migrating to the latest code base I'm having some trouble calling setup on new desktops. I'm using jmedesktops to manage displays in my cockpit. My main jmedesktop that handles menus and such for the game works fine, but when I try to instantiate my glass displays (which extend JMEDesktop) I run into issues where it's not creating the textures and such in setup.
public GlassScreen(PlayerVessel ship, Spatial spatial, String gameStateName, int w, int h) {
super(gameStateName);
this.ship = ship;
this.spatial = spatial;
glassScreenList.add(this);
this.width = w;
this.height = h;
Runnable initDesktop = new Runnable() {
public void run() {
setup( width, height, false, null);
}
};
try {
SwingUtilities.invokeAndWait(initDesktop);
} catch (InterruptedException e) {
Imp.addErrorToQueue(e);
} catch (InvocationTargetException e) {
Imp.addErrorToQueue(e);
}
But I keep getting:
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(Unknown Source)
at javax.swing.SwingUtilities.invokeAndWait(Unknown Source)
at imp.ingame.ship.cockpit.GlassScreen.<init>(GlassScreen.java:69)
at imp.ingame.ship.cockpit.CockpitDisplay.<init>(CockpitDisplay.java:23)
at imp.ingame.ship.cockpit.CockpitDisplayManager.<init>(CockpitDisplayManager.java:33)
at imp.ingame.ship.cockpit.Cockpit3d.<init>(Cockpit3d.java:78)
at imp.ingame.vessel.PlayerVessel.<init>(PlayerVessel.java:126)
at imp.ingame.vessel.classes.SH_F34.<init>(SH_F34.java:58)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at imp.net.NetManager.createObject(NetManager.java:275)
at imp.net.NetManager.update(NetManager.java:252)
at imp.Imp.update(Imp.java:304)
at com.jme.app.VariableTimestepGame.start(Unknown Source)
at imp.Imp.main(Imp.java:118)
Caused by: java.lang.NullPointerException
at org.lwjgl.opengl.GL11.glGenTextures(GL11.java:1317)
at com.jme.scene.state.lwjgl.LWJGLTextureState.load(Unknown Source)
at com.jme.scene.state.lwjgl.LWJGLTextureState.apply(Unknown Source)
at com.jmex.awt.swingui.JMEDesktop.setup(Unknown Source)
at imp.ingame.ship.cockpit.GlassScreen$1.run(GlassScreen.java:64)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Sounds like the old threads and OpenGl call problem.
Calls to G11 need to be done in the main thread, try without the Runnable
Yeah, that's a good thought, but I already tried that. It throws a java.lang.IllegalStateException and warns me "Not in swing thread!" Heh. Sounds like it's not happy in the main thread or the swing thread.
There's a built-in way to inject it into the Swing thread, but Irrisor will have to remember for me. 
In the test setup it is in the gl (main) thread. And there it should be. You should not get an IllegalStateException.
I'm sorry Irrisor, I don't quite follow what you're trying to say.
I mean, you should not get an IllegalStateException, please post the stacktrace if you really get one.
Ok. Well if I call setup from the Main Thread I get:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at imp.net.NetManager.createObject(NetManager.java:275)
at imp.net.NetManager.update(NetManager.java:252)
at imp.Imp.update(Imp.java:304)
at com.jme.app.VariableTimestepGame.start(Unknown Source)
at imp.Imp.main(Imp.java:118)
Caused by: java.lang.IllegalStateException: not in swing thread!
at com.jmex.awt.swingui.JMEDesktop.dispatchEvent(Unknown Source)
at com.jmex.awt.swingui.JMEDesktop.setFocusOwner(Unknown Source)
at com.jmex.awt.swingui.JMEDesktop.setup(Unknown Source)
at imp.ingame.ship.cockpit.GlassScreen.<init>(GlassScreen.java:76)
at imp.ingame.ship.cockpit.CockpitDisplay.<init>(CockpitDisplay.java:23)
at imp.ingame.ship.cockpit.CockpitDisplayManager.<init>(CockpitDisplayManager.java:33)
at imp.ingame.ship.cockpit.Cockpit3d.<init>(Cockpit3d.java:78)
at imp.ingame.vessel.PlayerVessel.<init>(PlayerVessel.java:128)
at imp.ingame.vessel.classes.SH_F34.<init>(SH_F34.java:58)
Strange… it should not get there from the setup method… please make sure you call setup(…) right after creation of the desktop. Have a look at HelloJMEDesktop or TestJMEDesktop to find the difference in setting your desktop up - it works there (possibly double check the test are actually working at your side).
Ok. I've moved setup to right after the super constructor call and still get the same (not in swing thread) error.
When I create the JMEDesktop that drives my GUI at application initialization it works OK (as it always has). I only seem to be having this issue with desktops created during gameplay. As I mentioned earlier, in previous versions (0.9 and before I believe) I didn't see this issue and everything worked as expected.
I don't remember that anything related to later creation was changed. I'm afraid you need to create them when the app starts then or debug it yourself, as I don't have the time to do it in near future.
Ok. When you do get a chance to take a look the problem seems to be in line 397 of JMEDesktop. I just commented out
this.setFocusOwner( desktop );
And the problem went away and functionality still seems ok. This line was not in my previous version.
Edit: Alternately, you could call setFocusOwner from the swing thread if you really need it in there.
That line was introduced by a user submitted patch on 30.05.06 (so it's not a recent change) to fix a button focus problem. I have wrapped it with a runnable to inject it into the swing thread. Please give it a try.