|Home » Learning Curve
The OS X Pasteboard
A look at a few Cocoa internals.
Pasteboards (aka clipboards) are mechanisms necessary for passing data between instances of an application or different applications in a 'protected mode' environment.
Microsoft Windows has but two pasteboards, one for general use and one managed internally by the system for drag and drop operations.
With OS X the number is unlimited.
Several OS X pasteboards are predefined for general use; applications can thereafter create pasteboards of their own.
No such facility exists on Microsoft Windows.
The ruling class in the pasteboard context is NSPasteboard. NSPasteboard works together with the pasteboard server pbs located in CoreServices and booted on every login.
NSPasteboard has the class method +pasteboardWithName: which returns a pointer to a pasteboard object with the specified name. The default names are the following.
|NSDragPasteboard||Used for drag and drop|
|NSFindPasteboard||Stores the current find string|
|NSGeneralPasteboard||Used for copy, cut, paste|
|NSRulerPasteboard||Stores paragraph formatting|
Noteworthy is that NSDragPasteboard is directly accessible, meaning drag and drop operations work a lot easier on OS X than they do on Windows.
Also worthy of mention is NSFindPasteboard, something people on Windows wouldn't be at all familiar with: using special APIs (methods) all applications can at all times continue user searches with the last string used. Often the simple keyboard shortcuts ⌘D (search previous) and ⌘G (search next) are all that is needed. ⌘E takes the current selection and puts it on the find pasteboard for the next operation.
As needed, applications can also create their own pasteboards by calling the class method +pasteboardWithUniqueName:. When the pasteboard is no longer needed, the instance method -releaseGlobally is called.
Pasteboard Data Types
OS X admits of a plethora of predefined pasteboard data types.
|NSColorPboardType||Color Unicode information|
|NSFileContentsPboardType||File Unicode contents|
|NSFilenamesPboardType||Unicode list of filenames|
|NSHTMLPboardType||HTML Unicode data|
|NSPDFPboardType||PDF Unicode data|
|NSPICTPboardType||PICT Unicode data|
|NSPostScriptPboardType||EPS Unicode data|
|NSRTFDPboardType||RTFD Unicode data|
|NSRTFPboardType||RTF Unicode data|
|NSTabularTextPboardType||TSV Unicode data|
|NSTIFFPboardType||TIFF Unicode data|
|NSURLPboardType||URL Unicode data|
To find out what objects can be sent for any given type, the class method +typesFilterableTo: can be used. The return is an array of all types that can be turned into the target type.
Using a Pasteboard
Putting data on an OS X pasteboard is eminently straightforward: first the client tells the pasteboard what data types are to be expected, and then the client actually sends the data.
NSPasteboard *pb = [NSPasteboard pasteboardWithName:NSGeneralPasteboard];
[NSArray arrayWithObject:NSStringPboardType] owner:self];
[pb setString:myString forType:NSStringPboardType];
Getting data off a pasteboard is just as easy.
NSString *tmp = [[NSPasteboard pasteboardWithName:NSGeneralPasteboard]
Drag and Drop
As drag and drop are simply a fancy way of using a pasteboard, implementation is again straightforward. Client and server are expected to conform to the NSDraggingDestination and NSDraggingSource informal protocols respectively. The client can control what happens when the drag enters its territory, what operations are permitted, as can the server.
The server can also create a drag image for use in the operation.
Many of the more sophisticated classes in OS X come with built in support for drag and drop.
As described elsewhere at this site, OS X services are 'a clipboard fantasy come true'. The Cocoa AppKit uses the pasteboard server to move data seamlessly between applications, offering filters and services on each application's menu.
OS X services are the type of feature that are not even thinkable on a platform such as Windows where the number of available pasteboards is severely limited (1) and the user flexibility is nil.
OS X pasteboard architecture is so well thought out that implementing services is mostly a matter of configuration only: everything else is set up by the system at runtime.