Re: Carbon Events vs Cocoa Events
Re: Carbon Events vs Cocoa Events
- Subject: Re: Carbon Events vs Cocoa Events
- From: Charles Srstka <email@hidden>
- Date: Mon, 1 Apr 2002 13:02:06 -0600
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.
_______________________________________________
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.
_______________________________________________
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.