The Current State Of JOGL/SWT Integration

Can somebody in the know possibly summarize the current state of a comprehensive AWT-free integration of JogAmp JOGL and SWT, perhaps focusing on what's left to do as of RC10?

I know this topic has been tossed around now and then on the forums, and Sven has said that it hasn't been a priority for reasons that are easy to understand.

I ask because our group recently discarded our Eclipse 3.x prototype front-end and started over with Eclipse 4.  The experience under E4 has been a good one and things are working very well.  However, our JOGL components are still sitting on top of the SWT_AWT bridge, and that has always felt kind of like a Rube Goldberg machine that should be eliminated.

On 10/02/2012 12:41 AM, rhatcher [via jogamp] wrote: You can use NewtCanvasSWT now,
pls test w/ latest aggregated build (pre RC11)
  <http://jogamp.org/deployment/archive/master/gluegen_594-joal_362-jogl_819-jocl_683-signed/>

NewtCanvasSWT:
  <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/classes/com/jogamp/newt/swt/NewtCanvasSWT.java;hb=HEAD#l66>

JOGL's SWT GLCanvas:
  <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/com/jogamp/opengl/swt/GLCanvas.java;hb=HEAD#l74>

Due to the lifecycle of creating an SWT peer, the SWT GLCanvas can NOT deal w/
custom GLCapabilities (MSAA, ..) properly.
Hence it is strongly advised to use the NEWT SWT bridge, i.e. NewtCanvasSWT.

The NewtCanvasSWT allows you to attach a native NEWT window to your SWT Canvas,
similar to NewtCanvasAWT. Since it allows us to have full control of the resource
you can:
  - Use custom GLCapabilities
  - Native reparenting (fullscreen in/out, pull NEWT window out/in of SWT peer, ..)

However, if this seems to be a burden and SWT GLCanvas is the only thing you like,
we may discuss it's required enhancement to make it a full solution w/ custom GLCapabilities.
Of course, help & support is always welcome!

~Sven

As always, thanks for the response.

I'll give NewtCanvasSWT a try.

One additional area related to SWT integration is whether there are any changes coming for mouse and keyboard event handling.  As we know one of the most heinous features of JOGL 1.1.1a was its tight coupling to the AWT.  JogAmp JOGL has taken some nice steps to divorce OpenGL code from having to know too much about the platform on which it's sitting, and along these lines on the AWT side of the fence there are facilities to repackage AWT mouse and keyboard events into corresponding newt events (e.g. AWTKeyAdapter).  I can always get at the SWT events as an ordinary SWT event listener, but do you have any plans for a similar generalization of SWT events into newt events (SWTKeyAdapter and so forth)?  Or... maybe it's in there and I'm not seeing it, which happens more often than I would like to admit :-/.

At this point I'm just wanting to get clear on the project's intentions; it may have some bearing on how we juggle some existing code around as we continue the switchover to E4/SWT.

Hi

Yes SWTKeyAdapter doesn't yet exist but it would be a nice addition.

On 10/03/2012 01:25 AM, rhatcher [via jogamp] wrote:
> As always, thanks for the response.
>
> I'll give NewtCanvasSWT a try.
Great.
The native events being delivered by using NewtCanvasSWT
are NEWT events, since you use the native NEWT window which does
receive the native events.
So key/mouse events are covered here.

NewtCanvasAWT requires some AWT -> NEWT event dispatching due to
windowing managment etc.
NewtCanvasSWT does not need them, AFAIK.

However, ofc we like having an SWT[*]Adapter in com.jogamp.newt.event.swt.*,
similar to AWT[*]Adapter and it's AWTNewtEventFactory.

If you or others like to copy the AWT* classes
and make proper SWT* versions out of it - it would be more than welcome
for SWT users - I am sure.

I personally don't use SWT, nor clients here - and since I am currently
focusing on a few other issues, I cannot do it myself right now.
However, I will help and assist if there are any questions etc.
Ofc .. we will merge your code.

>
> At this point I'm just wanting to get clear on the project's intentions; it
> may have some bearing on how we juggle some existing code around as we
> continue the switchover to E4/SWT.

Well, intentions are to offer seamless integration of JOGL to any
windowing toolkit, native or not. Hence the SWT enhancements etc.
Only the lack of available time is able to stop us sometimes :)

Again: If you are willing to contribute, I am sure you won't be 'left alone in
the dark' :)

~Sven

OK, sounds good.  I'll give all this a try now that I have the total picture.

It would be interesting to know how many people are using JOGL with SWT.  I know of our site and Wade Walker's; that makes two :-).  I don't have any numbers on it, but it's easy to believe it's the minority usage by far.

At our site we aren't so interested in SWT per se though it does seem to be a little snappier, but we are interested in Eclipse, and SWT comes along for the ride.  It's just another toolkit anyway and no harder to program, so we just kind of accept it and move on.

We also take what you might call an unconventional approach to integrating our existing code base with Eclipse, so there are some overall integration aspects that would be of interest to others using RCP that we don't use (notably we don't do any bundling for our own classes or for GlueGen/JOGL/JOAL, but Wade has covered that in some of his tutorials).  However, any SWT-related enhancements we might make around the JOGL API proper could be of interest, so if we cook up anything that seems useful we'll definitely toss it back in your direction.

Gentlemen, thanks again for your comments.

On 10/03/2012 04:58 PM, rhatcher [via jogamp] wrote:
> OK, sounds good.  I'll give all this a try now that I have the total picture.
>
> It would be interesting to know how many people are using JOGL with SWT.  I
> know of our site and Wade Walker's; that makes two :-).  I don't have any
> numbers on it, but it's easy to believe it's the minority usage by far.
Yep, we had some legal discussion w/ Eclipse foundation a 1-2 years ago
and there were a few more approaches to use JOGL 'officially' .. but this
discussion has ceased .. since the lawyer departed from the foundation.

>
> At our site we aren't so interested in SWT per se though it does seem to be a
> little snappier, but we /are/ interested in Eclipse, and SWT comes along for
> the ride.  It's just another toolkit anyway and no harder to program, so we
> just kind of accept it and move on.
Sure.

>
> We also take what you might call an unconventional approach to integrating our
> existing code base with Eclipse, so there are some overall integration aspects
> that would be of interest to others using RCP that we don't use (notably we
> don't do any bundling for our own classes or for GlueGen/JOGL/JOAL, but Wade
> has covered that in some of his tutorials).  
Well, I prefer to let the JogAmp JARs untouched in other products as well,
since this way we can properly identify it's signature (git-sha1, .. etc).

> However, any SWT-related
> enhancements we might make around the JOGL API proper could be of interest, so
> if we cook up anything that seems useful we'll definitely toss it back in your
> direction.

Thank you, very much appreciated. It always takes real world use cases
to make a tool a good one.

>
> Gentlemen, thanks again for your comments.

Thank you!

~Sven

FYI: we're using SWT and jogl in a larger project (http://caleydo.org) as well and are currently thinking about throwing out our AWT bridge. So we'd definitely be interested in progress on these issues.

alexsb wrote

FYI: we're using SWT and jogl in a larger project (http://caleydo.org) as well and are currently thinking about throwing out our AWT bridge. So we'd definitely be interested in progress on these issues.

I'm glad to know that and your project is really nice. Would you like us to mention it in the examples of applications relying on JOGL?

Sure that would be great!

Thx,

Alex