| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Rewire Connection::postReceipt() to the generated job too; this call is still deprecated though.
|
|
|
|
|
|
This impacts the cache as well, as we don't save state_keys for most
state events.
|
|
* StateEvent<> is a new class template for all state events. It provides a uniform interface to the state content, as well as a means to serialize the content back to JSON. In addition, StateEvent now parses the "prev_content" JSON object, so one can refer to the previous state now (a notable step to proper reflection of state changes in the displayed timeline in clients).
* EventContent::SimpleContent, together with StateEvent<>, forms a generalisation for simple state events, such as room name, topic, aliases etc. that boil down to a single key-value pair. DECLARE_SIMPLE_STATE_EVENT is a macro defined to streamline creation of events based on SimpleContent, providing API back-compatibility for events defined so far. As a result, a very concise simplestateevents.h replaces all those room*event.* files.
* Event/RoomEvent::fromJson() code is squeezed down to plain type lists passed to makeIfMatches() "chained factory" function template. TypeId is mandatory for an event type to be included into that factory.
* Event::toTimestamp() and Event::toStringList are completely superseded by respective fromJson<>() converters.
|
|
|
|
|
|
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).
|
|
Display name is a calculated thing, name is received from the server.
|
|
|
|
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
|
|
The CS API, turns out, has a quite official extension point inside m.read event content - clients are allowed to put whatever extra data they feel reasonable.
|
|
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.
|
|
|
|
|
|
Otherwise, users are doomed to stay avatarless upon restoration, until they update avatars again.
|
|
|
|
It's a case when the last-read-event id refers to an event that was outside the loaded timeline and has just arrived. Depending on what messages follow the discovered last-read one, we might need to promote the read marker and update unreadMessages flag. The latter is especially relevant in our current situation when empty timelines upon the application startup are a norm.
|
|
|
|
Since there's no such thing as "unread messages flag" in the CS API spec, there's now a non-standard key-value in cached m.read receipts for that.
|
|
The previous version constructed QString from const char* and QByteArray
parts,
only to convert it back to QByteArray; the current version
does the whole thing in QByteArray terms.
|
|
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
|
|
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 greatly reduces the noise made by quaternion.
To enable full logging, export the following variable:
QT_LOGGING_RULES="libqmatrixclient.*.debug=true"
|
|
|
|
Because it's a recommended by Qt method to sort end-user-facing lists.
|
|
|
|
Room names conflicts should be handled at the client level, for example
by displaying the canonical alias in a tooltip or in the custom
delegate of the view.
If we extend the display name algorithm at the lib level, we
are just cluttering the display name in the most common scenario
(i.e. when there are no name clashes).
|
|
|
|
This will be used from Quaternion for a better algorithm dealing with read markers
|
