Re: Carbon Events vs Cocoa Events
Re: Carbon Events vs Cocoa Events
- Subject: Re: Carbon Events vs Cocoa Events
- From: Chris Thomas <email@hidden>
- Date: Mon, 1 Apr 2002 11:52:52 -0800
See
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/
Misc/EventsPage.html
for everything you need to know (I think). If it's not covered here, it
probably doesn't exist yet.
In particular, check out the "Overview of Events" topic first.
Chris
On Monday, April 1, 2002, at 11:02 AM, Charles Srstka wrote:
The question is, how do you have some method or function get called
whenever an event occurs in Cocoa? In Carbon, it's easy, because you
can just do whatever you want with the EventRecord that you get from
WaitNextEvent (in the old model - I don't know much about the new one
to comment on it). How could you make a simple app in Cocoa that logged
all events, for example? I can do that in Carbon, but I have no idea
how it would be done in Cocoa.
On Monday, April 1, 2002, at 09:47 AM, Bill Bumgarner wrote:
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, cocoa-dev-
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.
--
Can't you feel the peace and contentment in this block of code? Ruby is
the language Buddha would have programmed in.
Sean Russell, <
http://www.germane-software.com/~ser/Software/rexml/>
_______________________________________________
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.