| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Connection::getThumbnail(QString,...) is better fitting to retrieve
images for QML image providers - one doesn't need to create a QUrl
(which if made naively ends up being incorrect) and also doesn't need to
stack up "mxc://" before the mediaId. Just call Connection::getThumbnail
with the id the QML engine gives you.
|
|
Closes #149.
|
|
|
|
|
|
|
|
Because that's what it really is.
|
|
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.
|
|
Rewire Connection::postReceipt() to the generated job too; this call is still deprecated though.
|
|
|
|
|
|
|
|
It's now camelCase everywhere, even if The Spec uses snake_case (it is
not consistent in that respect).
|
|
"Needed" means when the current HS URL is invalid even by its outlooks. If it is just inaccessible, no attempt to fix things will be made. This breaks compatibility with previous library behaviour because connectWithToken historically has been fully synchronous and clients depend on that. connectWithToken _may_ work synchronously if HS URL is good enough; but this is no more guaranteed. Moreover, in the future the server will be probed via /versions before working, so connectWithToken will become entirely asynchronous.
|
|
Closes #119; many thanks to @r0kk3rz for prodding me into that.
|
|
|
|
This impacts the cache as well, as we don't save state_keys for most
state events.
|
|
The idea is simple: store a version in the cache; if, upon the next load, the (major) version is too old, the cache is discarded. The currently used version values (0.0) do not discard the cache; but the next commit will bump the (major) version.
|
|
The original comment got a bit rotten, so refresh it as well.
|
|
|
|
|
|
LoginJob
This is _almost_ a backwards-compatible change, except that connect*()
and other relevant methods in Connection are no more virtual (that
wasn't much useful anyway). Otherwise it's a matter of passing
initial_device_name to connectToServer(), saving device_id (along with
access_token) from the result of LoginJob and then passing device_id
(along with access_token, again) to connectWithToken() upon the next run.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
The property controls whether or not the rooms state is cached: if it's off, loadState() and saveState() become no-ops. Other changes:
* loadState/saveState properly deal with rooms in Invite state (this is not quite relevant to the current branch but very much is in the light of a concurrent kitsune-invite-kick PR);
* Profile loadState/saveState (because dumping and especially parsing JSON takes time);
* Use QJsonDocument::Compact layout, it's about 3 times smaller and quicker to parse than Indented, and we really don't care about the cache being human-friendly;
* Have a default path for the state cache, based on the connection's user id.
|
|
Notably:
* setJoinState() invocation has been missing from the previous code
* processing invites did not take into account that a Leave state may already exist, thereby forcing clients that display left rooms to look through their records just in case they have to replace a Leave with Invite.
* joinedRoom() was emitted even when the room is not newly joined.
|
|
joinedRoom() and leftRoom() now pass the preempted Invite state of the
room as well; roomMap() only returns Invite and Join rooms, not Leave.
|
|
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.
|
|
Instead of createUser() and createRoom() virtual functions, use std::function<> to store predefined lambdas that would create respective descendants from User and Room, respectively. No more need QuaternionConnection just for the sake of creating a QuaternionRoom.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 generation algorithm doesn't support several Quaternions using the same accessToken, as of yet.
|
|
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
|
