In other applications chatrooms allow you to idle in a call and have
people hop in and out as desired. If a user is the only one presently
online in a group but knows someone will be joining shortly they should
be able to join the call ahead of time.
Qt doesn't support QObject multiple inheritance, so use our existing interface
macros to declare signals in the interface without QObject, and implement them
in child classes.
c-toxcore calls the groupCallCallback from it's main thread instead of
the ToxAV thread as expected, this was triggering an assertion.
Aditionally the destructors of Core and CoreAV were fixed, because they
now either crashed or deadlocked qTox when it was closed while a group
call was still running.
This actually fixes two problems:
1) CoreAV and Audio thread both locked the callsLock and audioLock in
different orders, resulting in a deadlock of both threads. This fixed by
using a ReadWriteLock in the CoreAV thread.
2) Multiple functions were emitting signals while holding a lock. This
is unsafe, because the connected slot may acquire any other lock. This
is fixed by releasing the locks before emitting signals.
It doesn't really make sense to assert that the callbacks are coming
from any other thread than CoreAV, when we actually want to ensure the
callback is coming from Core thread.
Remove over agressive assert from sendGroupCallAudio(...), this function
should be callable from any thread.
We we're calling toxav_* functions without synchronizing to any of the
Tox threads.
Additionally remove the call timeout, it creates timers from different
threads, which causes errors.
As of 2019-10-09, toxme.io was taken offline permanently. Remove UI and code
in qTox relating to it. Revert this commit if it comes back online in the
future.
Fix#5897
When re-evaluating our dependencies we decided that the update bridge
has a high potential for security issues because it's not widely used.
Additionally similar functionality is already present in qTox.
When re-evaluating our dependencies we decided that the update bridge
has a high potential for security issues because it's not widely used.
Additionally similar functionality is already present in qTox.
* When the DB schema was too new we were accessing history anyways. This
has potential to just completely corrupt the DB
* When history was disabled there was a chance we would attempt to write
to history anyways. Added more checks in this area
* Chatform was accessing invalid iterators when there were no displayed
messages. Added a guard for this case
indexes need to be created after their corresponding table is created.
QMap doesn't enforce insertion order, just key order, so use a vector.
Also verify indexes from sql_master instead of only tables.
