Merge normal and background copy dialogs

[Lefteous]

Currently we have a normal modal copy dialog and a background copy dialog. Why would anyone copy in foreground instead of copying in the background?
Because the background dialog doesn't offers the same level of information as the foreground dialog. Why not take the best of both worlds and drop foreground copy?

Current foreground dialog:
- Quite large dialog
- Caption "Total Commander" in normal window state
- Taskbar item caption displays percent, speed and time left when minimized
- Copy speed and total time left
- Current file progress bar
- Total progress bar
- Current file source and target as full path
- background button

Current background dialog:
- Quite small dialog
- Caption displays always percent and filename without path (updated only occasionally)
- Current filename or speed and total time left for larger files.
- Total progress bar
- Start/Stop button

So my suggestion for an improved background dialog is basically to use the current foreground copy dialog as a template and apply just a few changes:
- The background button would be removed and a Start/stop button would be added.
- When minimizing the new dialog only the the dialog is minimized not TC itself.

[fenix_productions]

Nice ideas but for me background copy dialog represents the simplicity itself. The only think I would miss is From/To information.

PS "One picture means thousand words". So maybe visualize your ideas using tools like this or that

[StatusQuo]

I actually never use background copy now,

Because the background dialog doesn't offers the same level of information as the foreground dialog.

Yes, mainly.
Also it is more difficult to handle via keyboard, AFAIR from last tests.

Other benefits of foreground copy:
- If you abort a copy process, you don't have to navigate into the dirs again for checking/restarting - TC is still there.
- You easy notice dialogs, because they are modal to the main window. In background one may overlook them.
- You have less chance to create a mess when using foreground copy, because you can't use a copy destination as source for another, unless the copying has finished (without using a second TC instance).

So, I wouldn't completely drop foreground copy (we already have AlwaysCopyInBackground for this),
but Support for improving background copy.
If the interface of background copy gets better, maybe I'd give it another try.

[Lefteous]

One picture means thousand words". So maybe visualize your ideas using tools like this or that

Well I could do that but I thought it's not difficult to imagine the current foreground copy dialog were the "Background" button is labeled "Pause" and behaves like a pause button.

If you abort a copy process, you don't have to navigate into the dirs again for checking/restarting - TC is still there.

This is a valid point. Maybe it would be a good idea to provide navigating to the directories at the end of a copy process if something went wrong.

You easy notice dialogs, because they are modal to the main window. In background one may overlook them.

I think you can notice them if you want to notice them. Otherwise they don't hurt but modal dialogs hurt.

You have less chance to create a mess when using foreground copy, because you can't use a copy destination as source for another, unless the copying has finished

This is something which could be prevented internally by the program. There is no need to let the user handle this.

[Postkutscher]

Support++

[d]

hello.
"support++".
and i had seen this in krusader.

[fenix_productions]

For view only: Krusader's copy dialog.

[Flint]

Nice idea in general, but may appear inconvenient when implemented. Some thoughts:

1. Large background window does not look good for me. I'm too accustomed to small, cute background copy dialogs. Idea: this could be solved by adding possibility to expand/contract this dialog between full and small modes (with option to run in full/small mode by default or to remember last used mode). Just like e.g. in Media Player Classic: Standard and Minimal view modes.

2. Sometimes it is psychologically important to know that the operation is being performed. When I press OK and immediately gets the dialog disappeared, I think (instinctively) that the operation has already finished. My TC window is always maximized, and I don't see background windows without switching to them. So, I personally use foreground dialogs not only because of lack of information in the background ones, but also to make sure, the operation is completed before I continue to do something (yes, yes, I know it is possible to look and wait while background dialog closes, but I would need to switch to it, and with foreground I do not need to switch anywhere).

[m^2]

Support++

2. Sometimes it is psychologically important to know that the operation is being performed. When I press OK and immediately gets the dialog disappeared, I think (instinctively) that the operation has already finished. My TC window is always maximized, and I don't see background windows without switching to them. So, I personally use foreground dialogs not only because of lack of information in the background ones, but also to make sure, the operation is completed before I continue to do something (yes, yes, I know it is possible to look and wait while background dialog closes, but I would need to switch to it, and with foreground I do not need to switch anywhere).

How about foreground, but modeless?

[Flint]

How about foreground, but modeless?

Hm... What about aligning all background dialogs at the top left?

[m^2]

How about foreground, but modeless?

Hm... What about aligning all background dialogs at the top left?

They would cover buttonbar. Bottom right? (a few pixels from the edge not to cover scrollbar)

[Flint]

m^2
Any placement will cover something. I meant that moving the dialog anywhere would look a bit strange, but not moving it would make using multiple background dialogs inconvenient (all at the same screen position, over each other). I can't see any good solution for now...

[JohnFredC]

Instead of dialogs... how about displaying the relevant lists, status, and controls in a tab?

Another approach: Speed Commander uses a tabbed sub-panel of the right file panel to show ongoing activity groups. There is a tab for each action initiated, and a movable splitter between the sub-panel and the parent (containing) file panel.