Re: Carbon Events vs Cocoa Events
Re: Carbon Events vs Cocoa Events
- Subject: Re: Carbon Events vs Cocoa Events
- From: Donald Brown <email@hidden>
- Date: Mon, 01 Apr 2002 13:44:28 -0600
NSApp handles events. I think you'd subclass NSApp and then override
sendEvent: to see them. Or, if you're only interested in a Window, subclass
NSWindow and override its sendEvent:. Those events are moving around behind
the scenes, but you rarely need them.
Donald
on 4/1/02 1:02 PM, Charles Srstka at email@hidden 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.
>
> _______________________________________________
>
> 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.
--
Donald Brown
email@hidden
http://www.eamontales.com
We have met the enemy and he is us - Pogo
_______________________________________________
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.