JFileChooser freezes JME3 in fullscreen

Since Nifty has no native file chooser I’m using the ancient one from swing which works well when the app is running in windowed mode but when launched in fullscreen the mouse starts to show a windows “loading please wait” icon, but the chooser never appears and the window freezes if I click again. The code:

JInternalFrame tempFrame = new JInternalFrame();
JFileChooser chooser = new JFileChooser();
chooser.setDialogTitle("Load From File");
int returnVal = chooser.showOpenDialog(tempFrame);
if(returnVal == JFileChooser.APPROVE_OPTION) {

Should I not be using JInternalFrames? Or is there a workaround?

I’m not sure if Java dialogs would work like this. You’ll probably need to make your own dialog based on Nifty or any other gui engine. On full screen mode you can’t see your desktop which holds the standard windows based objects.


first problem would be fullscreen, yes. When you open a file chooser, it could minimize/unfullscreen etc depending on the window manager (test it on Windows, OSX and Ubuntu if you want crossplatform support).

However it would work, it would throw you out of the game for file choosing.

  1. Swing cannot run on the Render thread. We made our first version of the mapeditor with Swing and jMonkey, requiring two threads. The communication between these can be horrible! Really terrible! Even with a bus system, you have two threads that behave differently on windows, linux and osx.

I believe it was SwingUtilities.invokeLater if you want to implement the file chooser now for quick and dirty work. (http://stackoverflow.com/questions/12077245/what-is-swingutilities-invokelater)

I do recommend that you create your own file chooser.
Reading file system information in crossplatform environments is actually very comfortable in java :smile:

Yeah I’m going to make my own then. Uptil now I was being lazy using the swing one and leaving this for another day. I have no experience in making a thing like a file chooser but there should be plenty of help everywhere right?

well the nifty side shouldn’t be too difficult once you’ve gotten comfortable with niftyGUI custom controls (read the manual on that http://sourceforge.net/projects/nifty-gui/files/nifty-gui/1.3.2/nifty-gui-the-manual-1.3.2.pdf/download )

And handling files in java is quite simple. The internet probably answered all questions you will have about that part :smile:

I’d say if you have trouble understanding how the nifty part works and can’t find the answer in nifty GUIs doc (or on this forum), post here again :wink:

I already have. Read the manual and asked on the forum about problems since I was making a main/pause menu. The manual lacks a bit on the Java side, steering people into XML which I hate passionately. Nifty is made in a way that allows only Java but the documentation on it is poor. Good thing these forums exist :stuck_out_tongue:

What do you have against XML? I think it’s a lot cleaner if you can split the GUI code into handling and layout and I also think that the code itself looks a lot cleaner in XML.

1 Like

Mostly what annoys me is people’s attitude about it:“Oh XML is so awesome lets use it everywhere”.
How about no. With this attitude I cannot bring myself to learn it, alas I don’t use it.

Yes, XML is ugly and people do use it everywhere possible, even if it’s a really bad idea.
However it is handy for UI development. Just think about multiply nested layouts (like we have them).
In XML you immediately see the dependencies.

The Java Builders offer the same interface as the XML interface. Don’t forget to check the wiki as well (https://github.com/void256/nifty-gui/wiki/Button).
That is the only downside to nifty if you ask me. fragmented documentation. Wiki + Manual.

I really suggest you learn to use XML. It is really really simple (it’s basically only tags. No magic at all.)
You dont have to understand XSLT or so to properly use XML.
I do recommend you set your tag to the following though, so you can use XML auto-complete

<nifty xmlns="http://nifty-gui.sourceforge.net/nifty-1.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://nifty-gui.sourceforge.net/nifty-1.3.xsd http://nifty-gui.sourceforge.net/nifty-1.3.xsd">

The positive side about XML layout is that you don’t have to recompile to change the UI layout.
Thus you could even allow your users to mod the UI without decompiling your code.
We have our basic UI layed out in XML and populate dynamic Elements with.

We build a static version of our dynamic UI in xml first as its quicker to change.
Then when we know how it works we extract it into a custom control and generate it via a Java Builder.