1
0
mirror of https://github.com/qTox/qTox.git synced 2024-03-22 14:00:36 +08:00
Commit Graph

165 Commits

Author SHA1 Message Date
tux3
e74e29e4fb
Cleanly cancel broken file transfers 2015-04-25 19:18:46 +02:00
tux3
cdb2bad7c3
Signal broken file transfers 2015-04-25 17:12:49 +02:00
tux3
c6e60c4c77
Remove some CoreFile debug output 2015-04-25 16:59:29 +02:00
tux3
bd5eebbc2e
Cache avatar sending, fix image file preview
- 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
2015-04-25 16:51:58 +02:00
tux3
9ece486e22
Prevent possible uninitialized read of status
For unhandled values of Status, we want to return, not continue with an uninitialized value.
2015-04-25 02:28:57 +02:00
tux3
0e65d150e3
Don't show call buttons in text-only groupchats
I'm not sure why there are text-only groupchats in the first place, but that's fixed.
2015-04-25 01:50:35 +02:00
tux3
9d3d17d05e
Avatar sending on top of file transfers 2015-04-25 01:26:52 +02:00
tux3
5662120c51
Show Tox ID instead of blank names 2015-04-24 21:34:24 +02:00
tux3
42d7a7bcef
Assert profile locks before writing
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
2015-04-24 21:05:19 +02:00
tux3
05b6f1985d
Allow to start multiple instances with -p
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.
2015-04-24 19:43:39 +02:00
tux3
bbf75aefb9
Profile locking 2015-04-24 18:53:19 +02:00
tux3
13d98da1bc
Correctly separate received actions from messages 2015-04-24 15:57:01 +02:00
Zetok Zalbavar
92f3b6a20f Code style improvements 2015-04-24 15:43:57 +02:00
tux3
9dedd22bb2
Port file transfers to the new API
Parallel, extremely large, and other edge case transfers have not been tested, but the common path should work well.
2015-04-24 15:31:30 +02:00
tux3
e4859efe18
Refactor Core
Refactor Core's file transfer callbacks into their CoreFile class and files

Move all core*.{h|cpp} into a core/ folder
2015-04-24 02:32:09 +02:00