Carbon Window with GL-Context w/o xcode

[__anti]

Hi,

I recently started porting one of our games to darwin.

The whole toolchain is working,
but the window-code is giving me headaches :(

All I need is a simple sample, that:
- Opens a Window (using Carbon, no Cocao!)
- Adds a GL-Context to it
- Spins a triangle in it
- Builds via "make" from the command line

I tried a few times,
but all my windows seem to be "dead" after being opened.

ps:
There are reasons for all those restrictions!

[OneSadCookie]

there is no reason for the "no cocoa" one :p

you'll need to make an application bundle in order for your window to be activatable. I suggest using Xcode to build a simple application and poking around inside the result to see what the structure is, but Apple has documentation, too.

[__anti]

I guess "no C++" is a good reason for "no cocoa", but that decision has already been made and I could find a reason why it should be possible to open a window with carbon only.

Why do I need a bundle ?
My applications start fine without.

Xcode is no option. We do automated nightlies from CVS, so a GUI is only overhead.

Apple has docs, but they are pretty chaotic.

[dair]

There are plenty of reasons not to use Cocoa. In your case, the best starting point is probably something like GLCarbonAGLWindow (http://developer.apple.com/samplecode/GLCarbonAGLWindow/GLCarbonAGLWindow.html) (although, as with most Apple sample code, it's more complex than it needs to be).

To create your window, use CreateWindowFromNib (IBCarbonRuntime.h) or CreateNewWindow (MacWindows.h): probably CreateNewWindow, if your GUI all runs within a single window and you don't need normal menus/windows/controls.

To set up GL from Carbon, use the "AGL" interfaces (agl.h). These let you hook up your GL context to your WindowRef's CGrafPtr (via GetWindowPort), at which point everything is as per normal GL. Your sequence will be aglChoosePixelFormat, aglCreateContext, aglSetDrawable, and aglSetCurrentContext.

If you need to do automated builds, you can use xcodebuild to do this for Xcode projects (man xcodebuild for flags). You could use make directly if you like, however Xcode takes care of linking to the appropriate libraries for your compiler/etc and creating an application bundle (having an Xcode project also gives you a somewhat useable source-level debugger on top of gdb).

You will need to package your app as a bundle in order to appear as a double-clickable application to the user. This is nothing more than a special directory structure and a couple of XML files, but ensures you can connect to the window server/you show up in the dock when launched/etc.

The second-easiest way to set one up would be to produce a build in Xcode and then clone that structure into your build process (the easiest way would be to use xcodebuild, and have Xcode create it for you: note that the GUI part of Xcode does not need to be running for xcodebuild to work).

[__anti]

OK,
I made a bundle (simple, via the Makefile).

Now I get a foreground window.
Step 1 solved.

What I don't get:
When I...
1) ... start My.app via finder it runs fine.
2) ... start My.app/Contents/MacOS/My via the console I get the inactive background window.
3) ... start XcodeMade.app via finder it runs fine.
4) ... start XcodeMade.app/Contents/MacOS/XcodeMade via the console it runs fine.

Where is the difference between 2 and 4 ?
The source is exactly the same.
Both don't touch NIBs or Resources.

This is really confusing.
And I thought programming for MacOS would be easier ;)

[OneSadCookie]

Are your Info.plist entries correct? Is your PkgInfo file correct? I'd have thought that problems with one of those two would be the most likely problem.

[__anti]

Info.plist seems to be right.
It is running perfectly from finder.
PkgInfo doesn't exist.

What's the best way to create it ?
(without Xcode!)

My GL-Context seems to be set up correctly now.
I still have to figure out where (in which event) to draw ... and how to do it.
Apart from that it's almost ported.

[TomorrowPlusX]

I understand that you're working to some arbitrary requirement, but I don't see why you can't use XCode + Interface Builder to build a skeleton which works, and then extract the code and bundle resources such that it can be automatable via a Makefile. Once you have that, you can throw XCode & IB away. No-one's the wiser.

[__anti]

I did excatly that.
Now I got a working programm/.app.
But it only works from finder.
It would be really nice if I could also start it from the console.

I can't find the difference to the Xcode App.
Must be some unknown linker switch or something.

[OneSadCookie]

echo 'APPL????' > PkgInfo

[__anti]

Thanks!

That fixed it.

Is there any good documentation anywhere on how executables get loaded ?
Cause this wasn't to obvious...

[OneSadCookie]

yes, you'll find bundle structure documentation on developer.apple.com or in /Developer/ADC\ Reference\ Library