If you want to have an OSX port, I may be able to assist you in this realm.
That would be more than welcome!! 
I think I have some MacOS X base GLFW code somewhere on my disk (probably GLFW 1.x) from a previous attempt. I think the X11 source is a much better starting point though (the win32 code is just a pure mess - not as stright forward as the X11 code). Please mail me (I think my address is in my profile, otherwise on the GLFW page).
Hello again!
I have prepared a starting point for the MacOS X conversion. If you (or anyone else) wants to take a shot at it, you can download it from here: files , select GLFW_MacOSX_port.zip (hint: also download the v2.3.2 source code distro, which contains X11/Win32 source + GLFW docs)
Hoping for some response 
[This message has been edited by marcus256 (edited 12-05-2002).]
Just to add some impetus: if you guys can get an OS X port working, it will make my job easier in using GLFW for my little sim project.
I’ve checked all of the options for a simple, clean, C toolkit that is easy to compile using gcc (mingw for win32) and native OS X Carbon (for when I get my gorgeous mac :-), and GLFW is it… with a Mac port!
The good GLFW docs and current development make the decision easier, Marcus.
As an unsophisticated >user< I can’t help in the system intricacies, but I can give you feedback and other help with examples, docs (the stuggles of a newbie…).
Thanks,
Paul
[This message has been edited by paulfjeld (edited 12-05-2002).]
OK, I will see what I can do… I have a lot of other projects going ATM, but I would like to see some form of base-system support for OSX… Lemme get your info, mebbe discuss what’s up via ICQ or something… My ICQ is 27812673.
Hello all,
Any help is of course welcome. Regarding actual coding & porting work, we need to have some sort of discussion regarding license, authorship, packaging etc.
I would also like some discussion about what Mac interface to use (Cocoa?), and what OS versions to support (e.g. pthread_kill, used by glfwDestroyThread, is only supported in MacOS X 10.2 +).
I agree that a first working prototype is more important than a completely bug-fixed full-featured implementation.
I also think that it is very important that we focus on a clean implementation from the start, not a hack, since:
A) Many people will be interested in using this
B) The source code should be maintainable for others than the author(s)
…and believe me, turning a hack into a clean product is not easy (GLFW 1.0 really was a hack, and after a dozen of releases later, there are still remains of that sloppy code).
I always welcome feedback on the documentation. It’s not always easy for me to spot what is lacking or incomprehensive.
Originally posted by marcus256:
I would also like some discussion about what Mac interface to use (Cocoa?), and what OS versions to support (e.g. pthread_kill, used by glfwDestroyThread, is only supported in MacOS X 10.2 +).
I wonder if a Carbon port isn’t best. It seems, from my >scanning< of the Apple coding docs, that it is trivial to use Carbon in Cocoa apps, including adding all the Aqua widgets. From your first cut posting, it looks like, in the .m files, there are just a few NS* wrappers around your C code. Also, why not bypass all the old Mac stuff and get into the Jaguar game? That’s what Steve wants (I mean Mister Jobs…).
Of course, you need to take those comments with this salt grain: I don’t want to learn an entirely new language (and Obj-C is entirely different in syntax and philosophy despite people saying it is easy and fun), and I’ll be using Jaguar only. Never liked the Mac until they got a >serious< and good OS.
Besides, don’t you want all your excellent examples to successfully compile in any environment with the flick of a simple #ifdef switch? (Okay. I’m lazy.)
Paul
Hello again,
First, the Obj-C code wasn’t written by me, I don’t know if Obj-C is necessary or not, but I’d like to avoid it (please read the readme.txt file in the zip-file).
There are a few questions that need to be answered, but the most important one is:
Which interface(s) to use?
The following requirements should be met:
- It should support all GLFW functionality (e.g. the very low-level keyboard interface, the threading support etc) - see the GLFW docs
- Performance (e.g. using MacOS 9 interfaces is probably slow - ?)
- Only MacOS X has to be supported - does anyone disagree?
- Support C ! You should not have to use Obj-C/C++/other to code GLFW. If possible, code GLFW in C too.
- No changes, #ifdefs etc in GLFW apps (portability! portability!)
- A future version of GLFW may get some GUI functions (such as a video mode dialogue) - the MacOS X interface should support that too in a simple way (C language only - no “visual forms” etc)
Ok, my questions as a MacOS X newbie:
- Can you code Cocoa from standard C? (the Apple site only mentions Obj-C)
- What compilers support MacOS X? Can we support them all?
- Is it simple to support both MacOS 9 & MacOS X? Perhaps with #ifdef’s?
- Is this discussion better held in the Macintosh forum?
…I may be missing some points. If so, correct me.
[This message has been edited by marcus256 (edited 12-08-2002).]
First, the Obj-C code wasn’t written by me, I don’t know if Obj-C is necessary or not, but I’d like to avoid it (please read the readme.txt file in the zip-file).
Right! Good readme. Your earlier Cocoa comment wouldn’t have scared me had I read it right away.
2) What compilers support MacOS X? Can we support them all?
Apple provided IDE (free) and CodeWarrior 8.0 (expensive). (other Java, Basic as well). As long as you support the ProjectBuilder/App Builder requirements, I think Codewarrior can handle it >and< give you Classic with simple switch-throwing.
4) Is this discussion better held in the Macintosh forum?
There are definitely some sharp cookies over there (unlike this sad one.)
Paul
[This message has been edited by paulfjeld (edited 12-08-2002).]
Small update: Henry Maddock’s FTGL is a complete package for Linux/Win32/OS 9/OS X:
http://homepages.paradise.net.nz/henryj/code/index.html#FTGL
His various #ifdef calls and make/project files makes it seem that the Mac port can be done fairly elegantly. (GLFW makefiles are nicer and for more compilers.)
Paul
I got your email Marcus, and I wanted to note that I haven’t seen any way of writing a program where libc wasn’t dynamically called. Every program I have written that was moved to a system that didn’t have the “expected” libc version always puked.
As for doing an OS check of OSX versions… hmmm… I’ll have to look into that. Im not very familiar with OSX, but I do have it and have done some (not much) development on it.
Paul,
Thanks for the tip. However, FTGL is not quite as system dependent as GLFW (it only has some ifdefs for font paths and include files). Also, the Mac project files are complete mysteries to me: they’re binary (I prefer makefiles because they’re so universal and can be read by anyone).
142-7,
Based on what you say, I think we can simply assume/require 10.2, and hope that it is possible to detect/bail out nicely on earlier OS versions (compile and/or run time).
Ok, I have now started a new thread in the Mac forum …
None of the programming work that I have done on OSX used those binary project files, I used Makefiles. I am gonna have to dig up more info on OSX programming, for one, I know that all of the projects that I have done using Makefiles have been command line only, even ones involving 3d engines and so forth. I need to find out if it is possible to make “double clickable” OSX programs from a Makefile.
Originally posted by paulfjeld:
There are definitely some sharp cookies over there (unlike this sad one.)
Hey!
Please, Paul, join the discussion on the Mac forum that Marcus has linked to. I’d be interested to know how useful the current state of the Mac port is, and which bits I should be focusing my energy on.
(Incidentally, Henry Maddocks of FTGL fame hangs out on this forum, and I work with him at my day job )