| Age | Commit message (Collapse) | Author |
|---|
|
Objects derived from Event are not room events (in the spec sense) and
never occur in the same arrays as room events; therefore this chaining
has always been superfluous.
|
|
Another forgotten header file.
|
|
|
|
Also: extended quotest to cover member renames, not just user profile renames.
|
|
Add autotests to CI
|
|
CMAKE_INSTALL_RPATH_USE_LINK_PATH is more universal than setting LD_LIBRARY_PATH
Also: drop an extra slash in the path to installed quotest.
|
|
This covers Quotient_INSTALL_TESTS setting.
|
|
|
|
It turned out that, confusingly, ${{ runner.workspace }} refers to
the directory above $GITHUB_WORKSPACE, which is why the previous commit
ended up with valgrind not finding its suppressions.
|
|
|
|
Those tests don't even need an event loop.
|
|
|
|
|
|
Also, RoomAliasesEvent is to be completely gone after 0.7.
|
|
These were missing from the commit introducing .h files to sources,
highlighting the reason why .h files should be there...
|
|
There was that ugly workaround in CMakeLists.txt to produce the list of
files to be formatted and making a separate build target for
clang-format. As GTAD 0.9 calls clang-format itself this workaround is
no more necessary; generate-unformatted-api and format-api build targets
are now gone, and clang-format is no more one-build-system-configuration
behind GTAD on the list of files to handle.
|
|
This is driven by the change in the way Qt Creator 6 works with CMake
(see https://www.qt.io/blog/qt-creator-6-cmake-update) that basically
requires you to explicitly add header files as source files. While this
obviously added to the size of the source files list, it also drove
dropping the repeated file(GLOB_RECURSE ... CONFIGURE_DEPENDS) call
which added a considerable speedbump to the beginning of each build
(now that call is just one).
|
|
|
|
Quotient::function_traits<> did not support member functions in a proper
way (i.e. the way std::invoke_result<> treats them, with the function's
owning class represented as the first parameter). Now that I gained
the skill and understanding in function_traits<> somewhat wicked
machinery, I could properly support member functions. Overloads and
generic lambdas are not supported but maybe we'll get to those one day.
|
|
It has not much to do with the Visitor design pattern; also,
std::visit() has different conventions on the order of parameters.
|
|
|
|
There was a lot of excess redirection in fromJson() and toJson() with
most of JsonConverter<> specialisations being unnecessary boilerplate.
These have been replaced by overloads for toJson() and explicit
specialisations for fromJson() wherever possible without breaking
the conversion logic.
|
|
Turns out it's been deprecated by -Wextra since before Quotient existed.
|
|
Proper linters recognise that the returned types are not primitive,
while people might still be confused a bit.
|
|
In both fixed cases the callee accepts a const reference, which makes
std::move() useless. Static analyzers apparently missed them because
the cases are inside a macro.
|
|
It's might look weird; but without making fromJson() a specialisation
it becomes an overload next to an implicit specialisation of
the template function defined just above, and then loses to that
specialisation because it (also) has the perfect match.
(would be great if the compiler shaded the implicit specialisation in
such cases - alas it's not how the standard works.)
|
|
|
|
Similar to contentPart() - apparently there are enough places across
the code that would benefit from it.
|
|
Given that QJsonObject only accepts QStrings in the list constructor,
the template is useless cruft.
|
|
|
|
There's a clash between Event::content() (a template function) and
RoomMessageEvent::content() (plain member). Out of these two, the name
more fits to the RME's member function - strictly speaking,
Event::content() retrieves a part of content, and so is renamed.
In addition, contentPart() defaults to QJsonValue now, which is pretty
intuitive (the function returns values from a JSON object) and allows
to implement more elaborate logic such as
if (const auto v = contentPart<>("key"_ls); v.isObject()) {
// foo
} else if (v.isString()) {
// bar
} else {
// boo
}
|
|
|
|
New issue templates reside under .github/
|
|
|
|
|
|
This is useful for implementing Spaces support, where all events of
type `m.space.child` are needed, and we don't know their state keys in
advance.
|
|
The problem is in Room::processStateEvent(): after
potentially-inserting-nullptr into currentState, pre-check failure
(that may occur on member and trigger events for now) leaves that
nullptr in the hash map. Basically anything that uses currentState
(e.g., Room::toJson) assumes that currentState has no nullptrs - which
leads to either an assertion failure, or nullptr dereferencing. The fix
removes the nullptr placeholder if the pre-checks failed.
|
|
Trying to test bits with Changes::testFlag(Change::Any) was a bad idea.
Along the way: made logging in setLastReadReceipt() refer to the actual
timeline item when possible.
|
|
Doesn't really help build times, instead breaking the build on older Qt.
|
|
The "original JSON" wording is misleading: the returned JSON can be and
is routinely edited as a part of event construction, redaction, editing.
Also, originalJson() name is misleading in that it returns a stringified
(in a very specific way) JSON and not an object. You have to call
fullJson() to get the object, and originalJsonObject(), confusingly,
returns exactly the same thing but as a value rather than as
a reference. The original intention of keeping originalJsonObject() was
to make it Q_INVOKABLE or use it as an accessor for a Q_PROPERTY.
unfortunately, this was never really practical as discussed in
the previous commit.
All that implies that clients have to handle passing event JSON to QML
themselves, in the form they prefer (as an object or a string). The
added complexity is negligible though; on the other hand, there's added
flexibility in, e.g., choosing a compact instead of default JSON layout
or even generate a highlighted JSON representation.
|
|
Makes compilation a tad lighter.
|
|
Q_GADGET is generally used to enable two things outside of QObject:
Q_PROPERTY/Q_INVOKABLE and Q_ENUM/Q_FLAG. While the latter can be used
in its own right in QML, the former requires Q_GADGET instances to be
passed to QML by value, which is not really possible with
uncopyable/unassignable classes. Bottom line is that Q_PROPERTY in
anything derived from Quotient::Event is not viable, making Q_GADGET
macro useless unless there's a Q_ENUM/Q_FLAG (as is the case with
RoomMessageEvent, e.g.).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[skip ci]
|
