Age | Commit message (Collapse) | Author |
|
The previous one didn't cover all the cases; the current one seems to do. Closes #192. Accompanied by the developer's notes at: https://github.com/QMatrixClient/libqmatrixclient/wiki/unread_count
|
|
|
|
|
|
Basically, the whole requestDirectChat() body has been moved and generalised to doInDirectChat(), and requestDirectChat() delegates to doInDirectChat(). The logic has been updated to cope with formerly left/forgotten rooms present in the list of direct chats (cleaning up the list along the way).
|
|
The asynchronous update first implemented was more verbose and caused
more problems than provided solutions. The idea was that the internal
directChats map would better reflect the server state if updated
asynchronously. However, it also causes a local race condition; e.g., to
quickly remove rooms from direct chats one after another becomes very
non-trivial (one has to wait until the previous operation succeeds). So
after some playing with the code, hitting pitfalls along the way, I
decided to align the logic with the one for room tags; synchronously
issued signals look uglyish but at least work predictably. And race
conditions between several clients generally cannot be cleanly resolved
anyway.
|
|
|
|
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.
|
|
|
|
enough
|
|
|
|
|
|
|
|
Thanks to clang-tidy for spotting that.
|
|
cache payload
|
|
To be able to get all available tags throughout the connection.
|
|
Closes #176. The right way (c) of server name resolution will be done in #178 (see also the Google Doc mentioned in it).
|
|
Closes #177.
|
|
|
|
Plugs some memory leaks reported by Valgrind.
|
|
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.
|
|
When there are too many rooms to process, this gives at least some
bandwidth for the GUI in the meantime.
|
|
|
|
Closes #160.
|
|
Bonus: slightly more accurate comment in Connection::forgetRoom
|
|
Causes a cache version upgrade; the old cache stores the state in an
incorrect place that won't be supported. Closes #159.
|
|
Closes #157.
|
|
|
|
|
|
|
|
|
|
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.
|