Version 0.9

[fbi]

Hi guys, I know it might eventually be difficult to predict, but when do you plan to put version 0.9 out?
So that I might (eventually) also try to add the Linux versione of the SWT binding in time?  :wink:
Thank you a lot in advance!

[princec]

"Easter".

About the SWT binding: I'm considering writing an AWT binding as well. It would be sensible if your SWTGLCanvas and my AWTGLCanvas both implemented a common interface GLCanvas which had the context management functions declared in it. (The reason being that AWT and SWT both ultimately actually use OpenGL in the same way - it doesn't matter when you call a GL method so long as the context is current for the current thread).

How about, for starters:

public interface GLCanvas {
public void makeContextCurrent();
public Object getContext();
public int getWidth();
public int getHeight();
}

Any more ideas?

Cas

[fbi]

Thank you Cas for the Easter info  :wink:
I definitely agree about the Canvas...it would be great having the possibility of choosing AWT/SWT!  
I thought about two different possibilities...even if they're not that different  all in all


[1]
public abstract class GLCanvas
{
     private int glHandle;
     private int hDC;

     public void makeContextCurrent();
     public Object getContext();
     public int getWidth();
     public int getHeight();
     public void paint();
}


[2]
public interface GLCanvas
{
  public void makeContextCurrent();
  public Object getContext();
  public int getWidth();
  public int getHeight();
  public void paint();
}

The reason for using [1] is that, all in all, both SWT and AWT need to use (in their own way) the current GL context and the Window-system context.
I will also need  a couple of private declarations more and a dispose() method for the SWTGLCanvas...that's all.
In my opinion picking [1] or [2] is a pure matter of taste  

[princec]

I definitely prefer the interface method. Basically because an AWT GLCanvas must extend Component. An SWT one presumably extends whatever it is that SWT uses at the base class.

Cas

[fbi]

Ok...fine.
In my case I have to extend a SWT Canvas.
Let's go for it...the interface scheme I mean  :wink:

[princec]

I might see what we can do to org.lwjgl.Window to get it to implement that interface in some way as well. (Probably an inner class will implement it). My goal is to make it so that LWJGL interoperates nicely with AWT and SWT or lives on its own, as before, without anyone having to do anything remotely difficult.

I'll convince those Xith boys yet that they should be implementing Xith in LWJGL The buffer code and new security features going into 0.9 should just about clinch it.

Cas

[fbi]

Currently my SWT/LWJGL build works in a pacific way  :lol:
If you istantiate a SWT Canvas then the LWJGL rendering is directed there...if that's not the case then LWJGL really doesn't care  
I think that should be the way...as simple as possible.