We don't get notified for every message. Sometimes we only get a read
receipt for the newest message, which means old read receipts accumulate
in the database. This least to some considerable CPU overhead, when
checking if the timeline should be notified for new read receipts.
Instead just always notify, since that has far less overhead in the
worst case and doesn't need complicated cache cleanup.
The old pending_receipts db is not removed for now. It should still have
minimal storage overhead and we don't have a good mechanism for cache
format upgrades atm.
This turns `paginationInProgress` field of `TimelineModel` into a `Q_PROPERTY`, so the Ui can bind to it.
For the moment, I'm showing the same spinner as we do during initial sync. It's not ideal, on the count of being giant and in the middle but it's better than nothing. We can make it more subtle later.
- hides the overlay when prompting for download location
- cancel re-shows the dialog
- success closes the overlay
- would be nice to have a return code from the download fn in
mtxclient.
Closes#140
QFileDialog's dir arg (which was set to the incoming file name from the
Matrix download) can take a full path to suggest. By prepending
QStandardPaths::DownloadLocation, it opens to the system's download
folder and proposes the filename as the download name.
Using QStandardPaths should make this work on other platforms, and from
what I read, its possible for this to return an empty string on
platforms where it doesn't support it, so this should essentially
revert to the previous functionality if Qt can't determine the system's
download location.
This currently assumes the event, that is replied to, is already
fetched. If it isn't, it will render an empty reply. In the future we
should fetch replies before rendering them.
