[b]- Fix all Mac OS X related Makefiles
Just one thing: top level makefile & cleanup?[/b]
eh?
Question: how is console output (printf) handled for “bundled” apps? (e.g. listmodes.c)
The issue isn’t bundled vs non-bundled (there’s no difference as far as the OS is concerned), but Finder-launched as opposed to command-line-launched. If the app is run from the command-line, the standard Unix thing happens. If the app is run from the Finder, standard output goes to a log file somewhere, which can be viewed in real time via the “Console” application.
What implications would it have to go “framework”? Is it just another “archiving” tool (instead of ‘ar’). Would it be possible to have both, as with the Win32 version (static + DLL)? (some people prefer static linking)
Obviously, keeping a static link option is nice. A framework is a bundle which contains (possibly multiple versions of) a dynamic library, its headers, documentation, dependent resources, &c. It’s Mac OS X’s answer to the /usr/include /usr/lib /usr/share mess that is typical of Unices. Frameworks can be included inside an application’s bundle, too, so there’s no need for a separate install in general.
Usually, yes. There is a point in being able to iconify a fullscreen window though (e.g. pop up a config window on the desktop without closing the OpenGL display, or similar). I suppose iconifying a fullscreen window is quite different from iconifying a window (see X11/Win32 sources…).
You won’t be able to iconify a full-screen window on Mac OS X (there is no window for a start). It should be possible to un-capture the display and return to the desktop mode without killing the OpenGL context, but iconification is not the way 
Of course, I can implement full-screen iconification to do precisely this, but it won’t produce an iconified window anywhere!
- Window close events are not detected
I think you misunderstood what I meant by my answer to this question. Window events (including live resize events) shouldn’t be a problem, once I figure out how to receive them… In a normal Cocoa application, that all just happens automatically. Because GLFW is handling the event loop itself, however, it’s not quite automatic any more.
Yes, I suppose so. I just left a few “FIXME”:s where the code should be inserted. I think it’s really easy.
OK, I’ll have a look for those.
There is a NSNumericPadKeyMask bit in modifierFlags, but I’m not sure if it can be used (the docs were not very clear on wether the flag is related to the keys in the keyboard message, or if it only tells if ANY of the keypad keys is held down when the keyboard message was sent).
You very seldom get more than one character per key event (though you might for foreign scripts, I guess). I’d guess that this mask can be used. I’ll try it out.
- Handle “de-shifting” on international keyboards
The hard way would be to query the current keyboard layout (if possible), and keep hardcoded de-shifting maps for every possible keyboard in the GLFW source
There’s no need to get that extreme! At the very least, we ought to be able to use the raw key code from the key event rather than the characters, and use the system’s key mapping to go from there… won’t be pretty, though 
…but the GLFW specs says it should Well, the primary intent of disabling the mouse cursor is to be able to use the mouse as a game control device (i.e. not being limited by the window/screen borders). If a game is to be runnable in windowed mode, you must be able to give the game exclusive access to the mouse - period. In the win32 version of GLFW, you will get the cursor back if you ALT-TAB out of a GLFW window with a hidden mouse cursor, so it’s not 100% stolen.
Yeah, but that doesn’t stop the fact that it’s appalling HI. If you’re in windowed mode, standard UI elements like the menu bar and window widgets are visible and should be usable. If you want to make them unusable, you need to disable them somehow, and the way to do that is full-screen mode.
If the program is using the mouse for input in a way that’s not appropriate for windowed mode, it needs to go to full-screen.
And what happens when the mouse is hidden but they can still use the window widgets, the menu bar, and activate other apps by clicking outside the window?
This is an old issue popping up again - is it possible to control the position of the mouse cursor under Mac OS X? I seem to remember that you said that there were hideous delays resulting from such attempts. Is there an alternate mouse interface that can be used (more down-n-dirty closer-to-hardware-level)?
You can’t (and shouldn’t) control the position of the mouse, for the same sorts of reasons as above. There are functions that move the mouse cursor, but they lock it down for a fixed period afterwards, during which no mouse moved events can be generated. The period is programmatically adjustable to zero, however, so that’s not so much of an issue.
The “right” way of doing this is to get mouse deltas (unconstrained by screen bounds) out of the mouse moved events. That way you have no need to move the cursor around.
On Jaguar, the mouse is accessible via the HID manager, but I don’t think mouse scaling has been applied by then, so the values you get back from that interface are probably not compatible with the actual movements of the pointer on the screen.
Check your window resources in glfwCloseWindow? (I noticed the function is kind of thin?)
I have looked at this, and I think I’m doing everything I need to, and in the right order. Obviously I’m wrong 
Curiuos question: Is there ANY difference between Cocoa and OPENSTEP/NeXTStep?
Apple has Mac-ified it a bit, and added some new functionality (sheets, drawers, OpenGL, &c) – but it’s very close to the original interface.