Age | Commit message (Collapse) | Author |
|
It's been long overdue to separate them from the rest of the stuff (docs etc.). Also, this allows installing to a directory within the checked out git tree (say, ./install/, similar to ./build/).
|
|
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<...>>.
|
|
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.
|
|
To make it easy to use User objects and fetch room and user avatars from QML. Closes #155.
|
|
With all the liberty that pimpl idiom gives it's easy to get away without proper const's; but let's be consistent :)
|
|
|
|
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 race occurred because _ongoingRequest wasn't properly reinitialized if another request on a bigger size arrives while a request for a smaller size is in the air. The old request is now abandoned and continuations are collected inside the Avatar object rather than in the lambda connected to the job. Closes #124.
Along the way, _scaledPixmaps is now std::vector instead of QHash since usually it only contains very few (1 or 2) entries and QHash is a waste of memory for that.
|
|
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.
|