Send Copy/Move/Delete to the background

[Stoeck]

In the TotalCommander, I found it very useful to have a "background" button on the copy/move/delete dialog, where I can send the process to the background, even if it is currently ongoing.

[KNUT]

In the TotalCommander, I found it very useful to have a "background" button on the copy/move/delete dialog, where I can send the process to the background, even if it is currently ongoing.

Same in Servant Salamander: While copy / move /... is in progress, use the "Minimize" button to send the copy-window to the taskbar

[Jan Rysavy]

Or click the Servant Salamander main window to bring it up.
Or press the Alt+Tab to activate the main window.

(Copy/Move/Delete operations runs always in background from version 2.5.)

[JohnFredC]

I know about the minimize button but only by "accident". The first few times I used it I kept checking to see if, indeed, copy/move was still happening.

In Windows, the minimize button means "minimize"...

So, for me (and for new users, too!) an additional "background" button in the dialog would be good. Such a button would "advertise" the functionality instead of keeping the user guessing.

Yes that introduces redundancy into the interface, but I am a proponent of control redundancy in GUIs.

[Jan Rysavy]

There are several non-modal windows in Servant Salamander (Progress windows, Find windows, Viewers, Properties dialog boxes, some plugins windows). Shoud we add the "Background" button to each of them? I don't think it is a good idea.

The "Minimize" button does exactly what it says and what is standard in the Microsoft Windows.

[bebe]

I agree with Jan, "background" is not a good idea as this is not what the button does. The dialog is non-modal, if you don't want to minimize, just click on the main window to focus it (and put the copy dialog to background).

[JohnFredC]

Should we add the "background" button to each of them?

In my opinion no... only in those circumstances where it isn't explicit what happens while the dialog is minimized. I think of the copy/move dialog as being such a case... should the user just assume that background processing occurs when the dialog is minimized?

It's better to tell him/remind him IMHO.

[Jan Rysavy]

In my opinion no... only in those circumstances where it isn't explicit what happens while the dialog is minimized. I think of the copy/move dialog as being such a case... should the user just assume that background processing occurs when the dialog is minimized?

It's better to tell him/remind him IMHO.

What about the Find window while search is in progress?

What about the Properties dialog box (standard Windows window) opened for large directory, where Size/Size on disk/Contains fields are computed on background?

It looks like the same problem to me.

Maybe Microsoft will introduce some way how to distinguish modal and non-modal windows sometime...

[JohnFredC]

Find window yes/desireable, but not necessary. Properties window, not necessary.

The criteria should be if there could be consequences for the user if they did not know/remember that something was proceeding in the background when a dialog was minimized. Not all software continues "in the background" the way Salamander does. Copy/Move background processing already exposes the possibility of the user's "knowledge" of the file system getting out of synchronization with the facts. Forcing the user to click a "background" button is just a little subliminal reminder.

Of course, if there is no foreground mode at all(!), the background button doesn't make sense.

(Copy/Move/Delete operations runs always in background from version 2.5.)

What if I want the copy to proceed in the foreground? My off-hand assumption would have been foreground as default.


Perhaps this is an issue of differing design philosophies. For years I tried to minimize the control surfaces of the software I develop, stacking functionality into the fewest buttons/controls I could. My users told me they liked more controls better than fewer controls, so I shifted my emphasis to exposing everything and concentrated on working to make the control layouts efficient and clean despite the extra button or two.

[Petr Solin]

I think that background processing is normal (and expected) in multitasking environment like Windows. So I think that Copy/Move defaultly on background is the best what we could do. If you want to wait until Copy/Move ends, you can, it's your own choise.

Even if we make it "on foreground", so blocking Salamander's main window, you still could switch to another running application (e.g. another Salamander), so it would not protect you from anything.

[JohnFredC]

you still could switch to another running application

This is unfortunately only too true.

I recently had an issue when using two different file managers simultaneously (not Salamander) performing unrelated copy activities in the background over a wireless network prone to intermittent (and short term) disconnects/reconnects. Except one activity was inadvertently a MOVE, not a copy! I ended up with corrupted files on the destination and no originals on the source, but also no error messages. It had to be about "background" politics.

I know it would be better to stick with one file manager for everything (Salamander certainly would be a candidate) because one would expect that a single file manager would "play nice" with itself better than with another program. Unfortunately, no one file manager has everything I need.

[Petr Solin]

Error reporting does not depend on foreground/background processing (at least in Salamander, it's 80% of source code ). I think that this your problem is caused by error-ignoring software (not unusual even among filemanagers, they save 80% of work by this) or by operating system/driver error (system confirms read/write operation to be OK, but it was not OK, it has failed - it reads/writes other data than expected).

[Jan Rysavy]

I recently had an issue when using two different file managers simultaneously (not Salamander)

I think that this your problem is caused by error-ignoring software (not unusual even among filemanagers, they save 80% of work by this)

What file manager are you both talking about?
Now you know why we are so slow -- we are implementing the error handling code all the time

[jis]

Now you know why we are so slow -- we are implementing the error handling code all the time

Thank you for this, Salamander is one of the most stable applications which I have ever seen!

[JohnFredC]

I'll just say the two commanders I was using at the time weren't either Salamander or another well known Swiss tool, neither of which has ever EVER damaged a file in my many years of use of both.

After those two commanders, you takes your pick.

When a particular gui feature set of a filer is overwhelmingly compelling for one's own way of working, one is tempted to switch tools. I've spent some money chasing features. Doesn't seem to work for me. Better (safer!) to sit tight and beg you guys for enhancements.