| Age | Commit message (Collapse) | Author |
|---|
|
Notably:
- simplified unnecessarily verbose constructs;
- formally aligned (no re-numeration was necessary)
QOlmMessage::Type with corresponding OLM_ constants;
- dropped QOlmSession::encryptMessageType() because it's very
sensitive to the order of calling with QOlmSession::encrypt()
(and encrypt() itself already calls it and returns the message
type);
- simplify the return type of pickle() calls that can only fail due to
an internal error;
- replace const QString& with QStringView or const QByteArray&
where appropriate;
- use '\0' where it was meant to be instead of '0'.
|
|
QOlmError represents a subset of OlmErrorCode, and the associated
fromString() function uses undocumented strings produced inside Olm;
meanwhile OlmErrorCode is documented in its own header file. Each QOlm*
class now has lastErrorCode() next to lastError() (that, from now,
returns a textual representation straight from Olm, not QOlmError enum).
Also: including olm/error.h in e2ee/e2ee.h required some rearrangement
of the code to make sure non-E2EE configuration still builds.
|
|
As of the current GHA jammy image, Valgrind cannot cope with some
of Clang 14 output: https://bugs.kde.org/show_bug.cgi?id=452758
This is most likely a band-aid, before the work on switching from
Valgrind to ASan.
|
|
This is the earliest version shipping olm/error.h. Conversely, stock
libolm that comes with Ubuntu 20.04 (version 3.1.3) is no more enough
so CI completely switches to jammy now.
|
|
Too many suggestions to add, e.g., * in places where it may eventually
be a smart pointer.
[skip ci]
|
|
This tries to fix getting stuck at exit since NAM has been switched
from QThreadStorage to thread_local
|
|
[skip ci]
|
|
|
|
Previously moc choked on [[attributes]]; deprecated signals, slots etc.
were documented as \deprecated instead. By Qt 5.15, that was fixed.
|
|
|
|
Previous logic wasn't quite accurate with detection of existing flags
in CMAKE_CXX_FLAGS - the new code doesn't add a flag if the negating
flag is already there. This required separate treatment of positive
and negative (-Wno-*) flags.
|
|
|
|
It's more straightforward in usage and less prone to leaks
(QThreadStorage doesn't delete objects when on non-main thread).
|
|
|
|
|
|
|
|
|
|
Key verification events gain their own base type and
KeyVerificationSession gets a single point of entry for all kinds of
incoming events. This allows to drop a pile of `incoming*` signals in
Connection and a stack of options inside switchOnType in
processIfVerification(). KVS::handleEvent() also makes (some) allowed
state transitions a bit clearer.
|
|
There's a bit convoluted stack of calls involved here, worth laying out.
C++ containers are loaded from JSON containers by calling fromJson<>
on each element of the JSON container, specialised by the element type
of the C++ container. If that element type is not itself an object
(e.g., QString), the respective specialisation of fromJson<> is supposed
to kick-in and override the default template that delegates the
conversion to JsonConverter (which in turn falls back to
JsonObjectConverter unless specialised for that type). Because template
functions cannot be partially specialised, that specialised overload
for, say, QString, is not complete: it accepts QJsonValue but anything
except QJsonValue will hit the generic overload instead. That makes the
whole fromJson<> machinery quite sensitive to the exact JSON type passed
to it; but as of Qt 5, the types actually presented to fromJson() were
limited to QJsonValue and QJsonDocument (okay, QJsonObject and
QJsonArray could also be there but the QJsonObject case is trivial
for JsonConverter and containers loaded from QJsonArray are all caught
with JsonArrayConverter).
Qt 6 started returning (const) QJsonValueRef from
`QJson*::const_iterator::operator*()` - meaning that whenever a simple
type (like, again, QString) is loaded within the bigger container,
the "wrong" fromJson() gets called. To fix this, JsonObjectUnpacker
gained a dedicated function to unpack QJsonValueRef. QJsonValueRef is
an old name existing since Qt 5.15 - no big pain. However, in Qt 6.4
QJsonValueConstRef is getting introduced for the same purpose. It's
possible to wrap the *Ref overloads in some #if/#else brackets but at
that point it becomes easier to just produce QJsonValue from whatever
QJson* iterators dereference to.
|
|
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
The new MSVC preprocessor is needed to correctly deal with variadic
macros defined in .h files, so the respective compiler switch has to be
added when building depending projects too.
|
|
With CMAKE_INSTALL_LIBDIR set to ".", the place .cmake files land in
was not discoverable by find_package(), assuming a conventional
CMAKE_PREFIX_PATH.
|
|
Since C++17, parentheses only work when a constructor is there, while
braces allow both calling a constructor and aggregate initialisation.
|
|
|
|
|
|
|
|
Ironically, this slicing would not break anything as all the necessary
data are saved in the Event parent class; but the code is very fragile
and scary.
|
|
Streamline event types, part 2
|
|
I guess it was simply overlooked originally; in any case, currently
used compilers deal with the reference just as fine as with the pointer.
|
|
TagEvent is only created to immediately extract content JSON from it;
at the same rate content JSON can be generated directly from content.
|
|
Now that StateEvent name is vacated, the naming for event core classes
can be completely unified: Event, RoomEvent, CallEvent, StateEvent.
|
|
Constrain types to derive from Event (or the chosen class), where
applicable.
|
|
Direct construction (using makeEvent() or explicitly constructing
an event) from JSON may create an event that has a type conflicting
with that stored in JSON. There's no such problem with loadEvent(),
even though it's considerably slower. Driven by the fact that almost
nowhere in the code direct construction is used on checked JSON
(one test is the only valid case), this commit moves all JSON-loading
constructors to the protected section, thereby disabling usage of
makeEvent() in JSON-loading capacity, and switches such cases across
the library to loadEvent().
|
|
These are small enough to comfortably reside in a single translation
unit.
|
|
This gives a more conventional API compared to queryOr() that can be
used for event objects that have content() defined - with the downside
being that content() unpacks the entire object instead of retrieving
one particular piece (but for state events and single key-value content
it's not a problem, and those make for the vast majority of events).
|
|
|
|
We don't expose logging internals to the outside world.
|
|
|
|
|
|
This commit introduces a few things to further reduce the boilerplate
across event type definitions:
- Event type is no more separately stored in Event and therefore no more
passed to base event constructors. Until the previous commit, it was
used by is() to quickly match the event type; with the new event
metatype class, the same is achieved even quicker by comparing
metatype pointers.
- EventTemplate is a generalisation of StateEvent for all event types
providing common constructor signatures and content() for (most) leaf
event types. StateEvent therefore has become a partial specialisation
of EventTemplate for types derived from StateEventBase; as the known
client code base does not use it directly, a compatibility alias is
not provided. Also, DEFINE_SIMPLE_EVENT now expands into a class
deriving from EventTemplate.
- On top of StateEvent->EventTemplate specialisation,
KeyedStateEventBase and KeylessStateEventBase types are introduced
with appropriate constructor signatures (with or without state_key,
respectively) to allow `using` of them from derived event types.
To facilitate writing of constraints, concepts for keyed and keyless
state event types are also introduced; RoomStateView, e.g., makes use
of those to provide appropriate method signatures.
- typeId(), unknownEventTypeId(), UnknownEventTypeId are no more
provided - they weren't used throughout the known code base
(Quaternion, NeoChat), and the concept of "unknown event types" is
hereby eliminated entirely.
- RoomKeyEvent no more accepts senderId as a parameter; it has never
been a good practice as the sender is assigned by Connection anyway.
|
|
The new metatype framework replaces
EventFactory/DEFINE_EVENT_TYPEID/REGISTER_EVENT_TYPE; it is faster,
more functional and extensible. Of note:
- EventMetaType mostly reproduces the logic of EventFactory but supports
custom base event types not just for loading (that part EventFactory
also supported) but also for matching - previously you had to have
Event::is*Event() for base type matching. Now Quotient::is() can
match against both base and leaf types.
- Instead of DEFINE_EVENT_TYPEID and REGISTER_EVENT_TYPE there's now
a single macro, QUO_EVENT, intended for use in the way similar to
Q_OBJECT. Actually, the entire framework borrows heavily from
QMetaObject and Q_OBJECT. Making event types full-fledged QObjects
is still not considered because half of QObject functions would not
be applicable (e.g. signals/slots) while another half (in particular,
using Matrix type ids to select event types) would still have to be
done on top of QObject. And QML can just access events as
const QJsonObjects which is arguably more lightweight as well.
- QUO_BASE_EVENT is a new macro replacing EventFactory object
definitions. This was necessary for the same reason why Q_OBJECT is
a macro: aside from a static object definition, this macro
introduces a virtual function override to resolve the metatype at
runtime. This very mechanism is used to make event type
matching/casting as quick as possible
- QUO_BASE_EVENT and QUO_EVENT use the C++20 __VA_OPT__ feature that
is only available with the new MSVC preprocessor (see
https://docs.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview);
the respective switch was added to CMakeLists.txt.
|
|
|
|
SingleKeyValue is a tiny wrapper and supposed to be discreet.
Having to explicitly (even if only with braces) construct its objects
stands in the way of readability on the consuming side of the code and
sometimes prevents direct initialisation of event objects without
constructors getting some kind of ContentParamTs parameter pack where
a single content_type argument would suffice otherwise.
|
|
[skip ci]
|
|
|
|
|
|
QByteArrays don't like interacting with QStrings
|
|
|
|
|
