Hi,
I need a sophisticated GUI (you know, Buttons, Lists, Tables, Frames and so on) in my JOGL app and I’m wondering whether there exist already some library for that.
If not, wouldn’t it be possible with relatively small effort to implement the low level drawing functions of the AWT (or Eclipse’s SWT) for JOGL so that every GUI component is drawn on a JOGL GLCanvas?
Do you really need those GUI-Elements on the canvas? If not, you just put your Canvas on a Frame and use AWT like normal (and even Swing with some “workarounds” regarding heavyweight vs. lightweight components)
[quote]Do you really need those GUI-Elements on the canvas?
[/quote]
Yes, for two main reasons:
I would like to run my program in fullscreen mode. Only one frame can be put in fullscreen mode and for instance overlapping dialogs are not possible.
In addition, I would like to make use of the advantage of the depth buffer. The objects that are below a window do not need to be rendered.
I know that there is a trick with this pseudo fullscreen mode where you use an undecorated JFrame which size matches exactly the screen. But I believe this does not tell OpenGL not to render the things that are below a GUI component.
Well, there’s the Shaven Puppy GUI (Spaghetti) but that’s for LWJGL and you’d need to port it to JOGL, but it does more or less the kinds of things you want within reason.
Cas 
I’ve had a go at using Swing to write into the GL buffer with only moderate success - part of my desire here is to have transparent swing panels over my main display. You can also map a swing panel onto a 3d object which makes for some interesting UI interactions. Project Looking Glass and Xith3D have working models for this and all use a bitmap buffer to get swing to write in and then texture map (or raster map) this onto the gl buffer. Can be rather slow for big panels as that means a lot of pixel copying (and argb <-> rgba conversions) in Java rather than via native buffers.
As an alternative I’ve been thinking of late that what would be even more useful is an implementation of java.awt.Graphics for a GL display…
Oh I forget to add the real pain of using Swing is that you don’t get lightweight peers until you have a visible frame. There’s some real nasty awt hangovers there that are continually tripping me up… Shame as in principle they should not be necessary and swing should work in vacuo.
[quote]As an alternative I’ve been thinking of late that what would be even more useful is an implementation of java.awt.Graphics for a GL display…
[/quote]
This exists already You can switch it on with the VM system property -Dsun.java2d.opengl=true. But the VM crashed on my machine with this property enabled.
But anyway, thank you very much for the input. I will check Project Looking Glass and Xith3D out (I tried the latter one once, but I did not know that it has that kind of features!).
Something came to my mind after I posted my initial question. Assuming that the information of the size and the position of a frame are available, one could draw on the GLCanvas a rectangle that exactly fits the covering frame. In other words, the actual frame is not drawn on the GLCanvas, but at least OpenGL has not to render the part of the viewport image that is masked by the overlapping frame. This may not work out in fullscreen mode… What do you think?
-edit- removed awkward spelling mistake -edit-
I’m not sure to understand well your needs, but, why don’t you just use a borderlayout (or any layout) to isolate your glcanvas from your AWT/Swing components ? AWT/Swing also work on full screen mode…
Lilian
Well, what I actually want is that my GLCanvas covers the whole screen in fullscreen mode and not only partially which would be the case if I put the GLCanvas in a Borderlayout together with an adjacent panel A static panel at the side of thew canvas is not what I intend to have. Rather, a small and simple window system that is displayed in the GLCanvas would be great. Since I plan my app to have a lot of internal frames, they would cover a quite high percentage of the GLCanvas which may have some positive impact on the performance since the parts of the scene that are masked by the internal frames do not need to be rendered.
well… check if Z-ORDER meets your needs … (jdk1.5 only)
http://java.sun.com/developer/JDCTechTips/2005/tt0118.html
Lilian
Hmm, that may help. But I’m not sure yet, but thanks anyway. I have to play around a bit with it. At least it probably helps to realize my former idea which I described above (drawing a rectangle on the GLCanvas where a pop up menu masks the scene in order to save some rendering).
What we really needed was the Swing api rewriten on top of JOGL with all that awt compatibility crap taken away for good. The problem is that Swing is too much dependent on AWT and that is too much dependent on Sun proprietary apis.
[quote]What we really needed was the Swing api rewriten on top of JOGL with all that awt compatibility crap taken away for good. The problem is that Swing is too much dependent on AWT and that is too much dependent on Sun proprietary apis.
[/quote]
yeah, I totaly agree. Maybe I should take IBMs SWT (http://www.eclipse.org/swt/) under closer consideration. It’s much cleaner, smaller and neater. If I put SWT on the top of JOGL, do you think that someone except me would use it? I guess more people are familiar with AWT/Swing than SWT, although the differences are not huge… :-/
(SWT has an own OpenGL Binding, but only within SWT, like JOGL in AWT/Swing. The binding requires SWT frames and is not fullscreen supported)
Swing is the most widely used API. There are tons of good books about and its from Sun. For good or bad this counts a lot.
So if you want to make a clean Swing port to JOGL you only need to implement the basic Swing classes and ignore awt components completely.
There is a problem with this however. For some strange reason JOGL is being built upon awt (an api said to be abandoned by Sun in favor of Swing in the future) so you would not only have to rewrite Swing basic classes but you would also have to change JOGL to work with your native Swing components.
This is an interesting project. If you ever decide to go on with it (JOGL/Swing that is) count me in to help in any way i can.
I had a closer look on SWT and it appears to me as way to much work for a lonesome student like me (even though it’s not AWT/Swing) 
I think i’m going to reduce my ambition to my former idea (to prevent the rendering of parts of the scene that are masked by an UI element… see above).
JOGL is built on top of AWT because AWT supplies the native peers that the jogl library needs to get an OGL context. I’d like to see that dependency folded into JOGL itself, so that you could use JOGL in isolation without relying on AWT. OTOH I have absolutely no idea what would be involved in doing this, I presume it woulnd’t be as simple as merely having native code within the JOGL library to create a window and supply whatever platform specific handle to the JOGL lib.
D.
[quote]So if you want to make a clean Swing port to JOGL you only need to implement the basic Swing classes and ignore awt components completely.
[/quote]
Okay, I will get the Swing sources and look what I can do. I appreciate your offer to help me. I bet I’ll need it
I wrote a standalone GUI for the stuff I’m working on with all the basic GUI functionality. Looking at the swing source is quite educational, 'instanceof’s all over the place for example, with looks like a very clumsy and slow method for passing the messages through the components. The thing about coding your own GUI is that initially it seems hunky dory, you have the base prototype working and you’re quite proud of yourself, and everything is nice and elegent and designed well. THEN you start getting into making sure focus works properly, mouseover events, modal dialogs, minimizing , maximizing, toolbars, layout managers for the windows, and before you know it, your code is a mass of special cases and dodgy looking bits and bobs. Much like the swing source
Lets just say that having done it myself I can understand why Cas called his GUI library ‘spaghetti’
D.
I also wrote a GUI in JOGL and I ALSO ended up in a near death experience. This was how this very idea came up to my mind.
My hope is, when I only have to deal with some basic low-level classes then I don’t have to care about the spaghetti overhead. However, the SWT code taught me the lessen that there seems to be no clean low level since a GUI system is pretty interlocked with the underlying platform because of callbacks, mouse handles, Drag and Drop stuff and so on. I’ afraid that it will be the same for Swing. A JOGL port would have to simulate the underlying level, at least most of the parts. For example, Swing often uses AWT LayoutManagers which on their own use AWT classes…
Yes the AWT/Swing linking code is probably the most messed code Sun as ever done. However the situation is not as bad as it seams. I looked a bit into the AWT and Swing and i believe that by changing just a couple of critical classes you can get about 80% of the Swing code working on top of it.
Heres a quick-and-dirty plan about how things could be done for this hypotetical JOGL/Swing api.
Graphics2D -> Graphics2D would extend an opnegl context
AWTEvent -> would become SwingEvent
AWTError -> SwingError
GraphicsConfigTemplate
GraphicsConfiguration
GraphicsDevice
GraphicsEnvironment
Toolkit -> SwingToolkit, from it we get a NativeWindow and OGLNativeWindow and an OGLContext form the window
JComponent -> SwingComponent
JTextComponent -> SwingTextComponent
Like i said this is a quik-and-dirty analisis so a lot of stuff must be missing.
The harder part would be to modify the SwingToolkit to obtain an opengl native window and integrate it with JOGL.