| Age | Commit message (Collapse) | Author |
|---|
|
This makes it easier and more intuitive to build a minimal JSON payload
for a given event type. A common basicJson() call point is also
convenient in template contexts (see next commits).
|
|
EventContent::Base has been made primarily for the sake of dynamic
polymorphism needed within RoomMessageEvent content (arguably, it might
not be really needed even there, but that's a bigger matter for another
time). When that polymorphism is not needed, it's easier for reading
and maintenance to have toJson() member function (or even specialise
JsonConverter<> outside of the content structure) instead of deriving
from EC::Base and then still having fillJson() member function. This
commit removes EventContent::Base dependency where it's not beneficial.
|
|
Main changes:
1. Base::fillJson() gets a QJsonObject& instead of QJsonObject* - c'mon,
there's nothing inherently wrong with using an lvalue reference for a
read-write parameter.
2. UrlWithThumbnailContent merged into UrlBasedContent. The original
UrlBasedContent was only used to produce a single class,
AudioContent, and even that can logically have a thumbnail even if
the spec doesn't provision that. And there's no guarantee even for
visual content (ImageContent, e.g.) to have thumbnail data; the
fallback is already tested.
3. toInfoJson is converted from a template to a couple of overloads
that supersede fillInfoJson() member functions in FileInfo/ImageInfo.
These overloads are easier on the eye; and clang-tidy no more warns
about ImageInfo::fillInfoJson() shadowing FileInfo::fillInfoJson().
4. Now that UrlWithThumbnail is gone, PlayableContent can directly
derive from UrlBasedContent since both its specialisations use it.
5. Instead of FileInfo/ImageInfo, fillInfoJson() has been reinvented
within UrlBasedContent so that, in particular, PlayableContent
wouldn't need to extract 'info' subobject and then roll it back
inside the content JSON object.
|
|
|
|
With the reworked JsonConverter code it is possible to work uniformly
with structures that have a member toJson() and a constructor converting
from QJsonObject, as well as with structures that rely on an external
JsonConverter specialisation.
|
|
This is a rework of EventContent::SimpleContent previously defined in
simplestateevents.h. Quite a few events (and not only state events) have
just a single key-value pair in their content - this structure (which
is really just a template wrapper around the value) and the accompanying
JsonConverter<> specialisation encapsulate the concept to streamline
definition of such events. This commit only has simplestateevents.h
using it; further commits will use SingleKeyValue in other places.
toSnakeCase is a facility function that converts camelCase used for
C++ variables into snake_case used in JSON payloads. Combined with
the preprocessor trick that makes a string literal from an identifier,
this allows to reduce boilerplate code that repeats the same name for
fields in C++ event classes and fields in JSON. SingleKeyValue uses it,
and there are other cases for it coming.
|
|
|
|
Yet another missing header from times when .h files weren't added to
CMakeLists.
|
|
|
|
Add a macro to make slicing clear in the code and quiet for static
analysis.
|
|
Check edKey when receiving an olm message and prepare for MSC 3700
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Store some more things in the database
|
|
|
|
Co-authored-by: Carl Schwan <carl@carlschwan.eu>
|
|
|
|
Is required to correctly choose a session to use for sending messages
|
|
|
|
|
|
|
|
signature checks
|
|
|
|
Building with static libs fails on QtKeychain apparently underlinking
with glib when --coverage is passed.
|
|
Co-authored-by: Carl Schwan <carl@carlschwan.eu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make sure that the enum values correspond to the values used in the spec
and use them instead of magic constants
|
|
Probably improves the performance slightly
If we handle to room data first, if a message arrives at the same time as the to-device message containing the key and we handle the message first, it will not be decryptable and stored as undecrypted. Then, when the key is handled, the cache of undecrypted messages is searched, the message decrypted and replaced.
When handling the key first, the message can be decryped instantly.
|
|
|
|
|
|
|
|
Otherwise new one time keys will be uploaded on every start
|
|
|
|
|
