Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Adding menu to right side of system menu bar

Keep in mind folks that Cocoa has its advantages today because of its mature
framework. Just like a few years ago the fastest way to a mac app was
through PowerPlant.

I, of coure, disagree with Chris in detail, though not in principle. If
there was a first rate framework for Carbon (perhaps PPx will be the one?)
then I think many of the advantages of Cocoa disappear and then it's just a
matter of which framework you know better and which language you prefer. I
mean let's be honest, with a good carbon framework built on modern carbon
technologies one can create a user interface just as quickly in either Cocoa
or Carbon.

And of course, if a really good framework for Carbon doesn't materialize and
isn't well supported and doesn't mature, then yeah, Cocoa will probably be
the best game in town.

Bryan

> ----------
> From: Chris Hanson
> Sent: Friday, August 29, 2003 2:09 AM
> To: email@hidden
> Subject: Re: Adding menu to right side of system menu bar
>
> On Thursday, August 28, 2003, at 07:09 PM, Mike Kluev wrote:
> > On 28/08/2003 09:00, Chris Hanson <email@hidden> wrote:
> >> Similarly, I think you need to have some knowledge of Carbon, too, and
> >> be comfortable working with Carbon APIs since there are still
> >> technologies available in Carbon that aren't part of Cocoa.
> >
> > Still? Just curious, Chris, do you think that once this is fixed
> > (so everything is available in pure Cocoa) all "advanced Mac OS X
> > developers" will be using Cocoa?
>
> I think at that point it won't be necessary to have some Carbon
> knowledge to be an advanced Mac OS X developer.
>
> Of course, that's assuming Apple ever provides 100% coverage of APIs
> like the Resource Manager in Cocoa. I suspect they won't bother.
>
> Part of the reason I expect advanced Mac OS X developers to have
> knowledge of both Carbon and Cocoa is so they can make the best, most
> economic determination of when to use which set of APIs.
>
> For instance, if you're porting a game, it may actually not make sense
> to try and use Cocoa for everything. Most of what you're dealing with
> is going to be are C APIs like OpenGL, CoreAudio, CoreGraphics, IOKit
> (HID Manager), and OpenPlay, and maybe some CoreFoundation; the game
> code you're porting is likely to be C++ code written to Microsoft's
> DirectX API. It's largely a toss-up as to whether to use Cocoa or
> Carbon for those few bits of application-style functionality you need.
>
> But if you're developing a new productivity application that (on the
> Macintosh platform) only needs to support Mac OS X, I'd strongly
> recommend Cocoa rather than Carbon. It's your fastest route to a 1.0
> release with the all features users expect of Mac OS X applications.
> And if you're writing a new application for Mac OS X only, I'd say go
> with Cocoa all the way.
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.