| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
Code maintenance
|
|
|
|
|
|
the code.
See https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES for the full list. All the newly added features are already implied by C++11 standard so for older CMakes -std=c++11 should cover all bases anyway.
|
|
This is used once in the library and, I guess, twice more in the
Quaternion. Implemented as a template function that is equally suitable
for Event and Message, and any container that supports STL-style
iterators (QList and other Qt containers do).
|
|
|
|
|
|
automatically.
|
|
1. Remove accidental trailing \
2. Show the contents of NetworkError in logs
|
|
|
|
|
|
Make Connection parent of Room.
|
|
|
|
Allow Connections to be used in QML.
|
|
Originally by Felx Rohrbach (kde@fxrh.de)
|
|
Originally by Felix Rohrbach (kde@fxrh.de)
|
|
|
|
|
|
|
|
|
|
|
|
|
