views:

57

answers:

3

The documentation for NSPasteboard's -types reads:

Return Value

An array of NSString objects containing the union of the types of data declared for all the pasteboard items on the receiver. The returned types are listed in the order they were declared.

Despite this, I have an NSPasteboard with only one NSPasteboardItem and [pboard types] returns more types than [item types] returns. Can anyone explain this?

Code

Here's some code that evidences the problem:

- (BOOL)performDragOperation:(id <NSDraggingInfo>)sender {
    NSPasteboard *pboard = [sender draggingPasteboard];

    // Prove that there's only one item
    if ([[pboard pasteboardItems] count] > 1)
        return NO;

    for (NSString* type in [pboard types])
        NSLog(@"Pasteboard type: %@", type);

    NSPasteboardItem* item = [[pboard pasteboardItems] objectAtIndex:0];

    for (NSString* type in [item types])
        NSLog(@"Item type: %@", type);

    return NO; // Ignore for example
}

Output

When I drag a link from Safari I get the following output:

Pasteboard type: dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k
Pasteboard type: WebURLsWithTitlesPboardType
Pasteboard type: dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
Pasteboard type: Apple URL pasteboard type
Pasteboard type: public.url
Pasteboard type: CorePasteboardFlavorType 0x75726C20
Pasteboard type: public.url-name
Pasteboard type: CorePasteboardFlavorType 0x75726C6E
Pasteboard type: public.utf8-plain-text
Pasteboard type: NSStringPboardType
Item type: dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k
Item type: dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
Item type: public.url
Item type: public.url-name
Item type: public.utf8-plain-text

Wild Speculation

It looks like [item types] is basically showing the same types as [pboard types], but only the UTI versions. And since [pboard types] seems to be interleaving the UTI types with the corresponding other type (?) of types, it's basically a mapping...

I could probably ignore this issue by simply using the UTI for the data format I want, but I'm looking for WebURLsWithTitlesPboardType (corresponding to dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k), and I'm wary of those dyn.(...) UTIs. Sounds like something that shouldn't be hardcoded.

Is there a reliable way of transforming WebURLsWithTitlesPboardType-style identifiers into UTIs? I don't trust the approach of actually using [pboard types] as a mapping...

+1  A: 

You might try using the UTTypeCreatePreferredIdentifierForTag() function to see if that will retrieve the UTI corresponding to that pboard type. You would pass kUTTagClassNSPboardType for the tagClass argument, and the pboard type as the tag (the third argument can be NULL). The docs imply that this will probably return a dynamic UTI, since non is explicitly declared anywhere for for WebURLsWithTitlesPboardType. What's not clear is whether it will reuse the same one it generated for use on the pasteboard, or if it just makes a new one each time.

Brian Webster
Thanks for the idea. Unfortunately `UTTypeCreatePreferredIdentifierForTag` doesn't return the same dynamic UTI each time.If *does* return the same UTI if I call it twice and pass it the same string, but this returned dynamic UTI doesn't match the one for `WebURLsWithTitlesPboardType`, even though I know the input strings are the same. I even tried multiple copies of the same string (i.e. two strings `isEqualToString:` but not `==`), and even those return matching identifiers. So I guess there's some other element of program state included in the dynamic UTI generation.
camdez
My belief is that `UTTypeCreatePreferredIdentifierForTag` only knows how to convert UTIs that have been declared, and perhaps identifiers that have been used previously in the same process.
camdez
Actually, I take it all back...if you do `UTTypeCreatePreferredIdentifierForTag(kUTTagClassNSPboardType, CFSTR("WebURLsWithTitlesPboardType"), kUTTypeData)`, it returns the right dynamic UTI. Oddly, you must pass `kUTTypeData` (not `NULL`) for the final parameter or you'll get a different UTI.
camdez
A: 

It doesn't because it has to maintain backwards compatibility with earlier versions of Mac OS X, none of which are multiple-item-aware.

If you're developing for Mac OS X 10.6 or later only, you can completely disregard the -types method and focus on the pasteboard's items directly. If you're targetting Mac OS X 10.5 or earlier, you'll need to either use the legacy methods (including -types) or check for the existence of the newer methods and types before using them (via weak linking and judicious use of NSClassFromString() and -respondsToSelector:.)

Jonathan Grynspan
I'm not sure I follow the logic of your first statement. I could understand why the `[pboard types]` method would need to return the same list of types as `[[[pboard pasteboardItems] objectAtIndex:0] types]` in order to maintain backwards compatibility (or even the *intersection* of the types of the items), but that's not what's happening here. The `NSPasteboard` is advertising types none of the `NSPasteboardItem` objects report. Or, at least, advertising them in different ways.
camdez
Basically, the format of the pasteboard's contents changed in 10.6, but only if you use the new APIs. To maintain compatibility at the software and API levels with older software, the old format is still used. The difference in formats is that the new one is essentially a UTI-only club, while the old one is an anything-goes speakeasy.
Jonathan Grynspan
I think you are theoretically spot-on, but then wouldn't you agree that Apple's docs would have to be faulty regarding `NSPasteboard`'s `-types` (the line I quoted in the original post)?Imagine a pasteboard with two items. The first item has `-types` A and B. The second has `-types` B and C. The pasteboard (per docs) should report `-types` A, B, and C (the *union* of the types).A user expecting pre-10.6 behavior then might request data from the pasteboard in format C, but it wouldn't be available, despite being advertised, since the pasteboard would try to get it from the first item.
camdez
In theory that'd be ideal, but pragmatism wins out. Programmers accessing the contents of the `NSPasteboard` instance rather than the `NSPasteboardItem` instances are assumed to be using the old API with its old requirements and old data types. The transition to the new API has been a bit shaky (the replacement for `NSFilesPromisePboardType`, for example is thoroughly undocumented.)
Jonathan Grynspan
A: 

I'm convinced that documentation for NSPasteboard's -types is actually faulty. The correct documentation should be something like:

An array of NSString objects containing the union of the types of data declared for all the pasteboard items on the receiver, with the addition of old-style, non-UTI type identifiers.

If you're targeting OS X 10.6+, you should be able to completely disregard NSPasteboard's -types and focus only on each NSPasteboardItem's -types, but this requires working exclusively with UTIs.

To convert a non-UTI type identifier to a UTI you need to use the UTTypeCreatePreferredIdentifierForTag() function; you also need to know what kind of identifier you already have (kUTTagClassFilenameExtension, kUTTagClassMIMEType, kUTTagClassNSPboardType or kUTTagClassOSType). This type is the first argument to the function. The second is the identifier itself (as a CFStringRef). While the documentation suggests that it's OK to pass NULL for the third argument, it seems to be important to actually pass kUTTypeData when generating these dynamic UTIs.

For example, to get the (dynamic) UTI for data with the old-style identifier "WebURLsWithTitlesPboardType":

CFStringRef webURLsWithTitlesUTI = UTTypeCreatePreferredIdentifierForTag(kUTTagClassNSPboardType, CFSTR("WebURLsWithTitlesPboardType"), kUTTypeData);
camdez