Mac Forum / Programming / Mac Programming / August 2007

Neither view is correct. Cocoa and Carbon are on an equal footing, but
they aren't totally independent either.

The low level framework is CoreGraphics, also known as Quartz, which
includes a bunch of private stuff like the core window objects which both
Cocoa and Carbon windows are implemented on top of.

Many things are implemented independently. For example, the control
hierarchies are done completely separately, which often causes odd
inconsisitencies in the behavior of what should be identical Carbon and
Cocoa controls.

Many things are implemented in terms of the other framework. As an
example, Cocoa menus are implemented on top of Carbon menus. And Carbon
font and color panels use the Cocoa ones.

The end result is that both frameworks are capable of doing most things
but there are certain things which only one can do, and you can't say
which framework will be able to do it without actually researching it.

The good news is that the frameworks mix just fine in most cases,
especially if you do all of your GUI in only one of them. I believe, and I
think many other will agree, that the most productive environment is to
write your GUI in Cocoa and use Cocoa liberally otherwise, but to use
Carbon whenever it's necessary or convenient to get things done inside the
app.

No.

Not totally separate. What you read "somewhere" about portions of Cocoa
being implemented in Carbon is accurate. But I wouldn't say that it's a
lot and certainly not most, and there are some things that today simply
are not cost-effective (and sometimes not realistically possible) to do
in Carbon.

Not necessarily. The libraries themselves can certainly be exposing only
Objective-C interfaces with no public procedural API for a given task.

Hmmm... Having been a Mac programmer since 1988 and a Windows programmer
since 1993 I suggest that what's probably changed most is you. If you're
looking at Carbon, there's really not much fundamentally different from
what you might have seen at any time in the 1990s. If anything, some
things have gotten more convoluted and opaque since then.

If you're a capable C programmer - and I expect you are - and don't let
yourself get defensive/hostile about the "weird" syntax, you can gain at
least a functional knowledge of Objective-C in literally an hour or two.
It'll probably take some practical use and a couple of missteps to
really "get" it - like really understanding the difference between
calling a function and sending a message, and the implications of that
difference - but putting together a status bar item is a piece of cake
once you let the tools work for you.

Depending on the complexity of your app, I think it's entirely likely
that you'll be creating a single subclass (of NSObject) that will act as
the delegate for your application and the target of the menu commands
you create. The trickiest thing you'll hit is a bug in either the
implementation or documentation of NSStatusBar, depending on your point
of view:

The way you create your status bar item is by sending
statusItemWithlength: to the NSStatusBar. This will create the item and
give you back a reference so you can actually set its properties. The
documentation notes, "The receiver does not retain a reference to the
status item, so you need to retain it."

The Cocoa memory contract says that if you retain something, you're
responsible for releasing it later. But if you try to release the status
item, your app will crash because apparently the status bar also sends a
release. So don't, and all will be fine.