| Age | Commit message (Collapse) | Author |
|---|
|
Receiving and caching m.direct (and other non-room account data along the way); Connection::addToDirectChats/removeFromDirectChats (might get siblings in Room eventually but not now), Connection/User::requestDirectChat. Closes #163.
|
|
To be able to get all available tags throughout the connection.
|
|
Closes #134.
|
|
|
|
|
|
It's still an open question whether it's better to store a separate
sorted index of users, next to an unsorted one; but a sorted list of
users is of much more use in GUI than an unsorted one.
|
|
|
|
|
|
createRoom and createUser renamed to roomFactory and userFactory
(because createRoom will mean a different thing); unneeded #include
moved to the cpp file.
|
|
|
|
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.
|
|
|
|
|
|
Because that's what it really is.
|
|
|
|
This is for the same reason as Connection::getThumbnail() - it's the only non-template (hence, supported by QML and Qt queued signal connections) way to invoke joining a room.
|
|
"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.
|
|
Connection::getThumbnail() should not have been deprecated because it's the only way to request a thumbnail using an event loop (i.e. from QML or via QMetaObject::invokeMethod).
|
|
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.
|
|
|
|
|
|
So that even uncopyable types could be used for parameters; also fixed a typo in util.h that prevented dispatch() from using with multiple argument functions.
|
|
Having to pass ConnectionData to each and every job class was nothing but boilerplate since the very beginning. Removing it required to prepend BaseJob::start() with ConnectionData-setting code, and to provide a way to alter the request configuration depending on the (late-coming) ConnectionData object. This is a new responsibility of BaseJob::start(); the previous BaseJob::start() contents have moved to BaseJob::sendRequest() (which is now invoked on retries, instead of start()).
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
|
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.
|
|
When SyncJob retries, networkError is emitted; if it fails entirely, either loginError or syncError, depending on the kind of failure.
|
|
|
|
As of now, the retry logic (see BaseJob::finishJob() method) invokes the same network request several times with increasing timeouts and retry intervals. Some additional signals and accessors are also provided to control the behaviour from inheriting classes (see a notable example with SyncJob in the same commit) and clients (support of retries in Quaternion comes in a respective commit shortly).
|
