On Fri, Dec 20, 2002 at 12:06:48AM +0000, Matthew Toseland wrote: > > Very cool! Only thing is that it might be just as well to make the > > colors contiguous as in Simon's screen-shot, I am not sure that there is > The colors were not contiguous in simon's screenshot.
Yes they were. By contiguous, I ment that we don't try to represent each individual block. Matthew, you can nit-pick all you want in an effort to disguise the fact that you have lost every argument you started today, but you aren't fooling anyone :-) Normally I wouldn't gloat, but you are being so damn arrogant it is hard not to. > > So, the first length of the bar could indicate downloaded/failed blocks > > (perhaps blue downloaded, red DNF, orange RNF), these can be mixed up if > > so-desired, or separated. Separated will make the table render much > > faster. > No, we need to have a failed-but-going-to-retry color, as well as a > failed-but-not-going-to-retry color. Not necessarily, it would be easier, when we are going to retry a node, to put it back in the green state, but even if we were to do that, it is a pretty trivial modification to my proposal. > > The third stretch of the bar - maybe green, indicates the number of > > blocks which must be downloaded to reassemble the file. > Eh? Sorry, I don't understand this bit at all. IRC? You need 100 blocks, out of 150. You have successfully downloaded 20, with 10 failures. The green area would be 80 blocks in length, representing the number of blocks you must download at this point to successfully reassemble the file. Ian. -- Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] Latest Project http://cematics.com/kanzi Personal Homepage http://locut.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021219/76ca488a/attachment.pgp>
