Is there a SWT version of the JMEDesktop functionality planned or currently possible?
I want to show Composites of an SWT Shell over a JME rendering – exactly like how TestJMEDesktop looks when fullscreen is selected except with SWT instead of Swing. I don't really need the perspective look of TestJMEDesktop for my project.
If not, I'd be happy to attempt something with a little direction and assistance. I've been using jME for a while, but I'm a noob when it comes to the internal workings of SWT .
Thanks for all the awesome work so far!!!
I think this is not possible easily. SWT paints the components as natively, which means it uses native methods for the look and feel of the controls. Thus drawing to a texture on or the back buffer is not possible. If you still want to achieve your goal, you would need to implement a new SWT native version which allows integration with lwjgl… I don't think that's worth it.
What's wrong with Swing? 
(I know what's wrong in general, but I mean for your project ;))
There's no project constraints that would prevent me from using Swing. This is an internal project and I thought I'd try it with SWT just for the experience of it.
I didn't know that SWT paints with native calls. I'm compiling against version 3.4 of swt.jar downloaded from eclipse.org. The absence of any *.so libraries (I'm on linux-x86_64) made me assume it was a pure java implementation. Now I see, from their website, my distro just happened to have all the dependencies already installed.
But… Swing does it too. My platform default L&F (GTK) uses com.sun.java.swing.plaf.gtk.GTKNativeEngine, which is all native calls! The class javadoc even says "GTKNativeEngine delegates all painting job to native GTK libraries." (yes, that's their grammar) ;) And TestJMEDesktop looks all GTK just fine under that L&F.
So I guess I'll do this project with Swing, but now I want to delve a little deeper into this – seems to me that if Swing can use native calls to do painting and still be able to render to a texture on a quad then SWT ought to be able too.
"New and noteworthy" for swt 3.4 (Eclipse 3.4 Milestone New and Noteworthy Items - SWT) says that:
"API was added to allow the drawing of any Control to a GC. For more info, check out Snippet 292"
This is a tantalizing development. :-o After all, Composite and Shell are subclasses of Control. 
And combining it with another "New and noteworthy" for swt 3.4:
"There is new SWT API that allows the setting of an alpha value on a shell."
makes me positively salivate at the possibilities.
Interesting. This could mean it's possible now.
If you try to implement it be aware that you can spend a whole month (or two, or three) to get an JMESWTDesktop working smoothly.
Looks like this would be possible now, but it still would be a huge task to do it though. But after all, it would only be a general PaintListener, that does the drawing on an image GC and avoid painting on the original GC somehow. Looking forward to your tech demo :evil:
Btw, the reason, why there are no native libraries necassary is, that they come bundled with the SWT jar file. SWT then seemlessly extracts the library and adds it to the library path at runtime.
Remember too that until they solve the mac/swt/cocoa issue, our swt support on mac is limited (and any new swt usage needs to be checked against the fake swt jar I made)
I wouldn't try to create a integration of SWT in jME, because you don't win anything, but lose the biggest advantage of SWT (its native integration into the host GUI system), because you would have to do the painting all by yourself.
SWT applications becoming more popular every day, so the other way of integration (jME in SWT) is hard enough. I am still wondering, if it is still a problem with jME 2.0, to have more than one jME views/editors open at the same time. But we will see, when we have finished the migration of MW3D form jME 1.0 to jME 2.0 (which is a huge task alone for the jME itself)
Currently we don't have so much active members in our team, that have Macs, so this Mac issue will be a problem for us too. Ehm, but its getting off topic now :-o
I disagree. From a few posts ago:
"New and noteworthy" for swt 3.4 (Eclipse 3.4 Milestone New and Noteworthy Items - SWT) says that:
"API was added to allow the drawing of any Control to a GC. For more info, check out Snippet 292"
When I ran Snippet 292 with native (GTK) L&F it behaved exactly as expected – the image was GTK L&F. This tells me that SWT still uses native calls to do the painting, then copies it to your GC.
Btw, I'd be happy to help with the MW3D migration to 2.0. I've used MW3D (mostly playing with the terrain plugin), and I'm developing my project against jME trunk in preparation for jME 2.0. Somebody knowledgeable would have to oversee me cuz I'm not up on the differences between 1.0 and 2.0. I'm not that experienced in jME or 3D in general, but I do have 30 yrs if programming experience, 20+ in object-oriented languages, with the last 9 exclusively in Java.
JavaRay said:
When I ran Snippet 292 with native (GTK) L&F it behaved exactly as expected -- the image was GTK L&F. This tells me that SWT still uses native calls to do the painting, then copies it to your GC.
Btw, I'd be happy to help with the MW3D migration to 2.0. I've used MW3D (mostly playing with the terrain plugin), and I'm developing my project against jME trunk in preparation for jME 2.0. Somebody knowledgeable would have to oversee me cuz I'm not up on the differences between 1.0 and 2.0. I'm not that experienced in jME or 3D in general, but I do have 30 yrs if programming experience, 20+ in object-oriented languages, with the last 9 exclusively in Java.
Ok, it only draws to an offscreen image that then can be used as a texture. In this case, there is no performance drawback of course. If there is something like an event hook in SWT, then its possible to generally switch the GC and take the result as a texture to display it wherever it is needed. Interesting approach to integrate SWT applications in a 3D environment like Project Wonderland...
I'm sure Tareq would welcome you with open arms to help with migration to jME 2.0. I'll send you a PM, where we can discuss that, if you like.