QT / Cocoa (was Re: Another controversial question)
QT / Cocoa (was Re: Another controversial question)
- Subject: QT / Cocoa (was Re: Another controversial question)
- From: Ken Tabb <email@hidden>
- Date: Tue, 4 Sep 2001 17:36:30 +0100
And so it was that Ondra Cada said on 3/9/01 5:56 pm:
>
Therefore there is so much ranting when some API (like authentification
>
instead NIAccess, QuickTime instead /never really completed/ NeXTTIME, etc)
>
is excluded from Cocoa: that's like you was used to powered tools, and now
>
somebody took them from you, saying the plain old hand saw, screwdriver and
>
hammer can be used to do the job.
I think your analogy is not quite parallel to the situation of
Cocoa/QuickTime... I think a better analogy would be "I've removed your
flathead screwdriver, and am giving you a crosshead screwdriver... by the
way you'll also need to get yourself a flathead screwdriver, as the
crosshead won't directly interface to all the screws you want to unscrew".
I think in the case of QuickTime / Cocoa it's a fair criticism to moan
about their integration when Apple puts up the pretty Steve Jobs OS X
architecture picture (at
http://developer.apple.com/macosx/architecture/). That diagram makes the
point that things on the same level (eg. Classic / Carbon / Cocoa / Java)
are independent of each other and that you can choose which you want to
use to access the stuff on the levels below. (With the assumption that
'Java' means the Sun Java API and not the Java language, which can of
course be used in Cocoa).
However these APIs are not independent. You can't do QuickTime stuff in
Cocoa without some knowledge of Carbon and all the memory handling /
display idiosyncracies that the API entails. If anything (and in the
sense of this example only!) Cocoa should sit atop Carbon atop QuickTime,
as without Carbon knowledge, you're not going to be able to do much
QuickTime stuff in your Cocoa app. Cocoa is therefore not independent of
Carbon, and they are not true alternative APIs - Cocoa is dependent on
Carbon for QuickTime stuff (and other stuff possibly). And you won't
learn about it in the QuickTime API docs, as it's Carbon stuff, not
QuickTime stuff. Of course this may change in the future (eg. they may
make the NSMovie implementation more like the QT for Java 'Movie' class),
but Apple never seems to want to comment on this even in an NDA forum, so
we can only assume that Cocoa developers wishing to use QuickTime in a
more than playback capacity (in which case just use NSMovieView and put
up with the display glitches) will just have to learn Carbon too. Hmm
suddenly seems like the Cocoa / QuickTime integration & docs are a bit
poor doesn't it? Or at the very least like that pretty "you get to choose
the API you want to use" diagram is plain deceptive.
If you think I'm wrong, check out the newly posted CreateCocoaMovie
project in the Sample Code section of the ADC website. The
QuickTimeCode.h and .m both include the <Carbon/Carbon.h> header (as well
as the necessary QuickTime stuff).
Therefore I and others moan that the Cocoa / QuickTime integration is
incomplete *if* Cocoa and Carbon are to be viewed as alternatives (like
everyone, including Apple, wants you to believe). If you disagree that
Cocoa is dependent on Carbon maybe you'd like to send alternative
QuickTime / Cocoa code which offers the same functionality but which
doesn't use Carbon? I would eat my hat if you could.
Ken
currently pouring Chilli sauce on his hat in the hope that he's wrong.
----------------------------------------------
Ken Tabb
Mac & UNIX Propellerhead & Network Bloke (Health & Human Sciences)
Computer Vision / Neural Network researcher (Computer Science)
University of Hertfordshire
e-mail: email@hidden
http://www.health.herts.ac.uk/ken/
Certified non-Microsoft Solution Provider