Carbon...

[emperor]

I actually tried to build a carbon program today. It's been an experience. I'm a little unwilling to go down the objectionableC/cocoa route, since, well, I'm a C programmer at heart. But nearly all the carbon documentation assumes you'll be using the GUI Interface Builder and nib files. I don't want to do that (at least not yet), so it's an uphil struggle. Has really no-one done this? And I like emacs, so have inbuilt reluctance to go with Xcode, too.

When I learned gtk+, there were a few tutorials to follow, and that was enough to get me going.

Anyway, I managed the following short piece of code:

#include <Dialogs.h>

int main(void)
{
  DialogRef theItem;
  DialogItemIndex itemIndex;

  CreateStandardAlert(kAlertStopAlert,
                      CFSTR("Here be titles..."),
                      CFSTR("Hello, world!"),
                      NULL,
                      &theItem);

  RunStandardAlert (theItem, NULL, &itemIndex);
}

And managed to get it to build with:
gcc test.c -framework carbon -I /Developer/Headers/FlatCarbon -o test

...not much for a lot of work, is it? The button doesn't even work...

Comments

[cartesiandaemon.livejournal.com]

"a carbon program" sounds too much like "life" to me... :)

[(Anonymous)]

That's not a lot of work! It's two function calls, which is tiny for GUI code, even non-functional GUI code.

(S)

[emperor]

It took a lot of work to write those calls, and find the compiler arguments, however; it was that work to which I was referring.

[xlerb.livejournal.com]

Historically, you'd have had to write an event loop, and deal with Pascal-style strings everywhere (this was, of course, less of an issue when writing in Pascal), not to mention Handles. And the preferred way of doing a GUI was to load the layouts and menus from the application's resource fork.

However, the CFSTR's indicate that we're not in Kansas anymore. You might need to do something with CFRunLoop, or something like that.

[(Anonymous)]

Mac OS X doesn't like unbundled GUI applications (except for CFM ones, but gcc can't generate those, so that's a little irrelevant). What this means is that the executable needs to be in a directory structure that looks like this: test.app/ Contents/ MacOS/ test Normally there's more stuff in the bundle, but that's the minimum (note that the executable needs to have the same name as the test.app wrapper, (minus the .app) unless you have an Info.plist file in your bundle). Part of the problem with Carbon is that it sort of grew out of InterfaceLib and friends, which can make it hard to pick up since it sort of assumes knowledge of lots of the old toolbox, but the docs for that are horrendously out of date. Do give cocoa a go though, it's generally nice to work with.

[emperor]

Thanks for that comment (who are you, BTW? I prefer anonymous posters to give some idea of their identity); the problem with cocoa is it rather requires you to use objective-C (and again seems very nib-centric, documentation-wise).

[(Anonymous)]

You can still have you application logic/backend in C (since objc is a strict superset of C), and just use Cocoa for the glitzy UI stuff, or even mix and match Cocoa and Carbon in the same app. The nice thing about cocoa is that compared to Carbon, there is a lot of stuff (ie behaviour that has been accepted as standard by users) that you get for free, (this is coming from someone who has used Carbon for a while and the classic Mac toolbox before that). You do sort of have to get into the right mindset or you can spend a lot of time fighting Appkit without getting anywhere.

I don't believe you know me or that i know you, but I believe we both know Abi. I'm a friend of her's at Cambridge.