Age | Commit message (Collapse) | Author |
|
This will provide some backwards-compatibility to clients that are not ready to move _their_ code to C++14 (at least, it will allow them to not add C++14 requirement to their makefiles as of yet).
|
|
This prepares the backend to enable timeouts/retry intervals configurable from clients.
|
|
|
|
Old GCC was still invoked; qmake-based builds weren't switched to C++14.
|
|
Also a bit of code tightening with some C++14 (but not only) things.
|
|
|
|
Because we should practice what we preach in CONTRIBUTING.md.
|
|
|
|
|
|
|
|
|
|
|
|
Because that's what it really is.
|
|
Otherwise they stick around when deleting actual settings (e.g. at logout).
|
|
Because the respective parameter in /login result is deprecated. Closes #137.
|
|
So that clients could start using this object without waiting for the next sync.
|
|
Because a missing return in a non-void function is always an error.
|
|
Closes #135.
|
|
|
|
|
|
This fixes compilation with older compilers that try to instantiate a copy constructor (and fail because unique_ptr) but actually is more proper in general. Also: do not advertise the class as Q_MOVABLE_TYPE: this was useful for QList/QVector when SyncRoomData was copyable; now it isn't, and Qt containers can't deal with non-copyable classes at all.
|
|
|
|
|
|
|
|
This causes the following changes along the way:
- Owning<> template is decommissioned.
- event.h has been rearranged, and Event/RoomEvent::fromJson static methods have been replaced with an external makeEvent<> function template. A side effect of that is that one cannot use a factory with a type other than the one it's defined for (i.e. you cannot call makeEvent<TypingEvent>) but that feature has been out of use for long anyway.
- Room::doAddNewMessageEvents() and Room::doAddHistoricalMessageEvents() have been removed, giving place to Room::onAddNewTimelineEvents() and Room::onAddHistoricalTimelineEvents(). The most important difference is that all code that must be executed now resides in addNewMessageEvents() (it moved from Room to Room::Private) and classes inheriting from Room are not obliged to call the overridden function from the overriding function (they can do it but those functions have empty bodies in Room). This was a long overdue change, and owning pointers simply mandated it. Room::onAddNewTimelineEvents/onAddHistoricalTimelineEvents should not do anything with the passed range in terms of ownership, it's just a way to allow the derived class to update his data in due course.
- Room::Private::dropDuplicateEvents() and Room::Private::insertEvents(), notably, have been updated to work with owning pointers. insertEvents() move()s pointers to the timeline, while dropDuplicateEvents uses remove_if instead of stable_partition and doesn't explicitly delete event objects.
Also, a bugfix: Event accidentally had not virtual destructor for quite a long time. According to the standard, deleting an object through a pointer to a base class without a virtual destructor leads to UB. So the fact that libqmatrixclient clients even worked all these months is mere coincidence and compiler authors good will :-D
|
|
|
|
|
|
|
|
Closes #130.
|
|
|
|
The Spec doesn't mention it but both Synapse and Riot act as if origin_server_ts was whitelisted, and it was also confirmed in #matrix-dev to be reasonable behaviour.
|
|
|
|
Closes #118
|
|
This only applies to new messages; historical redaction events are just skipped because historical events are already redacted on the server side. Closes #117.
|
|
A RoomEvent now has an optional pointer to a RedactionEvent that is non-null if the room event is redacted. transactionId and serverTimestamp are only filled if the event is not redacted. There's no way to construct a redacted event as of yet.
|
|
Will be used in Room to work with ranges of events.
|
|
|
|
Rewire Connection::postReceipt() to the generated job too; this call is still deprecated though.
|
|
|
|
|
|
|
|
|
|
|
|
notifications and others
Closes #128 (the issue has the full list of jobs arriving herewith).
|
|
|
|
appropriate
Body inlining is needed in content-repo cases and also cases with freeform JSON in the body (such as the one of upcoming PostReceiptJob).
|
|
notifications and others
Closes #128 (the issue has the full list of jobs arriving herewith).
|
|
This is needed to support cases of content-repo, where the request/response bodies are not JSON.
|
|
|
|
|