LWJGL and foreign contexts and the feature freeze

[elias]

Hi,

Spinning off the other thread about windowing support in LWJGL, I'd like to discuss the actual implementation. My idea is this:

1. Create a plugin-like architecture where a plugin involves the context _and_ input. An input plugins has to created for a context if you want to access it in the LWJGL style input*.poll()/read() manner and not in a context specific manner (e.g. awt input events).
2. There will be two default LWJGL context/input plugins, the fullscreen one and the simple window one.
3. Plugins will be created for "foreign" contexts and their corresponding input methods - one for the "JOGL context/awt events" combo, one for SWT/whatever input method they use, etc.

However, I'm in a bit of a dilemma here, because doing so will require subtle API changes, and that interferes with our feature freeze plans for 0.9 at least for a month or so. The Window will only do the very basic context stuff (update()), and Mouse/Keyboard will only do read()/poll() and friends. All other functionality will have to exist in the plugin only, so

Mouse.setNativeCursor(...)

will have to become something like:

((LWJGLMousePlugin)Mouse.getPlugin()).setNativeCursor(...)

similiar story with

bool is_close_requested = Window.isCloseRequested()

becomes

bool is_close_requested = ((LWJGLWindowContextPlugin)Window.getPlugin()).isCloseRequested()

What do you think? The plugin work of some kind will have to be done to support the mac anyway (at least I haven't figured out how to implement a decent LWJGL port on mac in any other way), so it must be implemented at some time.

- elias

[blah]

Why the casts?

Isn't Mouse.getPlugin() always going to return an instanceof LWJGLMousePlugin?

(bear in mind I've done no LWJGL programming yet, so this may be a very stupid question )

[elias]

Nah, the abstract bare class will be MousePlugin (implementing at least the core functionality like read and poll()), where LWJGLMousePlugin is a specific class that additionally implements native cursors (another plugin will be SWTMousePlugin which may also have setNativeCursor). Because native cursors cannot be guaranteed, it can't be in Mouse itself.

- elias

[Matzon]

hmm, I don't get it!

Except for the LWJGL Mouse, no other mice implementations for java use polling! And why would I use a SWTMouse thingy when I just use the SWT Mouse events...

As far as I can tell, there's nothing to be made pluggable - we just need to expose what is required to make "stuff" work with LWJGL - handles, interfaces and whatever.

I don't think we gain anything by making a pluggable architecture, except all sorts of annoyances.

Now I might have misunderstood something :roll:, and if so - please enlighten me.

[elias]

You're right, maybe we can drop the getPlugin() method of Window and Mouse, because you can use the extra features in the right places (e.g. on an AWT Frame). We still need a place to bong the LWJGL features of input in (like setNativeCursor).

Some way of pluggin in is needed however, because I don't want to use SWT/AWT events. Why? because LWJGL code use the Mouse.poll()/read() interface, and you need to be able to use that interface even when an AWT context is current.

- elias

[fbi]

I'm probably missing the point: Why do you want to use LWJGL mouse events when you've got a current AWT/SWT context?
I'll clarify my point with an example...I hope to be clear enough  
I would use (and I use it indeed) SWT or AWT to create something like an editor for a game, what is usually called a game tool.
In this specific case:
1) I will run my game in the SWT/AWT Canvas for a real-time preview while other widgets are used to manage properties, manipulate objects etc.
   OR
2) I'll have the possibility of running the game fullscreen to see what really happens.

In case 1) I'll use AWT/SWT events&classes, in case 2) just LWJGL ones (for what it concerns mouse and keyboard of course).

Even if I would need to create a strategic game in a common window I would to use in a straightforward fashion just AWT or SWT.
If I must implement an FPS I know I have to run fullscreen.
So what did I miss?!?  :?

[elias]

You didn't miss anything really. It's just that somebody (including myself) would like not having to switch event model (from LWJGL to swt awt) just because they use another form of context. With a SWT/AWT/whatever adapter for input, only the initialization code will know about what kind of context you're creating.

- elias