| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes #134.
|
|
Enables to address QMatrixClient/Quaternion#284. Also fixes a gibberish condition in Room::Private::renameMember() that led to improper warnings and a too early return.
|
|
Room::user() came instead of Room::Private::member() and memberJoinState() came instead of Private::hasMember.
|
|
Closes #168.
|
|
Works (at least, should work) with both Qt Widgets and QML.
|
|
|
|
To make it easy to use User objects and fetch room and user avatars from QML. Closes #155.
|
|
To make debugging (including QML debugging) more convenient.
|
|
This is needed for QML integration. Closes #155.
|
|
|
|
Closes #151.
|
|
This code is useful for all clients, and extensions to pretty-printing
can be later added either via making prettyPrint() virtual or even by
providing a registry of additional "text transformers" or even "event
content renderers" applied to visualise the event.
|
|
Closes #121; closes #122.
|
|
and User
The switch is necessary because MediaThumbnailJob is supposed to return something that can be worked on in non-GUI threads (as is the case of QML image providers), and QPixmap is not supposed for usage out of the main thread.
|
|
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).
|
|
Also a bit of code tightening with some C++14 (but not only) things.
|
|
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 #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.
|
|
|
|
|
|
|
|
The events are detected in /sync output, and avatars for rooms are loaded from respective URLs. Clients can use Room::avatar() method to request a pixmap of a certain size, and react to avatarChanged() in order to update the UI when new pixmaps/avatars arrive. avatarChanged() signal is overloaded with two tasks - the first firing merely indicates that a new avatar is available (without actual pixmap yet available) while the second firing means that an actual pixmap has arrived (all this is entirely transparent for clients, they just should update their pixmaps from Room::avatar() every time when Room::avatarChanged() is emitted).
|
|
|
|
Notably:
* API for SendEventJob and SetRoomStateJob has been altered to accept references, not pointers.
* Methods on Room that invoke requests to the server, have lost const, because they may be reflecting the changed state on the fly, within themselves
|
|
Closes #38. Also rearranged #includes
|
|
A cref is still faster than incrementing a refcounter in QString, and all the other COW stuff, and room id is not supposed to change ever.
|
|
|
|
|
|
|
|
Kicking and inviting use generated job classes. Rooms in Invite state are stored separately in the hash from those in Join/Leave state because The Spec says so. For clients, this means that the same room may appear twice in the rooms map if it's been left and then the user was again invited to it. The code in Quaternion that properly processes this will arrive shortly.
|
|
|
|
|
|
|
|
|
|
1. PostMessageJob is now SendEventJob, which reflects two things: first, it's a PUT instead of a POST (POST for /send is not supported by the latest spec anyway), so that we could enable tracking transaction ids for local echo in the near future; second, it's no more just about messages, the job can support sending any room events (topic changes etc.).
2. Room::postMessage() now uses the new RoomMessageEvent API to send m.room.message events.
|
|
|
|
|
|
The biggest change is we have no pimpls in Event objects anymore - because it's two new's instead of one per Event, and we have thousands and even more of Events created during initial sync. The other big change is introduction of RoomEvent, so that now the structure of events almost precisely reflects the CS API spec. The refactoring made UnknownEvent unnecessary as a separate class; a respective base class (either RoomEvent or Event) is used for this purpose now. All the other changes are consequences of these (mostly of RoomEvent introduction).
|
|
After adding some profiling it became clear that to recalculate the room name and emit namesChanged() upon each member event is a waste, especially when there are thousands of those coming at initial sync (*cough* Matrix HQ room). So the room name is recalculated only once and unconditionally (in most cases this will boil down to checking whether name/canonicalAlias changed after processing the events batch), and namesChanged is only emitted once per batch, if any name or alias changed.
|
|
introduced; Connection and Room cleanup
Helps to better encapsulate Room
|
|
It's just natural, after all, Connection is a parent of Room. But seriously, this will be needed when we have rooms from different Connections living next to each other.
|
|
Mainly it's about const-ification (in particular, passing const-refs instead of values) and deleting unneeded declarations/#includes. Since the changes alter the external interface, this is submitted as a PR for peer review.
One of unneeded declarations/definitions is a virtual destructor in BaseJob descendants. Since a job object should be deleted through QObject::deleteLater() anyway (and it's the only correct way of disposing of the object), all deletions will call the stack of destructors through virtual QObject::~QObject(). Therefore even BaseJob could get on with a non-virtual destructor but for the sake of clarity BaseJob::~BaseJob() is still declared virtual.
|
|
|
|
|
|
|
|
This will be used from Quaternion for a better algorithm dealing with read markers
|
|
timeline + no more discarding read markers to events that haven't arrived yet
When using deque::const_reverse_iterator for read markers and eventsIndex, I didn't realise that insertions into std::deque invalidate iterators (though preserve references and pointers). Therefore, a small TimelineItem class has been introduced that stores an event together with a persistent index that is generated upon insertion into the timeline (timeline.back()+1 for newer events, timeline.front()-1 for older events). Using such indices, we can still reach an event by it's index in constant time, while avoiding a problem with invalidating iterators.
While rewriting the code, another problem has been detected with read markers to events that haven't yet arrived to the timeline (in particular, older events). The old code simply discarded such read markers. The new code stores such read markers anyway, so that when that event arrives, it could be matched against the stored last-read-event id.
|
