| Age | Commit message (Collapse) | Author |
|---|
|
|
|
To streamline adding of simple getters of content parts.
|
|
QPair is giving way to its STL counterpart, becoming its alias in Qt 6.
|
|
|
|
This macro was defined in accountdataevents.h but adding one more
parameter (base class) makes it applicable to pretty much any event
with the content that has one key-value pair (though state events
already have a non-macro solution in the form of
`StateEvent<EventContent::SingleKeyValue>`). Now CustomEvent definition
in quotest.cpp can be replaced with a single line.
|
|
Not that it was very important, as the two are basically the same thing
(and matrixTypeId() is about to be obsoleted); but formally basicJson()
is supposed to get the former, not the latter.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For EncryptedFile:
- JSON converter bodies moved away to .cpp;
- instead of C-style casts, reinterpret_cast is used to convert from
(const) char* to (const) unsigned char*;
- the size for the target plain text takes into account the case where
the cipher block size can be larger than 1 (after reading
https://www.openssl.org/docs/man1.1.1/man3/EVP_DecryptUpdate.html).
- file decryption is wrapped in #ifdef Quotient_E2EE_ENABLED, to avoid
OpenSSL linking errors when compiling without E2EE.
|
|
That's a better primitive than just exposing SupportedAlgorithms list.
|
|
|
|
A note on switching to QLatin1String for JSON key constants - this is
more concise and barely affects (if at all) runtime performance (padding
each QChar with zeros is trivial for assignment; and comparison can be
done directly with the same performance as for two QStrings).
|
|
Also, removed Q_GADGET macros from key verification events as those
don't seem to do anything (no Q_ENUM/Q_FLAG things, namely).
|
|
|
|
This reverts commit 2cf44607cf0f057e147c2c4fe6dded6c13c58a8a (that was
stupid, honestly).
|
|
Logging categories used by Quotient are not supposed to be exposed
externally, which basically forbids usage of logging in header files.
A more flexible solution would involve moving logging.h to private
headers but Quotient doesn't have that thing yet.
|
|
The result is FTBFS as yet; next commits will fix that, along with a few
other things.
|
|
|
|
|
|
|
|
|
|
Move out current room state to its own class
|
|
Because Apple Clang choked on `explicit(false)`.
|
|
Default construction was only done to support stubbed state in Room
and even that did not really use those, opting to construct an event
from an empty QJsonObject instead. Now that Room doesn't have
stubbed state, default constructors are even less needed.
|
|
|
|
It's too restrictive compared to switchOnType() overloads and doesn't
map to the case with a default value.
|
|
Get rid of that Q_ASSERT() in the middle that only worked in Debug
builds anyway.
|
|
RelatesTo and EventRelation have been two means to the same end in two
different contexts. (Modernised) EventRelation is the one used now both
for ReactionEvent and EventContent::TextContent. The modernisation
mostly boils down to using inline variables instead of functions to
return relation types and switching to QLatin1String from const char*
(because we know exactly that those constants are Latin-1 and
QLatin1String is more efficient than const char* to compare/convert to
QString).
|
|
When internal linkage is necessary, anonymous namespaces fulfil the same
purpose in a better way. See also:
https://stackoverflow.com/questions/4422507/superiority-of-unnamed-namespace-over-static
|
|
It's better than const char* because any interaction between const char*
and QString assumes that const char* contains UTF-8, which is
pessimistic and therefore inefficient; at the same time:
- construction of QString from QLatin1String is extremely fast
(boiling down to padding null bytes)
- "something"_ls is much shorter than QStringLiteral("something")
- "something"_ls produces a direct pointer to the literal at compile
time, using the benefits of raw string literals (deduplication, e.g.)
The library API will also transition to QLatin1String where applicable,
likely in 0.8.
|
|
- Templates and constexpr imply inline
- A function called from a single site better be inlined.
|
|
|
|
It doesn't need all those things inside - order_type alias is no more
in use; operator<() is better outside; QLatin1String is better to
compare against than const char* (because const char* is assumed to be
UTF-8); and TagRecord is really small so it doesn't need const& for
parameters.
|
|
Those are already inherited with 'using'.
|
|
|
|
|
|
On Windows QUOTIENT_API expands to different things depending on whether
the library is built or used. This results in confusing statements (and
MSVC erroring out on them, in some cases - see below - quite
legitimately) not only when the application includes Quotient headers
but also when the application defines custom events and uses
REGISTER_EVENT_TYPE to make them creatable from /sync responses.
To avoid repeated registration when dynamic linking is involved,
EventFactory<>::addMethod() now bluntly looks up the method for this
type in the vector of already registered methods. It would surely be
quicker to use a static variable instead; but since the refreshed API
for addMethod returns a reference to the factory method it's necessary
to do this lookup anyway. Once the primary goal of this branch is
achieved across platforms I might experiment with lighter ways to
register factory methods; for now here's a minimal change to make
the code build on Windows.
|
