- this adds an option under the Display tab, to enable a relative progress
bar display (per popular demand)
- it takes a "remaining blocks at startup" value as maximum (which is
dynamic, when there are new blocks while downloading the chain)
- the bars value is computed by subtracting the above value from the current
remaining block count of the node converted to a positive number
- update some comments
- remove some orphan settings from the optionsdialog.ui file
That's great, but an option? Seriously? These are the kinds of options that don't really make any sense. Why not just make this the default? Does anyone find the current behavior useful?
That whole progress bar think is very controversial and it''s hard to do it right as a change that some like other seem to hate. That's why I chose the option way, set it like you want it to be.
I'm fine with some final decision to just change the default though.
Yeah, I understand the appeal of an option in this case, but if we add an option every time developers can't get consensus on something trivial it just results in a nonsense UI. How many people will ever change that setting?
The current setup means that for anyone who isn't a brand new user, the progress bar never moves and never indicates progress in any useful way. I don't understand how this can be controversial.
It's not about "developer consensus" it's about real observed behavior: The relative indicator was frequently causing users to freak out, corrupt their chains by screwing around trying to 'fix' things that aren't broken, or uninstall the software and send angry email. It's a non-starter.
(An example case study: A user installed bitcoin, couple hour sync time. Weeks later he restarted the client, and freaked out that it was back at zero thinking it meant another couple hours. To try to resolve this he downloaded a chain file from a website. But it still showed zero, so he downloaded another chain file and managed to mix up the blk/index files in the process... corrupting his database and then his client wouldn't start. While trying to fix it he followed some instructions and deleted his wallet. This is an extreme case, but we were getting complaints related to this behavior with fair frequency. It's objectively problematic. The relative indicator may be not very useful, but it's the lesser evil.)
The recommendation in the last discussion was to find an indicator which both prevents users from freaking out and is also useful and informative for short resyncs. I thought we achieved that already, but if not then we should keep grinding on it. I don't think an option makes sense.
You could just provide an estimated time remaining indicator alongside the progress bar. Non-paranoid users would wait and see that it advanced faster than last time anyway though, I don't know that we should optimize for the case of users who try and download chain files from websites. That seems over the top.
After all discussion about this apparent non-issue, I'm starting to think that a progressbar is just not the right way to show the progress here. The bitcoin wallet on Android just tells you how far (months/weeks/days/hours) it is behind. I'm starting to think that is enough...
I was trying to get a time-left display implemented, I'll add that as seperate commit later, so perhaps that is better with a relative display.
Yeah, but I asked Andreas to put a progress bar into the Android app too. Time by itself turns out to be less useful when you're far behind.
I don't think progress bar+estimated time is a big deal. The code for it is quite straightforward. On 31 Jul 2012 15:54, "Pieter Wuille" < reply@reply.github.com> wrote:
After all discussion about this apparent non-issue, I'm starting to think that a progressbar is just not the right way to show the progress here. The bitcoin wallet on Android just tells you how far (months/weeks/days/hours) it is behind. I'm starting to think that is enough...
Reply to this email directly or view it on GitHub: #1639 (comment)
- add secondsToDHMS() to guiutil.{cpp/h}, which converts seconds to DdHH:MM:SS format
- add util.h to bitcoingui.h for CMedianFilter
- add a time-left display when downloading blocks (based on a median of remaining blocks * time per block)Yes, it is straightforward. But implementation is not the problem. We've had both progress bars (one absolute, and one relative to the sync part since startup). As far as I remember, both were confusing and people complained in both cases to change it to the other. My conclusion is that a progressbar is not the right way to convey this information.
Well I have said before, I don't want an option, we just have to pick something and stick with it. And we did.
Last time, most of the developers were for an absolute progress bar. But this has flip-flopped too many times I don't even want to discuss about it.
Edit: of course, if you have an alternative that is even better (and noncontroversial too) that's great! But switching between two sub-par options is not an improvement.
Closed for now, problem with the timer was it only got updated when block count changes (void ClientModel::updateTimer()), so the timer stuck, when the block download was stuck ;).