Send Copy/Move/Delete to the background
Send Copy/Move/Delete to the background
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.
Re: Send Copy/Move/Delete to the background
Same in Servant Salamander: While copy / move /... is in progress, use the "Minimize" button to send the copy-window to the taskbarStoeck wrote: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.
Kind regards, KNUT
_____________________________________________
Satisfied Servant Salamander User from Version 1.5 till now
_____________________________________________
Satisfied Servant Salamander User from Version 1.5 till now
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
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.
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.
Mouse-centric, Registered
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
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.
The "Minimize" button does exactly what it says and what is standard in the Microsoft Windows.
Last edited by Jan Rysavy on 03 Mar 2006, 15:51, edited 1 time in total.
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?Should we add the "background" button to each of them?
It's better to tell him/remind him IMHO.
Mouse-centric, Registered
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
What about the Find window while search is in progress?JohnFredC wrote: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 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...
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.
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.
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.
What if I want the copy to proceed in the foreground? My off-hand assumption would have been foreground as default.(Copy/Move/Delete operations runs always in background from version 2.5.)
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.
Mouse-centric, Registered
-
- ALTAP Staff
- Posts: 1112
- Joined: 08 Dec 2005, 09:13
- Location: Novy Bor, Czech Republic
- Contact:
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.
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.
This is unfortunately only too true.you still could switch to another running application
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.
Mouse-centric, Registered
-
- ALTAP Staff
- Posts: 1112
- Joined: 08 Dec 2005, 09:13
- Location: Novy Bor, Czech Republic
- Contact:
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).
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
JohnFredC wrote:I recently had an issue when using two different file managers simultaneously (not Salamander)
What file manager are you both talking about?Petr Solin wrote:I think that this your problem is caused by error-ignoring software (not unusual even among filemanagers, they save 80% of work by this)
Now you know why we are so slow -- we are implementing the error handling code all the time
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.
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.
Mouse-centric, Registered