Should be doable. We can probably even copy the contents of the OpenGL view into the dummy window, so the miniaturized window looks right.
That would be 100% neet!
NSWindow deals with turning mouse events into window close (&c) events, which it then sends to its delegate (and, I think, to the notification center).
I didn’t understand much of that (but then again, I have never coded Cocoa). You’re the master, I know you’ll fix it
It talks about the Core OpenGL API that does some of functions of GLFW. They also give an example on how to set fullscreen, constrain the mouse, and test, change resolution and refresh rate. The link mentions Carbon but it also describes the Cocoa API.
Originally posted by Drew_in_Japan: Hey, has anyone checked out this documentation yet. [snip]
I’m pretty sure our Cookie has it figured out
Just to let you all know, I’m currently working on a new source code layout that should make it easier to integrate support for new platforms while reusing as much code as possible (thanks to Keith for the idea).
I’ve had the pleasure (?!) of dealing with some Carbon code over this Christmas break, and it strikes me that Carbon may well be a better match for GLFW than Cocoa. In particular, it deals directly with red, green, blue and alpha bits (rather than with the total number of bits); the event model is slightly better suited to GLFW’s architecture, and since GLFW was going to have to dip into Carbon anyway for certain functionality, it seems that it might be cleaner to go this route.
Note that this will not give backward compatibility to OS 9, there are still certain things (full-screen, joysticks, mouse capture and movement, &c) which would (have to) be done in an X-only manner – but it might well simplify the task of anyone wanting to back-port.
Anyone feel strongly one way or another?
Marcus, is it worthwhile my waiting for the restructuring before I continue the port? (ie is the restructure going to be usable in the relatively short term?)
I do not want to be the judge in the Cocoa/Carbon issue, I think you are a much better judge of that. As long as it’s future compatible, it’s fine with me. Backward compability is not as important as future compability. If one or the other gets disqualified because it can’t implement GLFW as well as the other, that should be a helping hand in the decision making
I’m working on the code “morphing” right now, and I don’t think it will be VERY long before it works (days, not weeks, I hope). I don’t have many hours per day (actually, 30 min in average or so) for GLFW development, but I still think I can make it pretty soon. I have a preliminary frame set up, and I’m half way through the windows code, so it shouldn’t be long before I can send you something that at least works on one platform (that’s all you need for Mac OS X).
I’m quite happy with the new code layout (I’m not 100% satisfied though, but it’s definitaly a step in the right direction). Now I can add/change many things without even having to touch the platform specific code
