thanks a lot for your reply.
Regarding your reference to Windows progress bar: It's not really a fair comparison as Windows 7 does not have a queue of transfers. It's displaying progress of single transfer only (equivalent to single line in WinSCP queue). When Windows shows single progress for multiple parallel transfers (Windows does that when its groups multiple buttons into one, when taskbar becomes crowded; Windows 8 does this always), it's not doing any good job as it shows progress of the least "progressed" transfer only (see attached Windows 8 screenshot). I believe this is not what you seek for.
Well, to be honest, I'm already happy that WinSCP *does* show a progress bar on the task bar icon at all, because FileZilla suffers from not having this feature:
And I guess you're right, I never realized that windows only reflect the progress of one task. From my experience, in most cases it doesn't make a big difference though, because if you split an upload into several equal parts, they will take a fairly similar amount of upload time. Of course, that may be differ for users with other requirements.
It's not really easy to show overall progress of multiple tasks that potentially start at a different times (new tasks can be added while others are still running). How would you calculate it? I have some idea, but it is not straightforward to implement. Maybe you have better Smile
What I would expect is that the overall amount based on transfered data (Not time) is displayed. So, for example assume that there are 3 upload threads given:
1.) 1 GB overall, 100 MB already uploaded (currently 10%)
2.) 500 MB overall, 300 MB already uploaded (currently 60%)
3.) 4 GB overall, 1 GB already uploaded (currently 25%)
If you just build the average of all percentages you would get: ((0,1 + 0,6 + 0,25) / 3) = ~0,31
But this approach doesn't reflect the overall progress very well because it doesn't consider the different amounts of data for each thread.
A much better approach would be to consider the data amounts which would result in: ((100 + 300 + 1000) / (1000 + 500 + 4000)) = ~0,25
which reflects a far better status from my point of view.
Regarding adding new tasks during runtime: Well, you would see a jump in the progress bar if you do that. But that's what I would expect because for me that feels natural.
Whether tasks that are on hold with a scheduled upload time are considered or not is certainly a design question. Personally I would consider these tasks too, but other people may have other opinions here.
Of course that's all just my opinion, how I would implement it, if I would code that.
Thanks a lot for taking the time to listen to my suggestion.
Keep up the good work,