Load the setting's cameria preview opengl context lazily and destroy it when done. Only preallocte Core's video buffer if we have any calls active, free up when all calls are done
Toxcore would incorrectly report the call as a video call in the call settings, and then crash while trying to send a video frame in the audio call. We workaround that by using another API that correctly reports the type of the call
askProfiles is a really dangerous function. Awful things happen when the user closes that message box. We now prevent it from being closed in more places
There are small instants on startup and while profile switching during which no profile is loaded but the GUI could still receive events, e.g. between two modal windows. Disable the GUI to prevent that.
Don't just let the user close the profile select box and continue with an empty value. We would create a new profile and save it back on top of the previous encrypted profile
- Add AvatarBroadcaster, in charge of making sure our friends have our avatar without spamming file transfers
- Fix file sending code not closing the file after transfer, which prevented file previews, and make the QFile a shared_ptr to fix the obvious memory leak
Some small additions to Core to support AvatarBroadcaster
This fixes the potential edge case where a frozen then unfrozen qTox instance could have its locks delete by a new qTox instance.
We now check that we still own our locks, restoring them if we can, before saving
Starting a new instance with the -p option will force it to start a new instance with the given profile instead of bringing an eventual existing instance to the foreground
Two instances can not run with the same profiles, the profile locking code will ensure that. A user who likes to live dangerously could manually delete the lock to force two instances on the same profile, but such an hypothetical user would be asking for it.
If a qTox instance starts and becomes owner of the IPC shared memory on its first try, it considers itself the only running freshly-started instance, and deletes any possibly stale lock before starting up. This should be fine in the vast majority of cases, but if an existing qTox instance freezes for a long enough time to lose ownership of the IPC and a new instance is started without first killing the frozen one, the frozen instance's lock will be deleted as stale by the new one. If the frozen instance subsequentely unfreezes, it will be running on a profile for which it doesn't have a lock, which could cause trouble. This is an intentionaly allowed edge case, the alternative being a stale lock staying forever until removed manually. A potential solution not yet implemented would be to check that the lock is still actually present before attempting any write.
