synchronizer: show progress in GUI (take 2) (req_answered/req_sent)

[SomberNight]

This is another take on #5312

We display Synchronizing... ({req_answered}/{req_sent}),
where req_sent is the number of network requests ever sent to the current main interface,
and req_answered is the number of those network requests that have been answered.

based on idea by @bauerj

This is probably easier to understand for end-users than #5312

However, it's not perfect.
By nature of this metric, the state is persisted in the interface, this means

• state is shared between wallets
• counters only reset on reconnect
  i.e. if you have a long running process, and open another wallet, both numbers will start with large initial values accumulated in the past.

[bauerj]

Nice, I'll try this later!

It might help to hide some of the weirdness of this metric using a percentage value instead.

[gits7r]

hey, neat stuff! I like this very much and it's about time we had this.

This is way better than #5312 in terms of digesting by average end users.

However, let us make it even simpler. The information displayed has little to no value to the end users, it's just useless. The point of this feature is to let users know something is happening and also something is progressing, and only thing required is little more patience. So, because these are irrelevant to average end users, instead of displaying the req_answered / req_sent in their numeric values, let us just display the result of this equation and update its result live:

req_answered / req_sent * 100 = n%
EDIT: rounded up to it's 2nd decimal, like 23,37%
Where the guy will only display Synchronizing... (n%)

and since n% will count up, the goal of this feature is achieved and no useless / confusing information is displayed to end users. They don't need to think about these numbers, if they are too high, too low or whatever other useless thoughts.

Same for Kivy of course.

[bauerj]

I stand corrected, the progress irately jumping from up and back down seems like we want to torture our users. In this form, the count is more useful than a percentage.

[gits7r]

I was unaware the counts can jump up and down, I thought they can go only up as more requests are sent / received but never down. I only understood that if you open a new wallet from an old running process the value for counts will start at very high values, but not that it's possible to go down.

Now I understand how they can go down, Electrum sends requests faster than it gets them answered, so the % progress might decrease as there are less answered requests than sent requests when synchronizing.

In this case, I also support displaying the numeric count rather than %, otherwise we need a hack something like:

• if result of the equation is less than (<) what is currently displayed in the GUI, display the old value (do not decrease % progress);

[ecdsa]

nice proposal. I think both counters should not be shared between wallets, so we should define them in the wallet, not in interface. in addition, they should be reset everytime we reach the synchronized state.

[SomberNight]

@ecdsa Ok, I've redone this to do something like that in #5319

@gits7r Yes the issue with a percentage is that it will not always change monotonically. In fact, during initial sync, it will fluctuate a lot.

I think #5319 is superior, closing.