Comment 1 for bug 1365060

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

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?