| Age | Commit message (Collapse) | Author |
|---|
|
avatars-to-rooms mapping
Because they are uncopiable, unlike pointers to them; and a combination of QHash of avatars and a QMultiHash of rooms is much more convenient than a std::vector<std::pair<...>>.
|
|
Enables to address QMatrixClient/Quaternion#284. Also fixes a gibberish condition in Room::Private::renameMember() that led to improper warnings and a too early return.
|
|
User::Private stores two new maps (for display names and avatars respectively) and is able to retrieve and store names/avatars on a per-room basis. The "most used" trait is stored separately and room lists are not kept for it (because most people have a single name and a single avatar across all or most rooms).
TODO: The avatar container should be replaced with something less clumsy; the current code doesn't even compile with MSVC. A "handle" copyable structure that would hold the Avatar is one of options.
Closes #141.
|
|
Although the setting part of the work is class(User or Room)-specific, the uploading part is common, so Avatar provides it now.
Also: there's no need to store Connection, as it's only used in get() and upload() - just pass it as the parameter to the methods.
|
|
User::fullName() is used in Room::roomMembername now. That string
construction may be further cached now if it ever becomes a bottleneck.
|
|
To make it easy to use User objects and fetch room and user avatars from QML. Closes #155.
|
|
To make debugging (including QML debugging) more convenient.
|
|
This is needed for QML integration. Closes #155.
|
|
|
|
and User
The switch is necessary because MediaThumbnailJob is supposed to return something that can be worked on in non-GUI threads (as is the case of QML image providers), and QPixmap is not supposed for usage out of the main thread.
|
|
The events are detected in /sync output, and avatars for rooms are loaded from respective URLs. Clients can use Room::avatar() method to request a pixmap of a certain size, and react to avatarChanged() in order to update the UI when new pixmaps/avatars arrive. avatarChanged() signal is overloaded with two tasks - the first firing merely indicates that a new avatar is available (without actual pixmap yet available) while the second firing means that an actual pixmap has arrived (all this is entirely transparent for clients, they just should update their pixmaps from Room::avatar() every time when Room::avatarChanged() is emitted).
|
|
Avatars are also a property of rooms, and the supporting code is basically
the same. The only thing different will be emitted signals, and the cleanest
thing to support that (aside from making Avatar a QObject) seems to be to
parameterise the thumbnail-updating logic with a continuation invoked upon
completion of the thumbnail job.
|
|
If all users suddenly don't have names, update to this commit, delete your cache and run again. Issue since 2bf912d6e6ddd9ff81a92ff28ac8c4c1d8f2d7e1.
|
|
Note that although the mechanism is generic enough to change any user's
display name, The Spec states that power rules are very strict about it.
|
|
avatarUrl() is not yet invokable from QML; I'm considering to make all the simple things in User Q_PROPERTies instead.
|
|
|
|
|
|
Crop avatar to ensure it has exactly the wanted size; Fixes memory leak #45
|
|
|
|
|
|
|
|
|
|
|
