Re: C'mon Apple! DECIDE! (QuickTime Obj-C API)
Re: C'mon Apple! DECIDE! (QuickTime Obj-C API)
- Subject: Re: C'mon Apple! DECIDE! (QuickTime Obj-C API)
- From: Ken Tabb <email@hidden>
- Date: Mon, 29 Apr 2002 17:57:41 +0100
On Saturday, April 27, 2002, at 05:05 pm, Bill Bumgarner wrote:
QuickTime is a cross platform API/implementation and, as such, it needs
to have an API that is easily integrated into many different
development platforms. An ANSI-C compliant procedural API is about as
cross-platform as you can get.
It may be cross platform but you still need to include the Carbon
headers in OS X unless you're only viewing pre-rendered QuickTime stuff.
WebObjects is a cross platform API which runs on a lot more OS's than
QuickTime, yet it's totally object oriented.
However, don't let this stop you from using QuickTime in Cocoa
applications. Cocoa provides an NSMovieView and NSMovie class.
These classes are simple wrappers around the display of a QT movie and
a QT movie itself.
Part of the trouble is that these Cocoa convenience classes only let you
display QuickTime content. Supposing you wanted to write an app to edit
or create QuickTime content, NSMovieView and NSMovie are the least of
your concerns.
That's not to say I don't appreciate their existence, just that it's
only half of the story.
wrapping a complex, general purpose, procedural API with a set of ObjC
classes that intelligently provide access to that functionality in a
general purpose fashion is actually <b>very hard</b>.
The QuickTime for Java API seems to do a very good job of this. I don't
see why Apple couldn't get the QuickTime for Java API moved over to
Obj-C... the object hierarchy could be the same, the docs could be
pretty much the same aside from syntactical changes between Java and
Obj-C (there's already a decent Apple-written QuickTime for Java book).
The only API changes in the docs are things like "add it to an NSView
instead of a Java canvas" etc. Apple are already used to upgrading the
QTJ API when QuickTime and/or the OS gets an upgrade.
Even once done, maintaining the OO wrappers can be costly in that the
wrappers have to be modified to track any changes made in the
underlying procedural APIs.
This is already the case with QTJ though. If the same object hierarchy
were used (which is quite an elegant one), the work done in updating QTJ
could easily be re-used for the Obj-C one too. After all, if both share
the same object hierarchies, and both link to the same Carbon procedural
API (because that's the only 'real' one for QuickTime... QTJ just links
to native calls, which is why it only exists on Mac & Win despite being
Java), then both need to update the same bits at the same time... unless
there are specific changes to Java and/or the Obj-C Runtime, but that's
a different argument.
Certainly, this is also an issue when you have built your own specific
purpose wrapper, but to a much lesser degree in that your specific case
solution doesn't exercise the entire underlying API and is not trying
to express all functionality possible.
I agree this is the case, although there'd probably be less overall time
wasted if Apple updated 1 Obj-C API than if a thousand developers all
updated their custom-wrapped APIs (bearing in mind the developers don't
have access to all of the same info as Apple internal QuickTime / Cocoa
people so would probably spend a lot more time fumbling around trying to
get every ounce of performance out of it).
However, it is trivial to hide the procedural calls behind opaque data
types and a decent set of classes to wrap the APIs in the fashion you
need.
Agreed, but it still involves learning parts of 2 APIs... look at the
Apple sample code for CocoaCreateMovie... and notice the header files
and frameworks it includes besides QuickTime.framework and AppKit /
Foundation. I agree with a previous poster that choice is a good thing
(being able to include Carbon in Cocoa), but it would be good if it were
a choice and not a necessity to learn both APIs.
It is likely that Apple will make an ObjC accessible version of the QT
APIs available someday. Until that happens, don't let the lack of it
stop you from using Cocoa / OS X!
It doesn't necessarily stop you, but inferring that you can edit
QuickTime stuff in Cocoa (by for example drawing a "Mac OS X
Architecture" diagram with a "Carbon / Cocoa" layer as equal citizens
above a "Quartz / QuickTime / OpenGL" layer) is misleading... you can
edit QuickTime stuff with Carbon within Cocoa, but not within Cocoa
itself.
So yes I'd be v. happy for an Obj-C API for QuickTime (editing /
creation and display)!
Ken
- - - - - - - - - -
Ken Tabb
Mac & UNIX Technical bloke (C, C++, Obj-C, Java) - Health & Human
Sciences
Machine Vision & Neural Network researcher - Computer Science Dept
University of Hertfordshire, UK
http://www.health.herts.ac.uk/ken/
Certified non-Microsoft Solution Provider
_______________________________________________
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.