Add a new window manager

[iamscottmoyers]

We don't want to use GLUT, but it would be nice to be able to switch between different window managers. So see if we can add another window manager whilst also keeping support for GLUT.

[17twenty]

I pushed edda25291c which adds conditional compilation, you can make USE_GTK=1 and it will use GtkGLExt instead of GLUT.

Is that OK? If yeah I can start looking at the GLUT functions that need replacing or do you want to do it a different way?

[iamscottmoyers]

Looks ok. The #ifs around the GLU functions will probably disappear. It seems that the functions with a glu prefix are part of the OpenGL utility library which is not part of OpenGLES. So they're not actually anything to do with GLUT, they can be replaced with some GLES calls.

[17twenty]

OK that's cool then. If you can test you can compile and get a black context on your Mac that'd be cool (assuming your gtk port works!).

[davestevens]

i tried to compile it earlier and couldn't get a working gtk library working on my mac. in terms of window management what do we need, will keystrokes/mouse input be on the window manager or be captured by gles?

[17twenty]

GLES has no concept of input devices. We'd need to have an input abstraction layer of events and then we would pass through events from a WM/toolkit/Glut/HW device.

Scott would be the guy to get it working on Mac as he had it already. On Jul 9, 2012 9:31 PM, "petercrumb" < reply@reply.github.com> wrote:

i tried to compile it earlier and couldn't get a working gtk library working on my mac. in terms of window management what do we need, will keystrokes/mouse input be on the window manager or be captured by gles?

---

Reply to this email directly or view it on GitHub:

https://github.com/iamscottmoyers/cambhaxx-gles/issues/2#issuecomment-6858672

[davestevens]

well the glut stuff worked fine on mine, so i'm not sure if its default on mac? just thinking about how easy it would be to package for different systems. thats fine about the different devices then, i think we need to start by defining what sort of inputs we think we would be wanting first then we can find out if there are any show stoppers in terms of libraries which won't work.

[17twenty]

Sorry - I meant that Scott could help getting the Gtk development libs/tools setup. Glut is fine by default but we want to move away from that to stay with the OpenGLES theme.

Speaking of which - Is there a good way we can create a fake include file for OpenGLES that just exports definitions for OpenGL functions that are only available in OpenGLES. I imagine we could do it if we ensure that warnings for implicit declaration are treated as errors. Does that make sense?

[iamscottmoyers]

I'm on holiday next week so I can get gtk working then. It should work on Mac + Linux. I've got 2 applications that use gtk+gl now and they needed no porting between the 2 OS's.

We could probably use the real GLES header file http://www.khronos.org/registry/gles/. Our include path could point to the GLES header file and the library path point to GL.

[17twenty]

gl2.h depends on GLES2/gl2platform.h, we have a gl2platform.h but that in turn depends on KHR/khrplatform.h. Do you propose we use just hack it up to make it work or do you know where we can get the Kronos platform header file?

[iamscottmoyers]

Here's a quote from the fucking link I gave you: "The latest OpenGL ES 2.0 headers now depend on the shared KHR/khrplatform.h header located in the EGL Registry"

Using these headers is a bit hacky but will prevent us from using unsupported functions. I think getting the mali developer emulator working would be the best way. That supports EGL so we can use the khronos windowing system toooo. Wow all these lovely window choices.

The malideveloper SDK is in C++ so if we want to switch to C++ it would be good to do it then.

[17twenty]

Can we close this issue? We have gtk as the alt. The opengles enforcement should be another issue IMO

[iamscottmoyers]

Yeah sure.