modified block DL progressbar to be more informative and precise #1025

I added a % left value to the tooltip, the progressbar text is now displayed in it's middle centered and uses real block values instead of only a % value ("x of y blocks (z %)"). The progressbar is hidden, if there is no network connection and get's hidden, if the connection is lost.

Edit: Removed the dynamic component of the idea ;).

NAK. Most confusing possibility yet proposed. :(

The problem with relative progress is that people restart while syncing and freak out when it goes to zero... thinking that it's started from the start again. Some people have even given up on the reference client as a result of this (or so they say on IRC).

Behavior that changes in ways that would take a paragraph to explain based on state which is hidden from the user is not intuitive at all.

However, I like showing real block values— but UI clueful people seem to think this is a bad idea.

I'm new in that discussion, but think about it for a while ... the ugly thing is not really the full resync, but if you didn't start the client for a few days and it has to catch up let's say 1000 blocks. This would be displayed relative and does not seem to stuck for so long on 99%. I even added the strings "abs. display" / "rel. display" as a hint.

But okay, so if the consens would be to not use a dynamic display at all, what do you think of the other changes (including only displaying the bar if there is a bc network connection)?

We've already tried the "show relative progress" thing once. It didn't fly.

Unless someone develops an elegant widget that shows both absolute and relative information in a neat, intuitive way (and cross-validates this with the complainers on the bitcoin forums and here) I'm reluctant to try it again.

I do agree with only showing "catching up" and the progress bar when the network connection is up. See my implementation comment though :)

So if a relative display didn't fly what about displaying "x of y blocks (z %)" as text on the progressbar? I think it's very nice, because you see progress per block and not per % (which is ver imprecise).

Updated to be not relative anymore and changed network detection part as laanwj suggested.

The problem is that the source information (the YY in "XX of YY blocks") is imprecise too. Showing that number only gives a false sense of precision.

On the other hand I agree with you. If you show a progress bar, the % is redundant as it is already visually conveyed.

Can you explain, why YY is imprecise? That are the current all time blocks in the network (claimed by the nodes), but even if the real value is not correct, the new text display is clear.

If you start the client and it sits on 99% for minutes you think fuck what's up. If it reads 9900 of 10000 blocks (99%) and keeps moving block for block you see it's working and it progresses further.

I'd say use an absolute percentage chain always, but put in readable text on it "est. X blocks left".

Last commit makes it absolute again, so that's fine and I won't touch it anymore ^^.

So we have the coice if we keep "%", use my suggestion "x of y blocks (z%) or something like sipa suggested above. As I said everything is better than a simple % because users want to see at least a real progress.

Edit: Tried it and a "x blocks remaining (y % done)" message looks nice and clean, too.

Thanks for making it absolute again.

I'm convinced. I think we should drop the percentage from the text and show "xx of estimated yy". Percentage is implicit in the progess bar visual and doesnt add anything.

Sipa's suggestion to show only the estimated number of blocks left is also good. Advantage is that it shows only one number, disadvantage is that the derived number is less useful for problem diagnostics.

The more I think about it, the better I like sipas idea of only showing the remaining blocks. And for problem diagnostic we have a tooltip, which shows the real numbers.

So "~xx blocks remaining" as text? Centered on the progressbar (perhaps hard to read as this uses the native OS style for the bar and text) or to the right of the bar?

I'd say show it on the progress bar. That's one less level of indirection. If it looks weird on some OS we can always change it.

Was a bit tricky to count backwards (blocks remaining) and keep track of the right value (scale) of the progressbar, but now it's ready for testing / review :).

Looks good so far, but

• small blocks for the progress percentage are not nice when combined with text
• at least here, it's completely unreadable: dark blocks for progress with black text; is there a way to get something like this: http://stackoverflow.com/questions/6258690/is-there-any-way-to-change-the-color-of-text-halfway-through-a-character-on-a ?

@sipa The style/design of the progressbar comes from the OS and can only be changed by some form of Qt stylesheets afaik (see: http://harmattan-dev.nokia.com/docs/library/html/qt4/qprogressbar.html#details).

2 options, put the text right to the progressbar or search the web for howto edit the style of the bar (which is a hard work, because of the different OS GUIs and color schemes :-/).

Okay, I found a way to apply stylesheets to the bar and it can be very well customized ... will add a commit so you could try it out @sipa.

Ok, let us know how it goes. Sounds like something that is a nightmare to get right on all OSes. Otherwise, putting the text in the progressBarLabel to the left of the progress bar is fine too.

OMFG what a mess, but now I'm happy :-D. So on Windows the bar looks equal, no matter what theme I activate and even if I chose the classic theme.

I moved some one-time functions so that they don't get called everytime setNumConnections() is called.

To the style itself, I chose an orange as bar color, because of the Bitcoin icon and I think it ROCKS! But hey let's vote or you can make own suggestions :).

So on Windows the bar looks equal, no matter what theme I activate and even if I chose the classic theme.

This does mean we lose platform-native styling for the progress bar. Not that that is necessarily a problem, I think it looks nice (also on Ubuntu 11.10).

I had to edit the code once more, because in the end of a sync the bar was rather jerky and jumped a bit too much. Because of that I had to seperate the "~x blocks remaining" text from the real progress bar values, to be not linked. Now the displayed text is one thing and the progressbar progress display another one.

Edit: I will rebase this after I got some final ACKs :).

It looks nice, visual ACK. I didn't check the source code changes.

That last commit did certainly make it better. It seemed like the number never changed while I was looking :-)

Edit: ACK

@laanwj Could you take a short look over the last commit. If you are fine with that, I will rebase!

So we have 1 "visual" ACK and laanwjs ACK, further dev votes :)?

I don't think there's much more to be done, except determine whether we want this for 0.6.1 or 0.7.0. The code change is small and simple enough to make it end up in 0.6.1 IMO, the only hindrance is that some translation messages have been changed and it usually takes a while to update them.

As for the translations, I would push the new master file (en) early to transifex, so that translators have enough time to keep up. So I guess there will be RCs for 0.6.1 and I suggest let's integrate this one here.

Remember, there is that Wallet-HTML-thing from #945, which has to do with translations, too (even if we would do that).

Yes, agreed. I'm for merging this as soon as possible. (and also #1002, depending on whether we fix URL handling for 0.6.1)

#945 is for 0.7.0 as it is pretty low-priority (nearly no visual difference) but a lot of hassle for translators.

Fine for 0.6.1 for me.