Hi,
[quote]Who are Yuri and David ? ? ?
[/quote]
OK, say, my name is Yuri 
. If you’d like to see my profile - you are welcome to http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=announcements;action=display;num=1074215610;start=15#15 thread, but this is off-topic here.
Now as of SWT port for JOGL and Xith3D.
For me, SWT is nothing different that AWT and Swing - this is just another GUI library with nice features, but also with its own open topics.
Xith3D is first of all scenegraph-based rendering engine. Of course, there is a need, a very big need, to add support for event handling and behavior processing.
Time ago I was implementing support for OpenGL-based picking in Xith3D, and came to the issues of handling UI events associated with 3D rendering components.
As of now, UI event processing (except of UIWindow) is completely up to the application that uses Xith3D. CanvasPeer has a method for obtaining a Component that acts as 3D rendering component, and then application can attach any event handlers to it. I see this approach very reasonable, because of it allows to keep Xith3D core aware of any of UI-library-specific event processing issues (again, except of UIWindow).
The visible problem with SWT integration is that [maybe - I don’t know] SWT version of GLCanvas extends something other than java.awt.Component, so it may make it incompatible with current CanvasPeer API. This can be easily changed by adding, say,
public Object get3DRenderingUIComponent()
that will return something other than Component.
I even don’t see any reason of changing Canvas- and Render Peer in order to support SWT, just because of this may be a part of JOGL - it already contains factory method of creating GLCanvas:
GLDrawableFactory.getFactory().createGLCanvas(gc);
So we can keep the same peer classes for all of the JOGL-based UI components.
As of event handling in general, I see the following structure of application that uses Xith3D:
-
Application creates CanvasPeerImpl of interest, maybe providing some peer-implementation flags indicating details of canvas creation.
-
Application attaches event handlers to created CanvasPeerImpl in implementation-specific way.
-
Application attaches View to Canvas and runs rendering loop (either built-in or custom).
-
Upon UI events received, application modifies Xith3D scenegraph accordingly, which results in visible dynamic changes.
If we speat about JInput and other related things, then I would say that there should be separate scenegraph modification subsystem, that may/will run in rendering thread context and will react to different external events. This will bring us to known concept of Java3d Behaviors, which is currently not implemented in Xith3D [OK, I have partially implemented some parts of it for my projects, but this is not 100% compatible and has only part of core Java3D behaviors implemented (interpolator and base mouse behaviors)].
Comparing to Java3D, Xith3D can be really flexible on supported behavior types, so we can make set of behaviors that react on different types of input - say. we can have set of AWT-based mouse behaviors, as well as SWT-based, as well as more generic JInput-based.
But, at the end, I see this as a separate Xith3D subsystem, Scenegraph Manipulation API, so we can still keep Scenegraph Rendering API independent on the underlying UI library, platform and rendering subsystem.
I would prefer to break Xith3D project to subsystems, so it will not become a non-maintenable monster, but a set of optional subcomponents. We see excellent example of this with XML serialization - this is a part of xith-tk project, and interoperates with Xith3D core very well. If we need to make some changes in Xith3D core in order to suppoer SWT, there is absolutely no problems.
Yuri
P.S. This is not a “final decision of Xith3D team”, but my personal opinion [that I see very reasonable], so I am open for discussion anyway.
