Brian,
I've noticed in 3.50 that the file send/receive dialog box seems to stick around a few more seconds after a successful send/receive than it used to. Is there any particular reason why?
It's just a few seconds, but I find having to wait before I can start typing again to be frustrating.
What's the deal?
BTW - I can't wait for SFTP - keep up the good work!
Thanks! - Scott
[size=1][ December 16, 2004, 04:41 PM: Message edited by: Brian T. Pence ][/size]
Scott,
Brian and I had a battle regarding this during the beta-cycle... I managed to knock a second off the delay, but Brian won the war...
Cheers,
/msa
[size=1][ December 15, 2004, 04:34 AM: Message edited by: Mattias Sandstrom ][/size]
So what's the reasoning behind having a (what seems to be artificial) delay? Older versions seemed to be just fine to me...
- Scott
The reason for the delay is so you can see the final transfer status. What was happening was that when the transfer completed, you couldn't tell what transferred successfully and what errored out because the screen would disappear so quickly.
(Perhaps I should rest my case here, but... 🙂 )
Maybe having the dialogue to stick around when an error has been detected and vanish at a blink of an eye if the transfer was successful... ?
Cheers,
/msa
(Perhaps I should rest my case here, but... 🙂 )
Maybe having the dialogue to stick around when an error has been detected and vanish at a blink of an eye if the transfer was successful... ?
Cheers,
/msa
I've been contemplating a number of design changes to the zmodem window. One problem that remains and has not been addressed is the situation where some files succeed and others fail (perhaps already exist). At the end of the transfer, there's no way to tell for sure what happened.
The types of things I've thought of adding are things like a count of the total files attempted, and counts of the successful/unsuccessful files.
Additionally, I'll probably replace the status line with a scrollable status window so you can go back and see that file 1 and file 4 both failed because they already exist, etc...
And, instead of tweaking the delays around again, I'll probably leave the window up and allow the user to close it at will. There will be an 'ok' button in addition to the 'cancel' button. During transfer, the 'ok' will be greyed out and your only option is to cancel the transfer that is in progress. Upon completion, you'll have to press the 'ok' button (or the cancel button, at this point it doesn't matter) to close the window.
This allows the user to take as much time as is necessary to get information from the status window about all of the transfers that took place, while still allowing you to break out of the window instantly if you care to do so.
How's that sound?
Brian
How 'bout a "close transfer window after send" option on either the transfer or global options properties?
Brian,
you do have a point when it comes to multiple files transferred, especially with small files that are quickly uploaded to the server. rz on most *NIX systems also don't allow you to clobber your files per default causing the upload to be (least to say) confused.
Sounds great to be able to dismiss the transfer-result window with either Enter or ESC. Personally, I hate seing the prompt return and not being able to go back to the terminal window... Speed-addict, I know... 🙂
/msa
FWIW: I did a small script, "rz-smart.sh" that copies the current file and clobbers the new file that is being uploaded. For this to work, change your setting for the transfer command to use this instead of simply "rz".
#!/bin/bash
if [ -z $1 ]; then
echo "Usage: $0 filename"
exit 1;
fi
if [ -e "$1.old" ]; then
rm $1.old
fi
if [ -e $1 ]; then
mv $1 $1.old
fi
/usr/bin/rz -y
This script moves the file with the same name and then starts the upload. rz has an option similar with this, but then the NEW file will have a number appended...
No warranties implied for this script, but it helps me 🙂
/msa
