dropping to the Finder
ambassador at fourthworld.com
Fri Feb 26 15:27:39 CST 2010
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
> 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:
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
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....
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
More information about the use-livecode