Total Commander

Existing feature to postpone questions tries to process items that don't require confirmations first and then ask for confirmations.

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)

However when question dialog is shown, TC can only wait. It would be nice to improve this.

0. Main copy/move/etc_operation thread processes objects that may be processed and in case of a question adds it to a question queue, at the same time background thread asks questions in a loop from this queue. So, when TC shows a confirmation, it continues processing items that may be processed instead of waiting for user's answer. Such question thread won't slow system down because it will wait most of time.
1. Copy dialog may show an icon when answer queue is not empty, click on that icon may show first unanswered question, also it may show a number of items that wait for confirmations (it is not a number of confirmations which is unknown because 'yes to all' answers exist). Question dialog should be modal to operation progress window and have a button 'postpone' (it may be called again using an icon if user have to go and can't answer more).
2. Every item in a queue should contain a set of flags for confirmations (read only, long path, already exists, access denied etc). When user answers 'yes to all' for some type of confirmation, further items with only that confirmation may be processed w/o questions.
3. When operation thread reaches end of queue, it repeats queue. If some answers were given during first pass, queue should be repeated immediately, then if no answers were given during a pass, TC should wait for answers before next pass. In case of a single question only that item should be processed, in case of 'yes to all/no to all' answer next pass should be performed in order to process/skip items with such flags.
4. Perhaps questions window should contain buttons 'next/previous answer' and 'next/previous answer type' (or these may be done with shift+click or context menu).

Where exactly do you see the problem in the current solution? Whenever a dialog is shown at the end of the process there should be no other actions planned which require no interaction.

For me it's currently not clear for the user when exactly it makes sense to stand and drink a coffee. Is it really always just five seconds? That would not make much sense. The simple case where the enumeration of the stuff to copy takes a long time (> 5 seconds) and then the main question occurs 'Can I write to the target' shows that just a static timespan doesn't make sense. So my idea to check this first and then continue with the asks me later procedure.

Whenever a dialog is shown at the end of the process there should be no other actions planned which require no interaction.

For me it's currently not clear for the user when exactly it makes sense to stand and drink a coffee. Is it really always just five seconds? That would not make much sense.

That's it. If you want to quickly start process and go for a coffee, you don't want to answer questions within first 5 seconds, and you want to be sure that TC won't wait for an answer when you return. Separare asking thread for questions would solve both problems. All that may be copied is copied while TC waits for an answer in background, and also you can answer questions while files are copied w/o waiting for processing next file.

So my idea to check this first and then continue with the asks me later procedure.

I think your idea is more related to enumeration than to postponing questions. W/o enumeration TC would warn about read-only destination immediately.

I think your idea is more related to enumeration than to postponing questions. W/o enumeration TC would warn about read-only destination immediately.

When this check would be performed immediately the related question would be displayed immediately. When it has been answered there would be no need to wait five seconds or finishing enumeration. All other questions can be displayed at the end.

BTW I see 'target is read-only' error very rare, much more TC warns about deleting read-only or hidden files, overwriting files, hidden or system ones, and maybe about long paths...

2MVV

BTW I see 'target is read-only' error very rare, much more TC warns about deleting read-only or hidden files, overwriting files, hidden or system ones, and maybe about long paths...

Well I would consider this a bug that should be reported if it happens after the five seconds.

I see 'target is read-only' error very rare

It may happen when overwrite was confirmed within the first 5 seconds, and there is an actual write error somewhere in the middle of the file. For example, when a database file is record-locked just somewhere in the middle.