[sdk] improve download progress bar percentage

[Giorgio Venturi]

When a progress bar is used to display download progress, there seems to be no progress when the downloading starts, and it quickly completes in the last few seconds. In addition, when the progress bar indicates it is completed the process seems to be still pending .

This seems to be related to bug #1227777
https://bugs.launchpad.net/webbrowser-app/+bug/1227777

***Proposed Solution***
When achieving the intent requires more than just downloading, but also waiting for server response and installing the package, make sure the progress bar reflects the overall progress.

Note: In most cases (e.g. downloading an app), a percentage should not be displayed to indicate progress, especially when the progress bar is only an estimation/approximation.

[Matthew Paul Thomas (mpt)]

This bug is filed under both the toolkit and System Settings, but needs very different design work for each.

An engineer fixing this for the toolkit will want to know: How should the toolkit determine whether a particular progress bar is "in most cases" or not? (I suggest: Never show a percentage, or any other text, inside a progress bar. Text against a moving background would be hard to read even if it wasn't a quickly-changing number in dark grey on orange.)

An engineer implementing this for software updates in particular will want to know:

1. Should updates that have already downloaded, before you choose to install them, have their progress bar partially pre-filled?

2. How much of the progress bar should be allocated to the DNS lookup, how much to the HTTP request, how much to waiting for the server to respond, how much to the download, and how much to the installation?

3. Since waiting for the server is an indeterminate task, how should that portion of the progress bar fill? Linearly over 5 seconds? 10? Asymptotically?

[Victor Tuson Palau (vtuson)]

not an rtm blocker

[Tim Peeters (tpeeters)]

This is not a UITK bug. The ProgressBar requires the app to set the "value" (between minimumValue and maximumValue), and how this value is computed is up to the app only.

[Tim Peeters (tpeeters)]

^so the bug needs to be fixed in system-settings app.

[Matthew Paul Thomas (mpt)]

This is a UITK bug, because a software update is just one of many examples where it is not accurate for a progress bar to display a percentage. Another common example is downloading a Web page: the browser hardly ever knows ahead of time the total size of the resources in the page, so it's smoothest if it compensates for probable late discovery of new load tasks by using an accelerating curve, for which a percentage would be meaningless. Another example is syncing an Imap account: a mail client doesn't know how many messages it will need to download, or whether any of them contain huge attachments, until long after the sync has started. Even when a percentage is accurate, it's both redundant and hard to read; but often it isn't even accurate.

[Matthew Paul Thomas (mpt)]

This bug report was confused from the beginning. As Tim said, how a progress bar's value is calculated is up to the app. Some progress bars are used for downloads, and some aren't, and the toolkit does not know -- and has no reason to know -- which is which.

If particular download progress bars are inaccurate, they should be reported individually, for example bug 1227777, bug 1429022, and bug 1450144. Percentages in progress bars is a separate issue that I've added to the toolkit specification.