dropping to the Finder

[Richard Gaskin]

Jim Ault wrote:

> On Feb 26, 2010, at 10:22 AM, Richard Gaskin wrote:
>
>> I've used a few like that myself (GoLive and FileZilla work that
>> way). It may be just a Mac convention that supports this so well,
>> but I use Interarchy for FTP and it does a wonderful job of behaving
>> Finder-like:  I just drag the file name from its listing into the
>> Finder and it starts the download.  Beautiful, simple, lets the user
>> interact with their files directly in the context they're most
>> familiar with.
>
> This is true Richard, but the Interarchy drag-drop interface drops
> data that is recognized by the accepting app, such as the Finder, that
> matches what the Finder is expecting.  In the case of moving files, it
> would be the full path and it triggers the 'move file command' if on
> the same drive, and 'copy file command' if on different volumes or
> servers.
>
> You task is more complex.  You are saying that you want your app to
> receive a report back from the Finder that contains the location the
> user chose.  This is not the normal semaphore unless you use
> AppleScripting (which is Mac only of course).  Beyond that, you want
> is to do work that the destination app may not understand, such as
> build a text file and save it.

Actually, as an FTP app Interarchy is facing the same issue I am:  there 
is no file to move at the time the drop is made.  There's not even any 
data; it still needs to be downloaded.

If there's a simpler way to accomplish this I'd love to find it, but it 
would appear that Interarchy (and the many other FTP tools that use 
drag-and-drop) are getting info from the Finder to know which file to 
download their data into.

I don't know specifically what Interarchy is doing what it's doing under 
the hood, but I was able to turn up some Cocoa info on this which I 
included in my RQCC request:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=8634>

 From my brief reading in the Cocoa specs, it seems the 
namesOfPromisedFilesDroppedAtDestination part of the drop record 
returned to the drag source app contains the paths to the files the 
receiver promises to create.


> As far as file listings, the [ls] command can be 'piped' to a text
> file on the hard drive or an environmental memory variable for access
> by your app.  The [ls] command will produce a list, and if you use
> Google, I am sure you can locate a directory walk script out there
> somewhere.

Traversing all files would take too long, but fortunately we only need 
to know about the folders that are open, and their subfolders.

Just to see how this might play out I ran a little test, with favorable 
results: getting "the files" from a dozen random folders containing a 
total of about 1200 files takes only 12 milliseconds on my 
three-year-old Mac (2.1GHz).

So even if it took 10 times as long that's still about a tenth of a 
second, plenty of time since we're responding to a user action.

Now the trick is to find a quick way to determine which folders are open.

As much as I appreciate Bob's posting the list of command line calls for 
OS X (thanks Bob) I didn't see one there that gives me a list of open 
folders - and that means AppleScript, and that means MUCH slower 
performance.  And it still doesn't provide a solution for Win and Linux. :(


> My take would be that the user defines the destination by drag-drop to
> your app, then you check permissions, and go forth.

That's what I have in place now as a workaround, but it's quite a drag 
to have to sacrifice consistent interactions:  we let folks upload via 
drag-and-drop, but make them go through that gawdawful file picker 
dialog to download, while other products do it so much more gracefully.

There must be a way....

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv