Re: Carbon Events vs Cocoa Events
Re: Carbon Events vs Cocoa Events
- Subject: Re: Carbon Events vs Cocoa Events
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 1 Apr 2002 10:47:11 -0500
It isn't entirely fair to say that 'The Carbon event model is modeled as
much as possible after Cocoa, but it is a poor substitute.'.
The granularity of the two event models-- as Erik indicated-- are
completely different. Cocoa has a very high level event model where the
programmer typically does not worry about handling any singular even. In
the cases where it is necessary-- say, tracking the mouse within the view
of a drawing application-- one typically only needs to catch and track the
exact set of events you need only in that one object through a very simple
set of APIs.
Carbon Events, on the other hand, tend to be much lower level. It tends
to be up to the developer to translate from a specific event to a
particular command (example: The various case statements in SimpleText
that lead to a DoCommand() call -- all of this is automatic in Cocoa). In
general, Cocoa provides a much higher level set of UI widgets to work with.
Cocoa widgets tend to be complete in and of themselves and the developer
generally only has to either set their value or query them-- but not
actually control or track them (though those options are available through
high level APIs).
Compare the SimpleText source tree to the TextEdit source tree. In
SimpleText, a tremendous amount of code is devoted to making the
application look and feel like a proper OS X application. In Cocoa, the
look and feel is given to the developer for free, almost all of the code
is devoted to implementing stuff that is unique to TextEdit.
Where Carbon has a distinct advantage as the target of a porting effort
where the code to be ported assumed a relatively manual approach to even
handling (i.e. was created with a relatively similar granularity as Carbon)
. In that context, Carbon can often be easier to morph into behaving
like whatever the foreign event model expects whereas morphing Cocoa's
event model and object hierarchy can be extremely difficult.
(If you are porting a large base of code to Cocoa and do not need to
maintain cross platform compatibility or can cleanly subdivide the
event/UI code from the 'business logic' of your code, you will likely be
better off tossing the UI code altogether and building a new app in Cocoa.
Developer productivity with Cocoa, once the developer groks the design
model, is mind blowingly high.)
Now, Apple Events are a completely different story. They can't be
directly compared to either Cocoa or Carbon events-- they solve a
different problem. They are incredibly rich and a tremendous amount of
power can be had via AE that is not present in Carbon or Cocoa events.
The APIs tend to be fairly low level in nature. Given Apple's moves to
'everything Cocoa', it is likely that we will see nice ObjC wrappers
around AE in the future.
b.bum
On Sunday, March 31, 2002, at 02:15 PM, email@hidden
wrote:
From: "Erik M. Buck" <email@hidden>
To: "Tom Condon" <email@hidden>, <email@hidden>
Subject: Re: Carbon Events vs Cocoa Events
Date: Sat, 30 Mar 2002 22:35:21 -0600
Organization: EMB & Assocites Inc.
----- Original Message -----
From: "Tom Condon" <email@hidden>
To: <email@hidden>
Sent: Saturday, March 30, 2002 10:17 PM
Subject: Carbon Events vs Cocoa Events
What is the difference between the Carbon Event model and the Cocoa Event
model? It seems from reading the documentation that the Carbon model is
much richer than the Cocoa event model. I would expect that they share
the
underlying implementation, but maybe not
In Cocoa, the event model is so powerful that you don't have to worry
about
it. It is a non-issue. Cocoa is not really comparable to Carbon in this
case because the combination of the NSRunLoop class, the NSApplication
class, the responder chain, and Objective-C messaging makes something like
the Carbon event model totally irrelevant in most cases. The Carbon event
model is modeled as much as possible after Cocoa, but it is a poor
substitute.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.