What about using SWT instead of AWT? This would allow for the image library replacement. Cleaner work with LWJGL since they are now supporting SWT and very easy usage of GCJ when you want to create an exe from all your work.
I for one don’t know SWT at all, but am not opposed to using it. This would require a vote and someone who knows SWT to implement it.
I definitely support the idea. SWT is a fine toolkit and this would solve two problems at once, as mentioned. Alas, I also don’t know so much about it but I’m thinking of learning it during the summer. I might be able to help then, though I suspect that there are some SWT proficient people lurking here already.
Isn’t this an aditional download for someone who doesn’t already have it ?
If you are using eclipse IDE then you are already using it. If you aren’t using eclipse… why not? 
<cough> intellij
<cough cough> netbeans (i am lovin it)
I use an old vershon of netbeans ide.
Not to get into a Swing vs SWT thing… but performance is head and shoulders over Netbeans. I suggest trying it out. Of course I have to admit that I’m far more comfortable with SWT mostly because it reminds me so much of my C++ Win32 days. And for the same reason I’m not so comfortable with Swing. Which I totally admit is ONLY opinion.
Anyhow…
Correct Guest… We are in the <:)>XHTML</:)> world now.
I tried eclipse 2.1.2 vs. netbeans 3.6 lately and i can’t see any difference speedwise between them on my system and as i am used to it since 3.0 i think i’ll stick with it.
But this was not my point.
I thought about everybody wanting to play some jME based games has to have SWT installed or aditionally download it vs. swing being already on each java enabled system.
Martin
"winkman" wrote:
I thought about everybody wanting to play some jME based games has to have SWT installed or aditionally download it vs. swing being already on each java enabled system.
Martin
Martin
It would be a problem. I think JME should use apis that every one can use and can make commercial games.
I think that the download size wouldn’t be so much of a problem, as SWT is pretty small, about 1 MB. Also their CPL licence seems to permit modifications to the library (http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/faq.html#useStandAlone), so we might be able to strip the image loading capabilities and maybe integrate those into jME directly.
Swing is already enabled on a Java enabled system, of course. However, if GCJ is used to natively compile a program it can also be run on PCs lacking Java, but that cannot be done if any AWT is used. A JRE would be a much larger download than SWT in that case.
"verkel" wrote:
I think that the download size wouldn't be so much of a problem, as SWT is pretty small, about 1 MB.
The problem comes when sum one wants to make a commercial game. They want the insulation to be as easy as possible with as few steps as possible.
If this is about placing a vote, I vote against SWT.
Although I definitely like Eclipse, I cannot see the benefit in using another external library for jme. SWT is not faster than Swing (there are by far enough examples of that) and there is way more information out there on how to solve problems in Swing than in SWT. Apart from that, Swing is already there with your JDK/JRE.
And, btw…
comfortable with SWT mostly because it reminds me so much of my C++ Win32 days
... that(!) is a strong reason not to use it. XD If I were comfortable with my Win32 C++ days, I would not have started using Java. ;)
Yes, you’ve made good points about not wanting to expand dependancies. I agree, ideally we’d want to keep ‘3rd’ party stuff out of jME as much as possible.
I would say the end solution should be jME specific image handling abilities. Most of the C++ Graphics/Game engines out there (ORGE, Genisis3D, Crystal Space) use thier own.
So the idea of stripping out (read plagerizing leagally) from some other library makes a lot of sence to me.
However, the core technology that we use LWJGL is now using SWT. (I know that in the future the desire is to provide for other core stuff, but right now there’s only the one)
So I really don’t see that it’s a big step. Especially since you can now download LWJGL with SWT built in right from the LWJGL site.
honestly speaking, i can’t see the problem, as the widget library is coming into shape, will there be a need for AWT or SWT?
If this is about other things than GUI, such as image loading…etc, it would be difficult to provide our own implementation of Image, although not impossible, but difficult. Or is there a different side to AWT or SWT that I dont know about?
We wouldn’t need SWT for widget handling, never would work in the OpenGL stuff like your widgets.
SWT is a good way to handle windowed applications. You can have an SWTCanvas inside a standard SWT application that uses OpenGL rendering, the rest of the applicaton is totally SWT.
The first thought however was for the image handling and being able to use GCJ to create and exec from a project. With AWT being used GCJ just won’t work.
And then I made the mistake of talking about the SWT based IDE eclipse. I probably should be flamed for even bringing it up. ://
If it comes to image handling questions (which, as I now see, is the real origin for this thread at all), what about jai?
http://java.sun.com/products/java-media/jai/
At least it is a concept coming from sun itself.
I see it that your point is that LWJGL is now using SWT for this sole purpose. But jme was thought to be independent of even that. If someone eventually comes up with a port to jogl, what about SWT images then?
Should there be an abstraction layer for image handling just like there is one for the rendering system?
I’m curious as to what people think is required for jme games to support lwjgl’s swt implementation. If you are going to go so far as to lock yourself into lwjgl and swt, why not explicitly call those lwjgl functions from you game as required?
As far as image loading, I agree with those who say jme should handle that inside the engine itself. Thus any use of swt would be for embedding the opengl screen in a panel within a gui… might as well just make those calls yourself.
I made a pull on this form to see what the comunity wants so vote.