On Apr 25, 2015, at 10:25 PM, Graham Cox <graham....@bigpond.com> wrote:
> Thanks Ken, that’s helpful.
You're welcome.
> … I see the following on the pasteboard:
>
> drag content: (
>
> "dyn.ah62d4rv4gu8yc6durvwwa3xmrvw1gkdusm1044pxqyuha2pxsvw0e55bsmwca7d3sbwu",
> "Apple files promise pasteboard type",
> "com.apple.pasteboard.promised-file-content-type",
> "com.apple.pasteboard.promised-file-url",
> "dyn.ah62d4rv4gu8y6y4usm1044pxqzb085xyqz1hk64uqm10c6xenv61a3k",
> NSPromiseContentsPboardType,
> "com.apple.UXCollectionView.draggingitem",
> "com.apple.UXCollectionView.sourcepointer",
> "dyn.ah62d4rv4gu8ywyc2nbu1g7dfqm10c6xekr1067dwr70g23pw",
> IPXPasteboardController,
> “com.apple.PhotoPrintProduct.photoUUID”
> )
>
>
> So it looks as if the URL of the image(s) that I’m dragging are promised. …
> The headers don’t have any info about what do to if the URL is only promised
> - I had thought that from the receiver’s point of view that was irrelevant
> and transparent, and the promise would be fulfilled when the receiver asked
> for the URLs, but that’s clearly not happening.
Promised files are strange and problematic in a couple of ways. First, the
destination specifies where the files are to be created. The source only
supplies file names (no path).
Second, even once the destination provides the URL of the directory in which
the files should be created and the source replies with the names, you can't
rely on the files having been created. The source is actually encouraged to
defer the creation of the files if it may be slow, and there's no way for the
destination to know when that process has completed. In the case of the
Finder, that's fine. It just tells the source the URL of the folder on which
the user dropped the files and washes its hands of the matter. When the source
eventually creates the files, that will be just like any other file creation
that the Finder deals with all the time. In most cases, other apps don't have
that luxury. They want to incorporate the dropped files into their app's data
in an immediate way.
Both of these issues prevent the pasteboard API from automatically and
transparently converting file promises to URLs.
Apple's woefully out-of-date Drag and Drop Programming Topics document has this
code snippet in its Dragging Files article, under Dragging File Promises:
NSURL *dropLocation; // Assume this exists
- (BOOL)performDragOperation:(id <NSDraggingInfo>)sender
{
NSPasteboard *pboard = [sender draggingPasteboard];
if ( [[pboard types] containsObject:NSFilesPromisePboardType] ) {
NSArray *filenames = [sender
namesOfPromisedFilesDroppedAtDestination:dropLocation];
// Perform operation using the files’ names, but without the
// files actually existing yet
}
return YES;
}
I expect that that's still the recommend approach for file promises even though
it doesn't use the modern API. Note the comment about the files not actually
existing yet. Whether or not you'll be able to accept file promises, given the
above limitations, depends on the specific needs of your app.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
