ManojNimbalkar / bitcoin-wallet

Automatically exported from code.google.com/p/bitcoin-wallet
0 stars 0 forks source link

the not so nice new bottomline #51

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
the new bottomline does NOT shows me anymore the count of the missing blocks 
and how many percentage is left for download. why not putting the good old type 
of taskbar-message into the new bootomline? who cares about, how many weeks the 
blockchain is behind? why not telling the plain truth of "blockchain xxxxxxx of 
xxxxxxx downloaded (xx%)" or somethings like this? and ofcourse it needs an 
progress-indicator like "downloading/computing" to see, that there is still a 
progress and not any useless waiting for nirvana.

Original issue reported on code.google.com by vn654...@googlemail.com on 19 Oct 2011 at 1:49

GoogleCodeExporter commented 9 years ago
The problem is there is no single truth. Any peer can be at any count of blocks.

Also, the percentage from last version did never really work.

Original comment by andreas....@gmail.com on 23 Oct 2011 at 5:57

GoogleCodeExporter commented 9 years ago
I guess it should be there, at least how many blocks are downloaded already and 
some information whether it has downloaded all of them to date or not. Now 
there's only a warning in this case which doesn't clearly state the end of 
downloading. 

Also, when both prodnet and testnet are running their block counters replace 
each other and you have no idea how many blocks each client has downloaded. 
Labeling them would be nice and the warning can find its place somewhere else I 
guess (for example when the user starts the app for the first time). It takes 
too much screen space for the one-time notification. It can be used better.

Original comment by radioano...@gmail.com on 10 May 2012 at 6:56

GoogleCodeExporter commented 9 years ago
The problem with prodnet and testnet blockcounters replacing each other should 
be fixed for some time. If not, please open individual ticket.

Original comment by andreas....@gmail.com on 16 Jul 2012 at 11:57

GoogleCodeExporter commented 9 years ago
Issue 103 has been merged into this issue.

Original comment by andreas....@gmail.com on 16 Jul 2012 at 12:00

GoogleCodeExporter commented 9 years ago
The progress bar _can_ be the amount to download in this session. See 
DownloadListener for an example of how to do this. If you make the bottom bar a 
progress bar that shows how much is left to download from the selected download 
peer, it will become a lot more useful.

Original comment by mh.in.en...@gmail.com on 17 Jul 2012 at 7:25

GoogleCodeExporter commented 9 years ago
(I was just going to write a lot of how unintuive progress bars are in the 
context of the blockchain, when I had an idea and I deleted it all)

The only case where a progress bar IMHO actually makes sense is first-time 
setup/blockchain reset.

I propose the following: If the app gets reported the first peers chain height 
(and I really mean first, so this will be persisted), the app will start 
displaying a progress bar that will go from 0 towards that reported chain 
height. If the height is passed, it will be gone and never be seen again (until 
blockchain reset that is).

After that point, and with autosync hopefully to be active by default soon, 
there should never be a reason for displaying progress again.

The progress bar could perhaps report the estimated *download time* inline, 
although this is problematic again because there could be larger gaps in 
download.

There is the slight chance that the first peer reports a vastly wrong chain 
height, but this would not be the end of the world. A "known minimum" threshold 
could protect against this case.

Original comment by andreas....@gmail.com on 18 Jul 2012 at 1:54

GoogleCodeExporter commented 9 years ago
I think Satoshis code takes the most common height reported by all connected 
peers.

I'm not sure why just displaying the amount to download from where we are now 
to where we think the chain is, is so problematic. It should usually result in 
a fairly rapid movement of the progress bar from left to right.

Original comment by mh.in.en...@gmail.com on 18 Jul 2012 at 2:02

GoogleCodeExporter commented 9 years ago
As the reference implementation has now more or less copied the approach of 
just showing number of hours/days/weeks behind, I doubt this will change soon. 
I'll close this issue for now.

Original comment by andreas....@gmail.com on 24 Feb 2013 at 11:25