| Age | Commit message (Collapse) | Author |
|---|
|
|
|
return it
This better fixes the contract for derived job classes and simplifies error reporting. Methods error() and errorString() are kept for back-compatibility; status() returns a combination of them, conveniently packed into a Status object. For a quick status check, Status::good() is provided.
|
|
|
|
BaseJob
1. The externally (for derived classes) visible additions are checkReply() and parseReply() virtual methods, with gotReply becoming a mere dispatcher (and therefore a private method). Splitting gotReply() in that way allowed to remove boilerplate code from MediaThumbnailJob.
2. The internal tweak is using QScopedPointer<> to store pointers both to the Private object and to a QNetworkReply (with a special deleter that aborts the reply before destructing the object). This allows to remove desperate attempts to call reply->abort() wherever it's no more needed (and not aborting the in-flight replies seems to be a/the culprit of Quaternion after-exit hangs).
|
|
Some parts of the code were copied from the KCoreAddons sources - surprisingly few, in fact, mostly API with comments. With this commit, libqmatrixclient doesn't depend on KCoreAddons.
|
|
|
|
Due to signal-slot processing it's not obvious when exactly each job object is deleted.
|
|
of access denial
|
|
The job calls the /logout endpoint of CS API that invalidates the passed
access_token; a respective Connection::logout() method and
Connection::loggedOut() signal are added for use in clients.
|
|
well + stability fixes
1. Introduce ContentAccessDenied error code to BaseJob to allow clients to treat access denial errors differently from other network errors.
2. Since parseJson() overrides are responsible for calling emitResult(), the "default" BaseJob::parseJson() should call emitResult() as well.
3. Make sure BaseJob::fail() doesn't crash in absence of QNetworkReply.
|
|
|
|
|
|
Previously Room::Private used to have a gotMessages() slot; now that it doesn't, it doesn't need to be a QObject either.
|
|
The license header in the source files says we ship a copy of the LGPL
which we didn't.
|
|
|
|
|
|
|
|
Relax the Qt requirements down to 5.2.0
|
|
Code tweaks
|
|
|
|
data()
Thanks to CLang model.
|
|
And we don't need two log lines for timeouts.
|
|
1. Introduce QDebug manipulators and formatJson manipulator in particular - this allows to accommodate some changes in Qt's debug printing behaviour between versions.
2. Show JSON for some questionable objects (UnknownEvents, events with no event_id etc.)
3. Log the list of typing users and the user id when getting an avatar.
|
|
|
|
In a case when authentication doesn't even happen, PasswordLogin job
won't run. The better place to assign (and log) the token is in
Connection::connectWithToken(), therefore.
|
|
Load a different set of event lists depending on the join state (and actually introduce EventList class)
|
|
actually introduce EventList class)
This makes loading of room events more compliant with the spec, not trying to load from keys that are not supposed to be there. As a result of refactoring along the way, a dedicated QList<Event*> subclass is made that remembers the JSON key it should load from and actually load itself from a QJsonArray.
|
|
Introducing EventList class + minor fix
|
|
Now you can parse a JSON array into a list of events with a one-liner.
Also, fromMSecsSinceEpoch accepts a qint64, not quint64 - fixed the respective cast.
|
|
Basejob improvement
|
|
|
|
|
|
|
|
destruction of the job
|
|
This is to facilitate processing of job results (see further commits).
|
|
Render display names of users and rooms according to the spec - take 2
|
|
signal, which clients should use in the room context.
Processing changes of user displaynames is tricky: we have to not only deal with the currently renamed user but also with its past and new namesakes which might change representation due to that renaming. So in the worst case a single User::nameChanged signal may lead to three Room::memberRenamed references (and 3 user displaynames updated in the UI, respectively). And the newly added users should be taken care of in a similar manner, of course.
|
|
(as requested at PR review)
|
|
a displayname update.
This changes the way displayname is supplied to a client application - instead of calculating immediately, displayname becomes a separate stored value that is refreshed with every change of the list of members, or the name, or the canonical alias. displaynameChanged signal is supplied to subscribe to these updates: in case of displaying a room in the roomlist a client should use this new signal instead of Room::namesChanged.
The displaname calculation algorithm is described in section 11.2.2.5 of the CS spec: https://matrix.org/docs/spec/r0.0.1/client_server.html#calculating-the-display-name-for-a-room
|
|
|
|
|
|
According to section 11.2.2.3 of the CS spec, clients SHOULD follow a certain algorithm of making a non-ambiguous display name of a user in the room context. This algorithm implies checking whether other room members have the same display name. This commit prepares for implementation of the algorithm:
1. Use a hash map instead of a list to store room members. The external Room::users() API is kept intact.
2. Convenience CRUD methods are implemented to deal with the hash map.
3. An additional slot for user renaming is introduced (because renaming affects the hash map). Binding of actual signals is left for the next commit.
4. nullptr is the recommended representation of a null pointer since C++11. Use that and mandate compiler support of that.
|
|
|
|
In particular, this will be needed to render room names according to the CS spec.
|
|
|
|
Resolve Matrix SRV records.
|
|
|
|
|
|
|
|
|
