Re: Drag and Drop from Photos
Re: Drag and Drop from Photos
- Subject: Re: Drag and Drop from Photos
- From: Ken Thomases <email@hidden>
- Date: Sat, 25 Apr 2015 23:33:10 -0500
On Apr 25, 2015, at 10:25 PM, Graham Cox <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden