and?
Can you be a bit more precise?
All i see in the event listening is all you’ll need to handle anyway, isn’t it?
The more interfaces and classes referenced by each API the more interdependent the two APIs become. I’m trying to get a simple no-brain one-class interface between them working so the chances of anything misbehaving or changing are minimal.
Cas 
Indeed. All that’s needed here is an adaptor class. One that can take one rendering interface and munge it for use by another. Cas, the one thing that I’m somewhat curious about though - does this mean that you will be able to render in an AWT/Swing component?
Yes, and this is my prime motivator. Or Swing components rendered over GL drawn components. I’d really like to see it working.
Cas
An Adaptor is the only way to go so that NO API on the extremities are tied to one an other, and always from higher level to lower level.
It may not be part of the gaming initiative, but maybe it would be time to start an adaptor scheme that every low level API creators should take care to be easy to be linked from. That way, everyone using that adaptor would be free to use any underlying rendering API.
Would be cleaner, imho…
That’s pretty much what I’m trying to do, without actually producing an implementation, just mandating the functionality of an interface and giving it a name.
Cas
Cas, start a different thread on adaptor based rendering so we can poll the audience and see what they think. What we’re talking about here is an easy change and will make it possible for someone to select a renderer from either JOGL, LWJGL, or some bastard jogl-lwjgl two-headed hybrid In either event, the code is done in my tree. I can’t check it in until I get some feedback of the other owners though as it may have some unknown impact - though its just an interface and all I’ve done is set up GLCanvas to implement that interface.
good going, this should really help with the LWJGL port of Xith3d!
Will.