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: "Dennis C. De Mars" <email@hidden>
- Date: Wed, 13 Jun 2001 23:34:15 -0000
Jorge Salvador Caffarena <email@hidden> said:
>
> The resource fork (IMO) is very convenient, but you can avoid using it.
>
> Are you looking at legacy code that heavily depends on resources?
>
>
Well, I plan to do a complete rewrite of one REALbasic application I
>
developed (eeCD 1.2 for Mac OS and Mac OS X) into Cocoa. But this app is
>
for managing the "CD Remote Programs" file that stores the info about
>
Audio CDs (artist, title and song names), this file is still in use
>
under Mac OS X and a very Apple app make use of it, iTunes. The info of
>
this file is in the resource fork, and it appears it will continue to be
>
in that place, so I *need* resource support from Cocoa. I just realize
>
that Apple forces me to make a Carbon wrapper for resource access.
>
Something that I suppose difficult for a Cocoa newbie. I did some "old
>
school" Mac OS programming in C some years ago, before Carbon, so maybe
>
I just can get it done sonner or later.
It is REAL EASY to call Carbon APIs from Cocoa. You just include <Carbon/Carbon.h> in
your source file and write the call in C just like you would in a Carbon program. You
make sure your project links to Carbon.framework, and that's it. You don't have to
write any wrappers, you just call it. (You could write some sort of Obj C wrapper if
you felt like it, but it's not necessary).
I think there is an example provided with the Developer tools, but I'm afraid I can't
name it as I am not at my Mac right now. Here's a link to an example on Apple's web
site, but this same thing is probably in one of the example folders with the OS X
Developer Tools:
ftp://ftp.apple.com/developer/Sample_Code/Cocoa/Cocoa_With_Carbon_or_C__.sit
>
>
What I want to say (maybe I am having difficulties in expresing my ideas
>
in English, sorry about that) is that I do not see Cocoa as the future
>
"unique" Mac OS X API, as Apple want us to think. There is so much of
>
that called "legacy code" that will be very difficult to eliminate from
>
Mac OS X.
If you want to do anything serious with multimedia stuff, (beyond NSMovie and NSSound)
I think you have to use Carbon, so that's one major area right there. Even so, you can
still write most of your app using Cocoa (avoiding the old, crufty Mac OS calls) and
just access Carbon for the managers that are missing (and these are generally newer
APIs which are nicer to use because they don't have the baggage of over a decade and a
half of backward compatibility hacks that the older Mac OS managers have).
Even if a Cocoa flavored interface to these APIs emerges, it might well call the Carbon
APIs under the surface. Some of Cocoa does this already. So yes, Carbon will probably
always be an essential component of OS X. But since you can call Carbon at will from
any Cocoa program, you never have to worry about being stuck because some essential
functionality isn't implemented in Cocoa. You truly have all of the power of Carbon
_plus_ Cocoa at your disposal without having to do any extra work.
- Dennis D.