I would suggest some improvements to the Background Manager:
I created an image to show what I mean.
The functionality:
1. From top to bottom it is checked for every queue-entry if another running entry uses the same drive. If not this queue-entry is started. This check starts always if one entry finished copying.
2. Paused entrys can be started manually by clicking on the pause-symbol or by pressing space. Running entrys can be stopped by the same way.
3. Entrys are rearranged by drag and drop. The delete key removes them.
4. Context menu could be used to remove, pause and resume an entry.
The check of number 1 is not used after Number 2 and 3.
The design:
1. The progress is only shown per line. (If files are not counted Vista like progress is used.)
2. Details of copy progress (which file is copied now) could presented in a tree like structure, but I recommend not to show it.
3. Copying many files of one folder should be merged to one job.
This were my thoughts so far. What do you think?
Background manager design and function improvements
Moderators: white, Hacker, petermad, Stefan2
-
bop sprengers
- Junior Member
- Posts: 63
- Joined: 2006-02-06, 08:51 UTC
- Location: antwerp, belgium
Perfect thing, I always wanted to see summary progress. But it requires to count files/sizes before starting job.
Idea to allow parallel jobs is good for operations on different drives.
But I think it isn't easy to allow simultaneously tasks in Background Manager - it is consecutive by design.
Also I think it is more logical to hide BM window on close and to continue operation in background instead of stopping process. Or ask user what to do.
Idea to allow parallel jobs is good for operations on different drives.
But I think it isn't easy to allow simultaneously tasks in Background Manager - it is consecutive by design.
Also I think it is more logical to hide BM window on close and to continue operation in background instead of stopping process. Or ask user what to do.
I would like to second the motion. This interface is highly visible, but isn't as polished as some of the other interfaces.
Changes I would do:
1. Separate the GUI and copy operations into different threads. Currently, even on a 2-core machine, due to the cache being written to the drive, the background transfer interface freezes until the cache is written. This wouldn't be so problematic, but if you assign another copy operation to the background transfer, the entire TC user interfaces locks up until the write operation completes. By separating the process into multiple threads, the user interface can be more responsive on multi-core CPUs.
2. A way to move items in the list. This can be done in several ways, but the fact that it doesn't exist at all is a problem.
3. A transfer-bar for the entire copy operation with an ETA displayed for the entire operation.
4. Use of Proper columns in GUI. The "->" separator looks a mess when you're copying a lot of files.
Changes I would do:
1. Separate the GUI and copy operations into different threads. Currently, even on a 2-core machine, due to the cache being written to the drive, the background transfer interface freezes until the cache is written. This wouldn't be so problematic, but if you assign another copy operation to the background transfer, the entire TC user interfaces locks up until the write operation completes. By separating the process into multiple threads, the user interface can be more responsive on multi-core CPUs.
2. A way to move items in the list. This can be done in several ways, but the fact that it doesn't exist at all is a problem.
3. A transfer-bar for the entire copy operation with an ETA displayed for the entire operation.
4. Use of Proper columns in GUI. The "->" separator looks a mess when you're copying a lot of files.
Yaron Gur
Zoom Player . Lead Developer
Zoom Player . Lead Developer
I would like to bring up this thread again.
Lately i've been busy transfering a lot of files to/from different places. (Disk to Disk and Network disk to Network disk)
Here, the F2 queue is not so handy at times since disk to disk operations are waiting for the "slow" Network disk transfer to be complete.
So personally i think this suggested changes are looking like a big improvement. Especially rearranging the entries would be great to start with.
2Ghisler
What is your view on this suggestion?
Lately i've been busy transfering a lot of files to/from different places. (Disk to Disk and Network disk to Network disk)
Here, the F2 queue is not so handy at times since disk to disk operations are waiting for the "slow" Network disk transfer to be complete.
So personally i think this suggested changes are looking like a big improvement. Especially rearranging the entries would be great to start with.
2Ghisler
What is your view on this suggestion?