Re: Cocoa friendly Quicktime APIs?
Re: Cocoa friendly Quicktime APIs?
- Subject: Re: Cocoa friendly Quicktime APIs?
- From: Oleg Svirgstin <email@hidden>
- Date: Sat, 08 Mar 2003 16:11:39 +0300
Hi all!
IMHO, QuickTime suffers from its Classic heritage. Not from being
"Carbon-oriented". It is NOT.
I mean these FSSpec, absolutely necessary to use while recording sound. They
do LIMIT us (our users) in their choice of file names, or make us invent
some complex file-manipulation schemes. It is NO good. Extra code means
extra bugs... and less features for the same time and money. In the long run
it hurts the platform sales!
Carbon is transparently callable from Cocoa, I consider it as an extra
source of fun, never a problem. Carbon is as powerful as a trailer truck,
and the fact that we can used it anywhere warms my self-confidence. Imagine
having a super-fighter's super-engine under the hood of your car...
Now some problems:
1. After I record a sound to a movie file, however I create a NSMovie after
this (by URL with ref:YES and ref:NO, with a Movie instance received from my
OpenMovieFile etc) the object does NOT store in the archive. I use a
workaround, but I want to know whether it is a bug in NSMovie, in
documentation or in NSKeyedArchiver/NSKeyedUnarchiver. I did not try
NSPasteboard format with the sound movies, but I had suspicious problems
passing between applications an RTFD containing movies. I do pass its PATH
now, everything works fine.
When I store a 30+ M movie into an archive the archive never becomes
significantly larger. I can put up with this situation. I am not even sure I
would be happy with a 3000+ M archive, taking 200 years to load or save...
But for smaller sounds storing them in the archive would simplify my code.
2. Well, I store all my "supporting" files and context-specific archives
inside a wrapper. Real movie names are guarantied to fit all limitations of
FSMakeFSSpec since it is me who generates them. However, there is a
user-controllable instance in the middle of the chain: the name of the file
package and names of directories where a user might put my package. The
users are expected to use very long file names, not in English, and I don't
want to deprive them of that right.
Try to explain a _Diehard Mac User_ that he CANNOT store his file as "the
file that I want to open on my birthday" in a directory with a path like
this: "~/Documents/My documents for the project 656/The documents that I
like/The documents that I like most of all/Don't forget to buy butter/My
files again/...". I am a Mac user since 1987, believe me!
Currently I convert a NSString path to Mac OS (":") separators (taking into
account all that device name trivia), convert it to a pascal string and
pass to the FSSpec creation as a whole. I control the path - normally it is
around 110-150 chars, FSSpec eats it without a problem.
I don't use NSURL because
- I am stupid and stubborn
- I like my own algorithm
- It was the first solution that came into my mind before I knew about
FSSpec <-> CFURL <-> NSURL and I hate to kill a working code, I was a
terrible horrible Cocoa newbie when I started this project...
- I like NSString and every chance to play with these excellent toys while
my wife is sure I am deep in my work...
- Did I tell I am stupid and stubborn?
Does anybody remember a fast and easy way to get folder ids (I mean
FSMakeFSSpec compatible folder ids) from a full path to a directory? Is
there a MODERN way to get folder ids for any folder in HFS+, with any
encoding and practically any length of the path? The ids look like quite
alive in HFS+ even now.
Thanks in advance
IMHO, a better NSMovie and NSMovieView would be a great help to all of us. I
consider an easy to use sound recording as ABSOLUTE must of Cocoa, and I
hope that either Apple or a third-party genius will finally fill this gap
before we all get too old to enjoy it.
I saw an NSMutableSound in my dreams doing all this... :^)
Oleg
_______________________________________________
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.