Page 1 of 1

F5 copy, questions asked at end - custom wait time

Posted: 2013-10-04, 20:47 UTC
by PhoenixK
About the feature: 01.09.13 Added: F5 copy, questions asked at end: If there is a dialog within the first 5 seconds, show it instead of postponing it (the user should still be there) - was 0.5 seconds in beta 1 (32/64)
Is there any chance to make this customizable? In fact, I prefer the lower or 0 wait time instead of the 5s - but this is only my preference.

Posted: 2013-10-05, 10:09 UTC
by MVV
I agree that it is useful to lower it. If I want to start copy task and go away of PC, I don't want to sit and answer a bunch of questions until first 5-sec pause.

Posted: 2013-10-07, 09:54 UTC
by ghisler(Author)
I don't want to make this configurable because it could have unpredictable results. But I'm open to suggestions how short I should make it. 0 is not an option, because it's not catching the situation where ALL files have to be overwritten. It makes no sense to try all files and then again, you don't gain anything. To the contrary, you start the operation, TC is trying 10000 files in vain, and when you come back, nothing has been copied at all.

Posted: 2013-10-07, 10:45 UTC
by PhoenixK
ghisler(Author) wrote:I don't want to make this configurable because it could have unpredictable results. But I'm open to suggestions how short I should make it. 0 is not an option, because it's not catching the situation where ALL files have to be overwritten. It makes no sense to try all files and then again, you don't gain anything. To the contrary, you start the operation, TC is trying 10000 files in vain, and when you come back, nothing has been copied at all.
Thanks for the explanation. :)
As I wrote I prefer the lower times, but I think it is depend on the usage. That's why I suggested the customizable wait time.

Posted: 2013-10-07, 11:51 UTC
by MVV
I think 5 seconds would be enough together with:
1. 'Postpone' button in some confirmation dialog.
2. Some indication in main operation dialog that TC has entered postpone mode.

Posted: 2013-10-07, 12:37 UTC
by PhoenixK
MVV wrote:I think 5 seconds would be enough together with:
1. 'Postpone' button in some confirmation dialog.
2. Some indication in main operation dialog that TC has entered postpone mode.
The first suggestion would be great!

Posted: 2013-10-07, 15:54 UTC
by MVV
Another idea (probably even better): when TC shows confirmation dialog, it waits for e.g. 1 minute and then postpones that confirmation and all the rest. So if user left PC he will see that operation is done and some confirmations are left unprocessed.

Perhaps ideal solution: show confirmations queue in a separate thread so TC can continue with operation while user answers questions, so if there are unanswered confirmations, one of them is on the screen.

However some confirmations may postpone multiple files! E.g. if 'remove read-only' confirmation is postponed, it must postpone deletion of all read-only files. And, if user answers one of them 'all', flag 'remove: all' should be set and so rest 'remove read-only' confirmations may be processed.

Of course, there are bad sides too. E.g. I see first confirmation and understand that I do bad thing. :roll: But in case of foreground confirmations no more files will be processed... So it is better to turn postpone mode manually so user knows what he doing.

Posted: 2013-10-08, 08:11 UTC
by PhoenixK
MVV wrote:Another idea (probably even better): when TC shows confirmation dialog, it waits for e.g. 1 minute and then postpones that confirmation and all the rest. So if user left PC he will see that operation is done and some confirmations are left unprocessed.

Perhaps ideal solution: show confirmations queue in a separate thread so TC can continue with operation while user answers questions, so if there are unanswered confirmations, one of them is on the screen.

However some confirmations may postpone multiple files! E.g. if 'remove read-only' confirmation is postponed, it must postpone deletion of all read-only files. And, if user answers one of them 'all', flag 'remove: all' should be set and so rest 'remove read-only' confirmations may be processed.

Of course, there are bad sides too. E.g. I see first confirmation and understand that I do bad thing. :roll: But in case of foreground confirmations no more files will be processed... So it is better to turn postpone mode manually so user knows what he doing.
I don't think it should not be more complex, because many people are simply lazy, so one more click will make this function unused. That's why I recommended to make it configurable via the .ini and keep the behaviour as is now.
ghisler(Author) wrote:I don't want to make this configurable because it could have unpredictable results. But I'm open to suggestions how short I should make it. 0 is not an option, because it's not catching the situation where ALL files have to be overwritten. It makes no sense to try all files and then again, you don't gain anything. To the contrary, you start the operation, TC is trying 10000 files in vain, and when you come back, nothing has been copied at all.
I prefer 1 or 2 seconds...