The qTox Project is not associated with the Tox Project in any ways, with the exception of "qTox" using the Tox Projet's "toxcore" collection of libraries.
In particular, the Tox Projet does not own copyright over the qTox Project's "qTox" collection of software, source code, and assets.
The qTox Project's assets are under the sole copyright of the qTox contributors, and no partiular rights are granted to the Tox Project.
We returned a shallow copy of the delete[]'d salt buffer
As a result the history consistently failed to decrypt and was removed as corrupted. This is now fixed.
Profile encryption should be fairly stable. History encryption was *NOT* tested yet and as such may not work, cause profile corruption, or invoke nasal daemons.
* added copyright header to src/platform/statusnotifier/enums.c
* 'switch(' → 'switch ('
* use Allman style
----
for / if / while / switch () {
↓
for / if / while / switch ()
{
----
----
for / if / while ()
{
1_line;
}
↓
for / if / while ()
1_line;
----
----
for / if / while ()
1_line;
line_out_of_loop;
↓
for / if / while ()
1_line;
line_out_of_loop;
----
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