Developing Applications With The QuickTime For Cocoa Kit
Volume Number: 21 (2005)
Issue Number: 6
Column Tag: Programming
QuickTime Toolkit
Back To The Future, Part II
by Tim Monroe
Developing Applications With The QuickTime For Cocoa Kit
In the previous QuickTime Toolkit article ("Back to the Future" in MacTech, May 2005), we began looking at
Apple's new Cocoa framework for displaying and modifying QuickTime movies, called the QuickTime For Cocoa Kit
or the QTKit. We saw how to open and display a movie in a window of a Cocoa document-based application; we
also saw how to manipulate movies using command-line tools, which would be quite useful for batch processing
via shell scripts or other scripting mechanisms.
Introduction
In this article, we'll continue our investigation of the QTKit framework, which is available in QuickTime 7
on both Panther and Tiger. We'll see how to extend the sample application KitEez that we began developing in
the previous article to support the complete set of standard document behaviors (Save, Save As, Revert, and so
forth). Toward the end of this article, we'll see how to restrict the file types displayed in the file-opening
dialog box. Then in the next article, we'll wrap up our tour of the QTKit by looking at some advanced uses of
its classes and methods.
Document Behaviors
So far, our sample application KitEez is able to open any kind of file that QuickTime can handle -- standard
movies files, Flash files, MP3 files, MPEG-4 files, AIFF files, text files, and so forth -- and display the
movie data in a Cocoa document window. Figure 1 shows a typical KitEez document window. As you can see, the
movie and the movie controller bar completely fill the content region of the window. As you can also see from
the hourglass shape of the thumb in the movie controller bar, the movie is editable using the items in the
Edit menu or their standard keyboard shortcuts.

Figure 1. A window that
contains a QTMovieView
Because movies opened using KitEez are editable, we'll want to support all the standard document behaviors:
Undo/Redo, Save, Save As, Revert to the last saved version, and so forth. If you have developed Cocoa
document-based applications before, then you'll know that Cocoa provides a sophisticated document architecture
that tracks changes to a document and responds appropriately to user actions. For instance, if the user tries
to close an edited but unsaved document window, Cocoa will display a sheet that prompts the user to save or
discard those changes. The Cocoa document architecture, however, has no knowledge of what it means to save a
QuickTime movie, so we'll need to override a few NSDocument methods to add that and other standard document
behaviors to our sample application.
Supporting Editing Operations
It's actually trivially easy to support the standard undo and redo mechanism for edits made to a QuickTime
movie that is displayed in a QTMovieView in a Cocoa document window. All we need to do is make the associated
QTMovie object editable, and we saw how to do this in the previous article with this single line of code:
[movie setAttribute:[NSNumber numberWithBool:YES]
forKey:QTMovieEditableAttribute];
Once we've executed this line of code, the movie can be edited using QTMovieView methods like cut:, copy:,
paste:, trim:, and the like. Indeed, the default behavior of the Edit menu items is to issue these IB actions,
so we need to write exactly 1 line of code (shown above) to have a full-fledged movie editing application.
QTKit provides the standard multiple-level undo and redo processing. A user can cut, copy, and paste to his
or her heart's content and then undo all those editing operations. Also, QTKit automatically provides the
standard drag-and-drop editing operations. A user can drag a movie segment out of a movie window and into any
other object that can accept dragged movie data. Figure 2 shows the drag image being dragged out of a movie
window.

Figure 2. A dragged movie segment
The performance of the dragging in QTKit-based applications is vastly improved over that provided by the
standard movie controller. In some benchmarks, the creation of the drag image alone was over 3000 times faster
in QTKit applications than in applications using the movie controller's drag-and-drop capability.
Saving an Edited Movie
When the user selects the Save item in the File menu, the first responder's saveDocument: method is
executed. The NSDocument implementation of this method checks to see whether a file is already associated with
the document; if not, it displays the file-saving sheet to elicit a filename and location from the user. This
will never actually happen in KitEez, since we only ever open movies from existing files. But it might happen
that an edited movie cannot be saved into the file it was opened from. For instance, KitEez is able to open
MP3 files as QuickTime movies (transparently invoking its MP3 import component), which are then fully
editable. But QuickTime does not provide an MP3 export component, so KitEez is unable to save the edited data
back into the original MP3 file. In that case, we'd want to display the file-saving sheet so that the user can
save the data as a QuickTime movie file (.mov).
The QTMovie class provides a method that we can use to determine whether a movie object can be saved into
its associated file, canUpdateMovieFile. Listing 1 shows our override of the saveDocument: method.
Listing 1: Saving a document
- (IBAction)saveDocument:(id)sender
{
if ([[movieView movie] canUpdateMovieFile])
[super saveDocument:sender];
else
[super saveDocumentAs:sender];
}
This is simple enough: if the movie can be saved into the file it was opened from, then we just call
NSDocument's saveDocument: method; otherwise we call its saveDocumentAs: method.
NSDocument's saveDocument: and saveDocumentAs: methods internally call
writeWithBackupToFile:ofType:saveOperation: to actually write the document data into the associated file. We
can override that method to save the edited movie data into the original movie file or into the newly-selected
destination file. Listing 2 shows our override method.
Listing 2: Writing out the movie data
- (BOOL)writeWithBackupToFile:(NSString *)fileName
ofType:(NSString *)documentTypeName
saveOperation:(NSSaveOperationType)saveOperationType
{
BOOL success = NO;
if (saveOperationType == NSSaveOperation)
success = [[movieView movie] updateMovieFile];
else if (saveOperationType == NSSaveAsOperation) {
success = [[movieView movie]writeToFile:fileName
withAttributes:nil];
if (success) {
QTMovie *newMovie = [QTMovie movieWithFile:fileName error:nil];
[movieView setMovie:newMovie];
[self initializeMovieWindow];
}
}
return success;
}
When the requested operation is NSSaveOperation, we simply call the updateMovieFile method to update the
movie atom in the movie file. When the requested operation is NSSaveAsOperation, we need to do a little more
work. As you can see, we first call the QTMovie method writeToFile:withAttributes: with a nil dictionary of
attributes. This has the effect of writing only the movie atom into the destination file. What we end up with
in this case is a reference movie, that is, a movie whose media data is located in some other file. If instead
we wanted a self-contained movie file, we could call writeToFile:withAttributes: with a dictionary that
indicates that we want the movie to be flattened into the destination file, like this:
success = [[movieView movie] writeToFile:fileName
withAttributes:[NSDictionary
dictionaryWithObject:[NSNumber numberWithBool:YES]
forKey:QTMovieFlatten]];
I'll leave it as an easy exercise for the reader to add an accessory view to the save panel that allows the
user to determine whether a movie is saved as a reference movie or as a self-contained movie, like the one
displayed by the QuickTime Player application (Figure 3).

Figure 3. An accessory view in a save panel
As you know, the standard behavior when performing a Save As operation is to replace the movie in the movie
view with the movie in the new destination file. So, once we've called writeToFile:withAttributes:, we then
need to open the movie in the new file and set it as the movie displayed in the movie view. Then we need to
perform any movie configuration that must happen when a movie is opened. As you can see, we call the method
initializeMovieWindow, defined in Listing 3. This code is lifted wholesale from the
windowControllerDidLoadNib: method we considered in the previous article on QTKit.
Listing 3: Initializing a movie and its window
- (void)initializeMovieWindow
{
QTMovie *movie = [movieView movie];
// make the movie editable
[movie setAttribute:[NSNumber numberWithBool:YES]
forKey:QTMovieEditableAttribute];
// use the QTKit's resize indicator, not NSWindow's
[[movieView window] setShowsResizeIndicator:NO];
[movieView setShowsResizeIndicator:YES];
// add a listener for size-changed notifications
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(boundsDidChange:)
name:QTMovieSizeDidChangeNotification object:movie];
}
It's perhaps worth mentioning that the writeWithBackupToFile:ofType:saveOperation: method is deprecated in
Mac OS X version 10.4 and later. Since however we want our application to run under all environments
supporting QTKit, including Mac OS X version 10.3.9, we'll stick with this method.
Reverting to the Last Saved Version of a Movie
There remains just one document behavior for us to implement, namely reverting to the last saved version of
a movie file. When the user selects the Revert item in the File menu, the Cocoa document handling code
displays the sheet shown in Figure 4.

Figure 4. The Revert sheet
If the user presses the Revert button, the revertDocumentToSaved: method in the first responder is invoked.
We won't override that method, so that method in the NSDocument class will be called. Rather, we'll override
the revertToSavedFromFile:ofType: method, as shown in Listing 4.
Listing 4: Reverting to a saved movie file
- (BOOL)revertToSavedFromFile:(NSString *)fileName
ofType:(NSString *)type
{
QTMovie *newMovie = [QTMovie movieWithFile:fileName error:nil];
[movieView setMovie:newMovie];
[self initializeMovieWindow];
return YES;
}
As in the Save As case shown in Listing 3, we open the specified file and assign it to the movie view; then
we perform the required initialization of the movie and movie window. Also, we return the value YES to make
sure that the change count of the document is cleared.
So, we have successfully implemented a reasonably complete set of document-related behaviors in our sample
application KitEez, using just a very few QTMovie methods: canUpdateMovieFile, updateMovieFile, and
writeToFile:withAttributes:. At no point did we need to step outside the methods provided by QTKit into the
underlying Carbon APIs. This stands in stark contrast to the work we needed to do in our earlier Cocoa
movie-playing application MooVeez, which relied on the now-deprecated Cocoa classes NSMovie and NSMovieView
for its QuickTime support. I invite you to take a second look at the article describing those classes ("The
Cocoanuts" in MacTech, December 2002); by comparing the Carbon-laced methods we had to write there with the
purely Cocoa-based methods we've seen here, you will get a very good appreciation of how big an advancement
the QTKit is over those earlier classes.
Openable File Types
In the previous article introducing QTKit, we saw that we can very easily configure the file-opening dialog
box to list all files openable by QuickTime by overriding the panel:shouldShowFilename: method and calling the
canInitWithFile: class method. That method returns YES just in case a specified file can be used to initialize
a QTMovie object. For certain purposes, however, we might want to restrict the types of files that the user
can open to some more limited set. For instance, as you probably know, QuickTime can open text files with its
text movie importer -- which converts the text into a series of frames in a text track. (See "Word is Out" in
MacTech, November 2000 for more information on QuickTime's text-handling capabilities.) But it's doubtful that
most applications that can open and display QuickTime movies would want to allow text files to be opened by
the user. Ditto for HTML files. Ditto for PDF files.
QTKit provides an easy way to allow the user to open only the kinds of files that would normally be
considered as media files and hence openable by a QuickTime application. Instead of using the canInitWithFile:
method, we can use the movieFileTypes: method. This too is a class method, so you don't need to have an
existing QTMovie object in order to call it.
The movieFileTypes: method returns an NSArray of file types and file extensions that can be opened by
QuickTime. This method takes one parameter, which indicates the kinds of file types that you want to be
included in the array. Currently these flags are defined for specifying file types:
typedef enum {
QTIncludeStillImageTypes = 1 << 0,
QTIncludeTranslatableTypes = 1 << 1,
QTIncludeAggressiveTypes = 1 << 2,
QTIncludeCommonTypes = 0,
QTIncludeAllTypes = 0xffff
} QTMovieFileTypeOptions;
Passing the value QTIncludeCommonTypes indicates that you want the array to contain only those file types
and extensions that are commonly thought of as openable by QuickTime; this includes the extensions .mov and
.mqv, as well as any file types that can be imported in place by QuickTime. (Recall that to be able to import
a file in place is to be able to import the file without having to create a new file to hold the imported
data.)
The QTIncludeStillImageTypes flag indicates that you want the array to include, in addition to the common
file types, all types of files that can be opened by QuickTime using one of its available graphics importers.
The QTIncludeTranslatableTypes flag indicates that you want the array to include also those file types that
can be opened by QuickTime using one of its available movie importers, whether or not the file data can be
imported in place; this array excludes however any file types that would require an aggressive importer. (An
aggressive importer is one that can handle file types like text or HTML that would not normally be considered
openable by QuickTime.) Finally, the QTIncludeAggressiveTypes flag indicates that you want the array to
include file types that require an aggressive importer.
Obviously, the QTIncludeAllTypes flag sets all the bits in the options parameter and requests that the
returned array include file types and file extensions for all files that QuickTime can open, using any
available graphics or movie importer. Passing the array associated with the QTIncludeAllTypes flag to
NSOpenPanel's runModalForTypes: method is essentially identical to using the canInitWithFile: method inside
our panel:shouldShowFilename: override method.
It's important to realize that, for instance, the array returned when specifying the
QTIncludeStillImageTypes flag will include all file types and extensions for still image files as well as all
file types and extensions for the common movie types. That is to say, that array does not contain only the
file types and extensions for still image types. If you wanted an array like that, you would need to use
Component Manager functions to iterate through all installed components and select only those of type
GraphicsImporterComponentType. Listing 5 shows how you might do that.
Listing 5: Finding still image types
0
fileTypes = [NSMutableArray array];
ComponentDescription findCD = {0, 0, 0, 0, 0};
ComponentDescription infoCD = {0, 0, 0, 0, 0};
Component comp = NULL;
OSErr err = noErr;
findCD.componentType = GraphicsImporterComponentType;
findCD.componentSubType = 0;
findCD.componentManufacturer = 0;
findCD.componentFlags = 0;
findCD.componentFlagsMask = cmpIsMissing |
graphicsExporterIsBaseExporter;
while (comp = FindNextComponent(comp, &findCD)) {
err = GetComponentInfo(comp, &infoCD, nil, nil, nil);
if (err == noErr) {
if (infoCD.componentFlags &
movieImportSubTypeIsFileExtension)
[fileTypes addObject:[[[NSString
stringWithCString:(char *)&infoCD.componentSubType
length:sizeof(OSType)]
stringByTrimmingCharactersInSet:[NSCharacterSet
whitespaceCharacterSet]] lowercaseString]];
else
[fileTypes addObject:[NSString
stringWithFormat:@"\'%@\'", [NSString
stringWithCString:(char *)&infoCD.componentSubType
length:sizeof(OSType)]]];
}
}
Conclusion
In this article, we've added the standard document-handling behaviors to our KitEez sample application.
We've seen how to use QTKit methods to support saving an edited movie into its original file or into a new
file, and we've seen how to revert to the last saved version of a movie file. KitEez is now a reasonably
complete multi-document movie opening and editing application.
In the next article, we'll take a look at some of the more advanced operations we can use the QTKit
framework to perform. We'll see how to add images to an existing QuickTime movie, work with notifications and
delegates, and execute QTKit methods on a secondary thread.
Tim Monroe is a member of the QuickTime engineering team at Apple. You can contact him at
monroe@mactech.com. The views expressed here are not necessarily shared by his employer.