Startup animation closes too quickly

[leto]

Currently we show the startup animation until we obtain a valid connection to the RPC server, but really that is just one step in the journey. It leaves the user to see "Loading..." on their address balances until that potentially long operation completes. If they switch to the "Send" tab the balances of their zaddrs will not be available yet and it's basically too early to let average users use the UI, although read-only operations are fine, such at the Market Tab.

We should show the startup animation until all startup operations are complete.

[oDinZu]

So startup animation of Silent Dragon (SD) should populate on repeat until hush daemon (hushd) is online aka rpc is able to communicate SD -> hush-cli or hushd. Then, SD mainwindow launches. Assuming if able to communicate with hushd, then hushd is online.

[leto]

@csharpee that sounds nice, it's just that things are 100 times more complicated. This issue is actually not very important, it only applies when hushd is already started. SD starts so fast that one loop of the animation doesn't get to play. But when SD starts hushd in the background, it plays for a few loops as expected.

Still, if you have a massive wallet, you will notice that after the startup animation ends, you still see "Loading..." for a long time in address balances, which is lame. I tried to fix that for about 2 hours and then gave up. The problem is not very noticeable unless you have hushd started already, so I am considering this low-priority.

[leto]

In an ideal world, we would show the startup animation until we have rendered all address balances. That turns out to be really freaking hard with how the code is written. It would require changing a lot of low-level QT code. So, instead, I think we should have something nicer, like a funny image or animation we show, instead of the boring "Loading...." for all our address balances