* Resolves#6221
* System message schema designed to take enum of message base + args
* New table layout required many updates to the queries executed by
history
* Bonus reduction of history signals/slots by issuing some file transfer
insertions directly when possible
This change adds a check for the V4L2_CAP_VIDEO_CAPTURE capability of
the video device found on devfs. This will filter out 'metadata' device
nodes that may be present on devfs at some /dev/videoN path.
Fixes#6276
Fix two small problems that break flag emojis
(1) Multi-char emojis are accidentally grouped together with emoticons
(such as : smile :). This is fixed by using a more robust isAscii(...) function
(2) Smiley regexp construction is undeterministic, causing multi-char to
sometimes be processed first, sometimes last. This is fixed by explicitly
inserting multi-char patterns first.
Issue: #5147
v0.0.2 of toxext_extended_messages brought in a user configurable max
message size. This changeset implements the minimum work required for
qTox to work sanely under the new API.
* Hardcode a max message size for all friends
* If a friend negotiates a max message size below the hardcoded value
pretend they do not have the extension
* Move splitMessage out of Core to MessageProcessor
* Updates to allow for extended messages to be split
Added a UI element to indicate extension support of the chatroom. For
all groups it will always be red since we do not support extensions in
groups. In a 1-1 chat the indicator will either be green/yellow/red
depending on if the friend has support for all/some/none of qTox's
desired extension set.
* Added new negotiating friend state to allow delayed sending of offline
messages
* Added ability to flag currently outgoing message as broken in UI
* Reworked OfflineMsgEngine to support multiple receipt types
* Moved resending logic out of the OfflineMsgEngine
* Moved coordination of receipt and DispatchedMessageId into helper
class usable for both ExtensionReceiptNum and ReceiptNum
* Resending logic now has a failure case when the friend's extension
set is lower than the required extensions needed for the message
* When a user is known to be offline we do not allow use of any
extensions
* Added DB support for broken message reasons
* Added DB support to tie an faux_offline_pending message to a required
extension set
* Introduced ToxExt and CoreExt abstraction
* Along with interfaces for mocking and unit testing
* Add "supportedExtensions" concept to Friend
* Dispatch messages to CoreExt instead of Core when friend supports
extended messages
* Only split messages for core when extended messages are unavailable
* Offline message engine/History not altered. Currently only valid for
an existing session after extension negotiation has completed
In history we cache peers to avoid extra DB lookups, this code is not
pretty and seems to provide little benefit. This reduces the cognitive
load when trying to reason about history.
* Removed peerId table from history
* Replaced peerId lookups with generated select statement
* Benchmarked on a profile with ~100 peers in the db and saw no
noticible change in transaction time (6-30 ms both before and after
the changes)
This commit fixes an issue when switching from any language back to English,
the system translations remain to be the last language even if the application
translations have switched back to English.
In some languages the "up to date" text can get over the qTox version text, so
this commit moves "up to date" above. The commit also moves the "Update
available" button above and stretches it.
This could happen between the time when the release tag is pushed and the time
when the release binaries are published.
Fix#6112
(cherry picked from commit 82547263f8)
This commit adds a new define called "GIT_DESCRIBE_EXACT" through cmake.
It is checked with a regex in "updatecheck.cpp" for a version number after the
check for new updates. If there is no version number,
a warning is output to log.
The reason for the new define is to avoid doing too much regex on
"GET_DESCRIBE", since "GIT_DESCRIBE_EXACT" will not contain a version number if
the code is not tagged.
TriKriSta (5):
fix(ui): implement and connect reloadTheme in leaf classes
refactor: delete classes that were used to reload theme
refactor: save friendScroll as a class member
refactor: reorder of includes
fix: clear custom style before update style
This allows leaf classes to update independently when the GUI has changed themes, without
their parent having to call updateTheme() manually.
Fix#5924Fix#5592
When a setting is set it locks the Settings mutex and emits a signal for that
setting. If a slot is connected to that signal and lives on the same thread as
Settings, it is executed immediately with the Settings mutex still locked. That
slot can then lock a series of other mutexes. During this time another thread
can lock a mutex and then try to read settings, which will cause a deadlock due
to the opposite order of multiple mutex locking. By always emitting signals
after unlocking the Settings mutex, we avoid holding the Settings mutex while
executing slots.
Fix#6218
Profile is required to load personal settings, and Profile was creating the
bootstraplist using personal settings. Instead create the bootstraplist in
initCore, after personal settings have been loaded. This avoids using an
uninitialized proxy type on every profile load.
- Seed random in Core Thread. Core Thread didn't seed random, resulting
in always using the same bootstrap nodes, even when you restart qTox
or change profiles.
- Use QDateTime::currentMSecsSinceEpoch() for seeding random. It
provides a bigger range of numbers than QTime::currentTime().msec()
does, and the latter somehow managed to result in approximately the
same first random number being generated, within a certain range.
- Use something a it more sensible than a mod operation to bound random
numbers within a range. It's not perfect either, but a lot better.
Using mod on random skews its distribution too much.
- Use QRandomGenerator's bounded() function to generate random values
within a range.
- Enable QRandomGenerator's usage starting with Qt 5.10.0.
QRandomGenerator is present since Qt 5.10.0, not 5.15.0.
- Bootstrap off every 5th node instead of two consecutive nodes. It's
likely that two consecutive nodes will have the same owner, which
makes some attacks more likely. The node selection algorithm should be
scraped and redone from scratch to be honest though.
This is a feature/fix to improve notification behavior when we receive
over 3 messages.
SnoreNotify prevents over 3 notifications from being displayed before a
user clears the notification. This is presumably to avoid infinite
notification spam.
Unfortunately this results in the notifications just coming in _after_
the user clears them. This means if there are 100s of messages built up
the user has to clear their notifications N messages / 3 times.
This feature/fix folds all notifications into a single notification
representing the current qTox notification state. See
notificationgenerator_test.cpp for what the new messages look like.
Previous exif transformations were not valid. The exif spec defines the
orientations as where the 0th row and the 0th column should end. The
previous mappings used in qTox did not respect these mappings and needed
to be updated.
We need to be lenient when reading from db because of ToxIds being saved in the
db from a bug introduced in e07d8d358f, which
used self ID rather than self Pk. Was subsequently fixed in
033f28e67e.
