Re: Cocoa, a complete Mac OS X API?
Re: Cocoa, a complete Mac OS X API?
- Subject: Re: Cocoa, a complete Mac OS X API?
- From: Ali Ozer <email@hidden>
- Date: Wed, 13 Jun 2001 14:38:31 -0700
As was discussed in the recent "proof of Cocoa superiority" thread,
Apple and third-party developers have used Cocoa to write some pretty
full-featured apps, including in the past when there was no high-level
APIs on the system but Cocoa.
On Mac OS X there are additional demands on apps: Some due to
integration with new technologies, others due to the richer Aqua user
experience, others due to the compatibility with 9 or legacy 9
apps/documents, etc.
Cocoa has come a long way since NextStep/OpenStep to address these
additional needs, but there are indeed some holes, both in the API and
functionality. But rest assured that Cocoa is constantly being enhanced
(for instance, in 10.0 open panel can now choose files based on types in
addition to extensions). In the meantime, in areas where there is no
Cocoa API, you can usually use Carbon, Posix, Quartz, or other APIs on
the system with little or no difficulty. In that sense, Cocoa doesn't
have to cover all the APIs to be "complete". But, in line with Cocoa's
philosophy, Cocoa should make "simple things simple" --- that is,
automatically do things for you that most apps need to do --- and
"complex things possible" --- that is, allow doing sophisticated or
out-of-the-norm things, with a bit more code.
For instance, you mention you need do resource fork manipulation, and
there are no Cocoa APIs for this. You can easily use the Resource
Manager APIs, which are actually in a low-level service in
CoreServices.framework, already automatically available to all apps.
Sometimes making the C calls might be inconvenient --- especially if
there is a mismatch between types (for instance, converting FSRefs to
paths or URLs); but it's just a bunch of C calls in the end. If you
have to manipulate resource forks, you can. (Just note that for new
document formats, we do not recommend using resource forks, as they tend
to be fragile in many circumstances.)
As far as UI parity, Cocoa is sometimes behind Carbon or the guidelines;
but in other cases it's ahead. Consider drawers, services, toolbar, font
panel... In any given update, there are likely to be new features and
specs which Carbon and/or Cocoa are not yet providing public APIs for.
Ali
Begin forwarded message:
>
From: Jorge Salvador Caffarena <email@hidden>
>
Date: Wed Jun 13, 2001 11:43:54 AM US/Pacific
>
To: email@hidden
>
Subject: Cocoa, a complete Mac OS X API?
>
>
Hello to all!
>
>
First of all, I must say that I am enjoying a lot learning Cocoa by
>
examples, "Learning Cocoa" book, this list and the cool web sites
>
around. I am newbie in Cocoa, but not in programming and I have found
>
the O'Reilly book worth its money.... but that's another story :-)
>
>
The feeling I have about Cocoa right now is that it is a superb API,
>
with a excellent IDE (PB & IB) but that is lacking some key features
>
for common Mac apps. I have read some examples of this in this list, as
>
the "AuthorizationExecuteWithPrivileges" lack of features, the Aqua
>
Interface Guidelines about NSBoxes and its titles and the actual
>
implementation inconsistence, the inexistent API for getting the list
>
of running process, and one of the most annoying things about Cocoa for
>
me is its total lack of support for resources forks.
>
>
Almost all this things can be done using Carbon calls (making a Carbon
>
wrapper is one thing I do not have any idea on how to do) buuuuut, I
>
thought that Stevie told to us that the state-of-the-art API for
>
developing Mac OS X applications is Cocoa, and Carbon is just to make
>
the Mac OS 9 leap. But it turns out that Carbon is more feature rich
>
than Cocoa, in terms of Mac friendship.
>
>
So the fact is that I started learning Cocoa, and realized that most
>
ideas for applications involved accesing to resource forks, but this
>
cannot be done with Cocoa. I have to use Carbon. Maybe it is time to
>
spend some more bucks in "Learning Carbon" :-P
>
>
Jorge Salvador Caffarena
>
http://homepage.mac.com/eevyl/