What would be just excellent is SWT being adopted by the JDK, and then AWT refactored on top of SWT.
Cas 
Heh, fat chance of that happening.
Well then you truly do have a lot fo redundant code in the JRE with SWT and Swing. And quite frankly I would rather have Swing, since it is āmore javaā and I assume would therefore be much easier to customize. (Iāve customized lots of Swing stuff, but I havenāt programmed SWT and likely never will.)
Anyway as far as JSR-231ā¦ if it can work with SWT, great. If it canāt. I couldnāt care less. Sounds like it can, so there you go. If it is harder I also donāt care, thatās what you get for doing something stupid like SWT. 
Ok ,seriouslyā¦ Sun has done an abysmal job with the windows look and feel. JFileChooser remains so bad that end-users complain about it constantly and we actually lose sales because of it. Until Java 5 pretty much everything else didnāt quite match the native components as well. But I would rather see the effort go in to fixing those issues than to do something like SWT. I Sun had fixed those issues at a reasonable rate (still waiting for a usable JFileChooser on Windows after how many YEARS?) there would be no āneedā for SWT. Itās mainly because in the earlier years (well shortly after they failed to get applets marketed properly) they totally disegarded the desktop side of Javaā¦ I guess they didnāt clue in that all those servers that they were selling might be able to make use of rich clientsā¦
This is so totally off-topic that I must shut myself up nowā¦ sorry for the rant.
SWT integration is one part of a bigger picture. OpenGL is platform agnostic. All it does is draw 3D things. Tehre are extension APIs (GLX, WGL et al) that provide it a handle to operate on. While SWT is probably the most popular non-AWT toolkit, there are also several others, as well as the J2ME market to consider. The basic OpenGL interface should be as free from AWT as it should be from any other windowing-system specific API. Just happens that SWT is the focus for enforcing that requirement in the spec due mainly to its popularity. Note that the JSR writeup says nothing at all about AWT integration being required, just that it is an interface to OpenGL.
Having done AWT and Swing Gui development for many years now it was a pleasant surprise recently to be asked/forced to use SWT for a new rich client development project. I did my best to defend Swing but I have to say Wow! Iām now totally converted. Even with a much smaller feature set than Swing, SWT is much faster and feels the right tool for the job. Itās what AWT should have been in the first place IMO.
So recently I was looking back at my JOGL Swing project which has been sat on a shelf for 6 months and now Iād really like to port everything to SWT asap. So for now though Iām following these threads and the bug reports over on eclipse really hopeing that you guys can hammer out something thats going to blow away other rich client development tools JSR-231 with SWT is the future of opengl development !!! Please make it work nicely together, esp. full screen
Cheers
Peter
What do you mean āEven withā¦ā ? With less features one might expect it to be a bit faster! Though I canāt see how any speed increase could possibly matter, itās a UI framework, and the user can only press the buttons so fast. I canāt work fast enough to make Swing feel slow.
What platform were you using when you compared SWT to Swing? Do you get the same benefits on Linux and Mac? To the same degree? Have you profiled applications that are identical except for Swing vs. SWT? Can the casual user see a difference in performance that is significant enough to warrant the duplicated effort, extra downloads, etc?
[quote]Itās what AWT should have been in the first place IMO.
[/quote]
Yes, I think this is exactly the case. But it came far too late. That ship has already sailed. Now that we have Swing,with a richer feature set than SWT, working plenty fast enough, without hardware accelerationā¦ well that leaves SWT serving no useful purpose.
[quote]ā¦JSR-231 with SWT is the future of opengl development !!!
[/quote]
JSR-231 is the future of OpenGL development. SWT will continue to be used by the minority.
But I agree in principle with Mithrandir, so long as JSR-231 remains neutral in terms of the windowing toolkit, be it AWT, SWT, even LWJGL with the simple support for top-level windows and screens (and by neutral I mean simply that it can be made to work with either one of them, not that no AWT classes are referenced, after all AWT is part of the Standard Java core) - then in my view it meets its purpose. Only if the AWT reference poses an true obsticle to these alternative implementations does something need to be done to address it.
[quote=āCork,post:25,topic:25112ā]
afaik, neither SWT nor JSR-231 mentions anything about fullscreen mode. You will have to use Swing or LWJGL for that
Letās not pollute yet another thread with the SWT vs. Swing argument!
Letās keep this place quiet, so that Mith & Ken can post real, valuable updates on the TOPIC of this thread: the tech details on how it is going (the port of JOGL to SWT, that is).
Mithrandir has made several valuable suggestions on restructuring in the public JSR-231 API as well as in the implementation to decouple the AWT-specific code from the rest of the window system-specific OpenGL-related code. These restructurings have been approved by the expert group (where necessary) and applied to the JOGL source base. At this point I think it should be fairly simple to plug in an SWT port. We have some disagreement as to exactly how that port should be structured but are continuing to discuss it.
Code is done for the Windows version on my end, but not yet checked into my local CVS. I want to do some more testing first and then Iāll post the details here for everyone to try out. Code is under the BSD license, packaged and available under the j3d.org site setup.
OK, general question for the community here. I have a GLCanvas implementation (not the org.eclipse.swt.opengl.GLCanvas) that just extends canvas. From that you can gain access to the underlying GLDrawable instance used for rendering. However, the canvas itself does not extend GLDrawable as that seems like a really badly confused design. Iād like to add the GLAutoDrawable capabilities. Any preferences on the way I would do this?
OK, Time for people to give it a burl. Head over to http://opengl.j3d.org/swt/download.html and download it. It is only for Win32 right now.
Youāll need SWT 3.2M3 or later and also you must use the provided version of JOGL with the download. Iāve had to hack on the RI code to stop it crashing when using SWT so make sure you donāt have the old one there. If you get exceptions about class cast exceptions when you run the example apps, that means you havenāt yet removed the RI JOGL from your classpath. Iāve offered the modifications back to Ken, but not sure if heās interested. As such, no source for the modified JOGL code just yet. If he doesnāt take them, Iāll fork the codebase and maintain our version on j3d.org. Thereās several other changes Iād love to make to the RI codebase, but theyāre mainly for longterm maintenance and more readability. They have nothing to do with the SWT implementation requirements. Weāll see if Ken wants these changes first, then go from there.
Oh, one other thing to note - the APIs for GLDrawableFactory have changed a fair bit since the JSR Beta 1 release. These are the API changes already apparently approved by the JSR committee, but there hasnāt been a JOGL RI release yet to show those to the world. Basically, anything that was creating a GLCanvas/GLPanel from the factory are gone and you can directly instantiate them now. However, since youāre using SWT, that wonāt matter. Download the examples files and have a look at the 3 different ways of using JOGL with SWT widgets and cut and paste those for now. My code currently has no equivalent for the GLAutoDrawable functionality. I want to do something like that, but the fact that GLAutoDrawable unnecessarily extends an interface with AWT-specific concepts in it is preventing me from doing so. Unless the JSR changes that, I wonāt be doing anything along those lines.
Iāll now head over to the Aviatrix3D and Xj3D codebases and add SWT capabilities to those. Iāve not really tried this code with anything other than the simple demos so far. I have no idea how well the pBuffer code will work with this stuff. Weāll see shortly once I have some code that stretches JOGL in all sorts of unusual ways
[Edit: Fixed typo in download link]
Another update
SWT with Aviatrix3D is running nicely. I want to do one more minor bug fix with the context handling on shutdown and then Iāll post an Aviatrix3D 2.0 beta 1 for people to play with, as well as some examples. If youād like code in the mean time, fire me a private email at the usual address. Attached a simple image of my desktop with the very simple animation demo showing.
Very nice!
JOGL is progressing very fast indeed.
Another update. We now have the SWT JOGL code available as a full Eclipse Plugin. Again, itās for Win32 only right now. Head to http://opengl.j3d.org/swt/download.html and see down the bottom for the plugin zip file download. You should be able to just take and unzip the contents of that zip file straight into your Eclipse plugins directory and have it immediately available to use. I donāt have a source plugin yet available to use, so youāll need to grab the javadoc from the 0.1 release to know what is going on.
Iām hoping tomorrow that Iāll be able to post about the Aviatrix3D Eclipse Plugin as well, for those of you that prefer working with a scene graph. I have it all up and running, just missing a few config requirements on my work machine to build it here. Need to update that from what I have on my laptop.
-
What do I need to do to create a new project in Eclipse that will make use of these plugins?
-
I was also wondering whether anyone has created an eclipse plugin with a view that uses these plugins?
If I can get a hand with 1 above I want to do 2, so any pointers would be appreciated.
- Shane
Seems I missed some of the points of the above discussion completely, but I can confirm that snippet 209 ( http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet209.java ) works fine for current JOGL builds and SWT 3.2M5. Maybe you can create your own plugin without too much effort based on the snippet.
The download pointed to in my previous post works as an eclipse plugin. Just drop it into your plugins directory and off you go. Iām currently working with a slightly later version, currently for some demos weāve been doing.
Apple stuff is still a long way off. I discovered that Sunās JOGL implementation talks to the windowing system interface through Cocoa. Unfortunately SWT uses Carbon and mixing the two is not possible. Iāve had to start again from scratch. Iāve got our code generating the AGL interfaces now, but havenāt had the time to go back and work on the AGL to JSR bindings implementation. I need to do about a weekās worth of work on another project and then I can jump back into getting that to work on all platforms. I do have X11 going, but something in one of Kenās recent changes are causing major flashing problems on my machines so I have to go trace down exactly what broke.
One major thing that changed recently is how the locking is performed on the underlying GLDrawable object when making a context current and releasing it. Now the GLDrawable is no longer locked between the makeCurrent()/release() calls. This allows multi-head rendering on X11 platforms in particular. I wouldnāt be surprised if this change affected the behavior of the SWT port as I have no idea how your port is doing its locking. You may want to try specifying the system property -Djogl.GLContext.noopt on the command line and seeing whether it affects the behavior of the SWT port. If it does, look around in the X11 implementation to see how the field GLContextImpl.optimizationEnabled is tested.
The eclipse plugin only works if you use the Eclipse JRE as your runtime JRE, if you want to use a separate JRE then the eclipse plugin doesnāt work.
I will have a look at the Java Snippet and see how I go from there. I am still only new to Eclipse plugin dev, but I did notice that the Views and Editors take a SWT Compositeā¦
- Shane