[CLOSED] Internal Windowing Code Refactor

[kappa]

Problem
There's been some concerns about the windowing code recently.

LWJGL's windowing system was originally designed to be really tiny and work just in fullscreen mode. However over the years functionality has slowly been added (e.g. windowed mode, opengl es, opencl, setParent, AWTGLCanvas, resizing, etc) and the project has evolved to a point that it has outgrown its original structure.

The opengl package has become one large monolithical codebase. Its hard to hack on without spending lots of time understanding it, documentation is lacking and is rigid to add new features too. This further becomes a barrier for new contributions which should never be the case as these are extremely important for such a project.

Solution
I propose that the windowing system be seperated from the OpenGL package. This will move the Display and windowing implementation code out from org.lwjgl.opengl.* to org.lwjgl.display.*

This will require adding no new code just some refactoring of the exisiting code.

The Display class will then be located at org.lwjgl.display.Display; and any interfaces, etc, needed to implement a platform should be in that package.

Secondly, classes and code relating to each implementation should be in a sub package inside org.lwjgl.display, e.g.

org.lwjgl.display.windows.*;
org.lwjgl.display.linux.*;
org.lwjgl.display.mac.*;
etc

The above will be purely be an internal change and doesn't need to break any public API as we can keep a proxy Display class in org.lwjgl.opengl.Display until we decide to break it (e.g. LWJGL 3.0).

Advantages
This will have the following advantages:

1) It will make the codebase alot cleaner.
2) Much easier to add new platforms and bindings with minimal or no effect to other platforms.
3) Much easier to document and for users to figure out themselves.
4) The window system no longer remains coupled to any binding, so will make adding any bindings, OpenGL, Opengl ES, (Directx?) in a much cleaner way. Not forgetting the opengl package gets much cleaner too.
5) its very difficult to find people that have knowledge of Java, JNI, OpenGL, C, Various windowing systems, the generator, etc
You have to spend a lot of time understanding the structure of lwjgl to be able to make various modifications. This will allow people with skills in one area to easily contribute to the parts they are fluid with.
6) If you want to use the bindings without the provided windowing systems it'll be much easier (e.g. Prism, AWT, SWT, Android, etc).
7) The existing platforms already have multiple backends to functions (e.g. Native Display, AWTGLCanvas) and we'll need more in future, so separate packages make more sense and help make them more manageable.

Future
In future we will have to add more backends to some of the current platforms, e.g.

-Core Animation Layered backend for Mac will be needed, if we want to support running in the browser (probably even on the Desktop).
-Possibly Wayland backend for linux if theres a switch from X11.
-Maybe even one for Prism depending on the direction it takes.

We should also consider separating any dependencies on external frameworks that the Display has picked up.

So we could have subpackages such as

org.lwjgl.display.awt.*;
org.lwjgl.display.prism.*;
org.lwjgl.display.swt.*;
etc.

This will allow stuff like native compilation to work much better (Excelsior Jet, GCJ, etc) as the bits we don't need can be excluded at compile time (ANT build files).

Any thoughts on the above?

[Fool Running]

This sounds like a wonderful idea to me. I'm all for code clean-up and better organization.

[kappa]

Closing this RFE, the current plan is not to break/change the LWJGL 2.0 API and focus mainly on just bug fixes for it (therefore no multiple Display support for LWJGL 2.0).

Having said that work is already under way on LWJGL 3.0 which has a clean rewrite of the API and includes support for multiple windows (using OO).