It's either this or some fairly major refactoring, which is preferable,
but I've got another even bigger refactoring in mind, and fixing this
will be rolled into that.
Closesdubslow/qTox#4
The GUI is slow to update after accepting a password, but a cursory ten minute investigation didn't yield why
I inserted a processEvents() call before ready = true; at the end of Core::start, but that didn't help.
Define the total time between the password dialog disappearing and the UI updating with your own status is T:
Then my debug statement indicated that this processEvents call happened around 1/3T, raising two questions:
1) What the hell is happening between 0 and 1/3 T? Decryption doesn't take that long...
Note that bad passwords are immediately rejected with a new dialog, so I highly doubt it's the decryption cpu time
2) The remaining 2/3rds: processEvents has been called after the avatar and username signals, yet they
don't update in the UI till time T when everything updates after bootstrapping...
Oh well, like I said, only a cursory investigation
@apprb there is one question and one TODO that you should look over in privacyform.cpp, as well as a TODO in historykeeper.cpp
Also both the encryption settings box and the pw dialog lineedits should probably be in a QGridLayout... but I don't really want to do that by hand :P
