What is the third parameter Stack<Runnable> mainThreadTasks in the LWJGLPropertiesDialog constructor all about?
It is undocumented, and seems rather useless to me, yet it cannot be null.
As far as I can see the Stack is used only once to add some "ModeValidator" during verifyAndSaveCurrentSelection(). However that validator is only accessed once in the same place, and never again retrieved from the stack.
Is this unfinished work, and if yes, what's the idea behind it, and will it ever be finished? Or am I missing something so blatantly obvious that adding a line to the constructor's javadoc it isn't even worth the typing?
It is a bit of a work in progress, sorry. Mostly in that it is not yet documented. See this thread for some history.
The stack is a workqueue, to be used in the main thread for gl dependent tasks. It is actually used twice in the current properties dialog (once in its construction to detect modes and then as you mentioned in the validation.) In both times, a validator worker is added to the stack and in the main thread, it is removed (popped) from the stack and executed.
This is necessary because, as was pointed out in another thread, the dialog is supposed to be created in the AWT event thread, and event handling (such as the OK button being pressed) also happens in the event thread. Since both of these activities require GL code, there must be a way for that code to be executed in the main thread, since that is where your GL context will be living. Most people do not access LWJGLPropertiesDialog directly, so the changes will not affect them (aside from making jME work nicer on certain Intel cards, etc.)
I recommend taking a look at the changes to AbstractGame, checked in with those changes to LWJGLPropertiesDialog, to see how the dialog is now created and the task queue used. Note especially the use of EventHandler.invokeLater. If you have suggestions on making it better, please post! 
Thank you renanse, that makes it perfectly clear why the stack's there. I think I may have looked in BaseGame, not AbstractGame, and that had me confused. I'll see if I can come up with a good javadoc for the new parameter after I had a chance to get a more global view of the matter!
I've readded the old ctors for backward compatibility.
Even though you are right, renanse, that LWJGLPropertiesDialog should not be accessed directly, game devs don't have another chance if they want it customized. We would need to abstract from the LWJGL specific dialog here…
Most people do not access LWJGLPropertiesDialog directly
Then this would be the patch for jmephysics com.jmetest.physics.SimplePhysicsTest which uses the LWJGLPropertiesDialog directly :)
Index: test-interactive/com/jmetest/physics/SimplePhysicsTest.java
===================================================================
RCS file: /cvs/jmephysics/test-interactive/com/jmetest/physics/SimplePhysicsTest.java,v
retrieving revision 1.1
diff -u -r1.1 SimplePhysicsTest.java
--- test-interactive/com/jmetest/physics/SimplePhysicsTest.java 26 Nov 2007 10:28:35 -0000 1.1
+++ test-interactive/com/jmetest/physics/SimplePhysicsTest.java 20 Apr 2008 09:16:14 -0000
@@ -35,6 +35,8 @@
import java.awt.event.ItemListener;
import java.net.URL;
import java.util.Set;
+import java.util.Stack;
+
import javax.swing.JComboBox;
import javax.swing.JComponent;
@@ -60,7 +62,7 @@
properties = new PropertiesIO( "properties.cfg" );
properties.load();
- LWJGLPropertiesDialog dialog = new LWJGLPropertiesDialog( properties, logo );
+ LWJGLPropertiesDialog dialog = new LWJGLPropertiesDialog( properties, logo, new Stack<Runnable>());
dialog.setVisible( false );
dialog.setModal( true );