GLFW might be nice and small, but I require MAC support so it’s useless
for me, no matter how small it is.
I would also like to see a Mac port of GLFW, but until someone gives me a Mac or decides to do the port himself, it won’t happen (sadly). I think a MacOS X port shuldn’t be hard to do (a guy did a rough draft with the basics and could compile & run most GLFW demos). A nice thing for instance is that MacOS X has pthread, so you can basically rip the X11/Unix code for the threading part of GLFW
By the way, if none of the listed windowing toolkits will ever be able to
replace GLUT, why bother.
With “replace”, I mean all aspects of GLUT, including legacy code compability etc (which is impossible without doing a GLUT API implementation - just as freeglut does). Most toolkits are able to replace (and surpass) GLUT for certain/most tasks, but that requires that the programmers start from scratch, and do not rely on GLUT (for instance, you can’t use GLUI with any toolkit other than GLUT).
Why not work on freeglut?
Honestly, if I knew about freeglut before I started coding GLFW, GLFW would probably not exist today. On the other hand, I know many people who are very happy that GLFW does exist.
What’s so bad about the GLUT API that everyone feels the need to come up with their own. If the GLUT code turns your stomach, fine, replace it. But is the API all that bad? I don’t think so. In fact, it seems pretty darn similar to the APIs in all these newer (but somewhat lacking) toolkits. All of them could have been done using the GLUT API with a few modern tweaks that mirror the functionality of the GLUT patches listed on the toolkit FAQ.
I think that in order to bring GLUT up to speed, you would have to either break compability or introduce much redundant functionality (have both old and new versions of the same basic functionality), which, in the end, is not much different from a completely new API.
The toolkits may look the same, but it’s the fine points that make a difference. I am thinking about things like:
- Keyboard (one or two degrees of finer key selectivity wouldn’t hurt, and for instance, how do you know if the key “4” is pressed, regardless of modifiers?)
- Joystick (1 stick, 3 axes, and no Linux support isn’t really cutting it)
- Timer (10-50 ms resolution, not enough for most programs, especially games)
You can’t bring these modifications to GLUT easily without messing up or bloating the API. Well, prove me wrong, but I don’t think GLUT would be much easier to use, meaning that an alternative, clean cut, toolkit may be worth considering.