|
|
Since the earliest days of Squeak, the FileList has been a great
utility to fall back on, either when nothing else works, or when you
don't have other software to do the job. Until recently, it was
possible to browse to *any* file on any directory *or server*, copy
there, browse to another directory, make a file, paste and save. It
was consistent and it worked.
Now if you do this with a binary file, as others have observed, the
thing that gets stored bears almost no resemblance to the original
file, even though the UI actions boil down to copy-paste.
I was going to complain about this (I have been using an old Squeak
for a long time for just this reason) except that, using
drag-and-drop, the right thing happens, and it's actually easier to
do...
...but only in *some cases*. What is needed is a little work on file
drag-and-drop for the case of copying between different devices or
servers (ie between separate file systems). Specifically the
following three fixes would, I believe, restore proper operation in
this case...
1. Recognize this case from the fact that the two
directories do not have a common root.
2. Convert simple drags from 'move' to 'copy' in this case, and
3. Do the right thing with file names and directories.
Naturally the destination name
should be the local name of the source plus the path name of
the target directory.
The fact that the FileList can do FTP between servers makes it a very
powerful tool if other things are working right. I apologize for not
having time to do this myself right now, but I think it would be a
noble service for our shiny new Squeak 3.9 if file drag-and-drop
could be made to work properly in the FileList.
- Dan
PS: To anyone working on this, you will notice considerable delays
when switching windows open on different servers, and it helps to
have a Transcript open to understand what is going on. It would
probably be nice to figure how to reduce these delays or put up a
little informer so that normal users will understand that things are
happening behind the scene. I think the best solution would be to
make re-opening the connection a lazy operation, rather than eagerly
on window wake-up, but we shouldn't let that get in the way of the
relatively simple fixes above.
|
Locked
