The primary goal of "backend decoupling" is to allow NeL3D and input/event handling to be embedded into other applications. A usage scenario are tools for the content creators, i.e. a "world editor".
There are multiple aspects, which need to be taken care of:
- providing NeL an OpenGL context (I have no idea how this works with D3D). Later on we may think about using multiple contexts at the same time for multiscreen applications.
- providing NeL event messages, i.e. X11 events. It should be possible to have multiple event sources in use at the same time.
As it stands, the current interface of NeL3D can't be changed/modified (our current policy to try to stay as compatible as possible to the last official NeL "release"/commit), so this "backend decoupling" has to happen below that interface. However, we can provide additional functionality, maybe in such a way that the old interface is fully based on the new functions.
This new interface may contain something like this:
- An "implementor", which implements things like creating an OpenGL context, running an X11 event poll routine and so on. This is NeL's own support for these things, to run it "standalone".
- A "connector" to connect NeL to an already existing OpenGL context, event provider etc. This offers application writers to connect NeL into an already existing framework, without resorting to weird hacks or even modifications in NeL (that can result in quite some maintenance headache).
OpenGL
The implementor covers everything from fullscreen/windowed mode setting, window title and icon changes and so on, up to and including creating an OpenGL context (aka accessing GLX visual). Most of this is not yet implemented properly for the Unix/X11 case; however, most of these functions don't need a change, either (read: there exists an interface for it already).
The connector is the missing part, because certain setup functions combine both implementor and connector in one. This needs to be split in the way mentioned above, i.e. having a function to create an OpenGL context and having a function to setup NeL within an existing OpenGL context. The existing all-in-one solution will be replaced by calling these two new methods.
The implementor will exists more or less outside of the OpenGL "driver", while the connector is an inherent part of it.
X11-Events
The X11 event handling is a bit more complicated than the OpenGL context setup, because it goes both ways in terms of "decoupling". Firstly, we will need an internal "plugin" mechanism to add X11 event handlers to the standard one. For example, the XRandR handler will need something like that to get informed about changes, which in turn can be used to update screen information or invalidate it (which is what the xrandr program does). Also, it may allow to handle additional input devices running over the X11 event queue. Secondly, NeL itself should be made in a way that you can "plug" it into an existing X11 event handling system, disabling the default X11 poll routine included in the NeL package.
The implementor just receives the native event messages (either as callback, polling loop or whatever else the underlying system offers for this), and hands these over to the connector.
In return, the connector does the actual event processing, means it translates native event messages into NeL events. It also offers a plugging mechanism to add more event listeners/handlers, i.e. the above mentioned XRandR event handler.
Also, there could be multiple implementors and connectors, all accessing different event sources (assuming that not all events go through X11, i.e. joysticks, gamepads and whatever else comes to mind here, unless they are all covered by some generic HID driver?). This will require some deeper look at the NeL event system, because we can run into some cool threading problems and may require a way to synchronize the different event sources into one NeL event stream.
That also requires a loosely coupling at best with the existing OpenGL "driver", because the event code has not much to do with OpenGL as such, and is secondly fully system dependent (both implementor and connector).
Cocoa
With a properly done "decoupling", it shouldn't be much of a problem to adapt NeL to other systems like MacOSX, without using the X interfacing libraries.