Do you want Swing or SWT? (7 day poll)
I added a couple more options and voted. 
Since a lot of the drive for this in the other topic is image handling, I’ll just point out again that javax.imageio provides a reference implementation for doing this, and probably should be used either directly or as the model.
It’s also worth noting that the current implementation of the display configuration dialog uses AWT/Swing, and would need to be replaced by a SWT version. (Though this is not a major issue. The dialog needs a minor overhaul as is, for better failure indication.)
As for image loading, the more jME handles internally, the better. I’m all for reducing our reliance on external APIs.
I had to write BMP load/save java support over the last two weeks. When I get a chance, I’ll try to rewrite it in javax.imageio format, and donate it as a starting point. Probably won’t happen immediately as I’m really busy the next couple of months.
I too agree that if we can implement the image loaders somehow, there’s really no need to bind jME to any gui toolkit. A SWT configuration screen could be a nice addition to Applications and Tools page, though.
I’m abstaining b/c the poll question groups two very different functionalities. I believe we should handle image loading internally, but GUI questions should be left open to interpretation. Greg’s GUI stuff is very nice for people who would like to handle the GUI in OpenGL, but if you want to handle a gui outside the bounds of opengl why should jme (an opengl specific library) provide special bindings for you? Maybe there is a reason, but I’ve yet to hear it.
"renanse" wrote:
I'm abstaining b/c the poll question groups two very different functionalities. I believe we should handle image loading internally, but GUI questions should be left open to interpretation. Greg's GUI stuff is very nice for people who would like to handle the GUI in OpenGL, but if you want to handle a gui outside the bounds of opengl why should jme (an opengl specific library) provide special bindings for you? Maybe there is a reason, but I've yet to hear it. :)
I agree. I also think that the loading screen should be optional( for demos and games early in development), ease to remove, and work with AWT because most people have it. ;)
Well, the loading screen is optional insofar as you can specify setDialogBehaviour(NEVER_SHOW_PROPS_DIALOG). You could also remove it with a minor alteration to AbstractGame.
Ok, I agree about the image loading in general, that it would nice to be built in. However, the basic windowing in SWT is very nice, especially with the LWJGL now having an SWTCanvas which allows for OpenGL rendering surface combines with all the standard SWT stuff. (I know, I know, we are working on a widget toolkit, but our’s is for within the OpenGL environment.)
Since LWJGL is now packaging SWT with it, it’s not too much of a jump. And since the imaging stuff is already there… why not use it?
So, I guess everyone knows where I stand 
Oh well, hey I don’t pretent to be the brightest bulb in the cupboard so I’ll go happily with whatever is decided.
Bottom line… I really think renanse has hit it on the nose, let’s plug and play gui libraries.
LWJGL is currently not shipping with SWT support. There is a build under the download section that contains SWT support, but it’s an “unofficial” build.
The reason for SWT not being included yet, is because it is Win32 only at the moment. Once SWT support is done on all platforms, it should be included in the distribution.