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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
