Previously, member events in initial syncs (unless user had "hide member
events" and "hide profile events" set to false in their config) were
completely discarded with the help of a sync filter, instead of simply
being hidden like events loaded from room backfilling.
This was done due to the common case of rooms getting only
userconfig-ignored/hidden events on startup (especially with the
low number of initial events requested for lazy initial sync),
and thus having nothing to show as "last message" in
the room list (room delegate subtitles).
Other problems resulted from this, like missing join/leave events
when the config was set to hide profile events but not other
member events, and the "Members not synced" (#54) in encrypted room
with recent discarded member events.
The discarding filter is no longer used. Instead, if a room in the room
list has no visible "last message" and is currently visible to the user,
messages will be lazily fetched until we find something adequate or the
room goes out of view.
Contact the server's .well-known API before anything to get
available login flows instead of blindly assuming it will be
m.login.password, and to get the server's real URL instead of
requiring users to remember that e.g. it's "chat.privacytools.io"
and not just "privacytools.io" despite user IDs making it look like so.
The server field will also now remember the last accepted URL.
While a user file write operation #1 was queued in the _write_loop,
it was possible meanwhile for another function to read the file
(the current old version on disk), add some data to it,
add submit the write (operation #2).
The modifications from operatio #1 were then completly lost at best.
Compression with Pillow can take long, especially with large
clipboard PNG images.
Doing this in a separate process prevents the async event loop from
getting blocked, and allows multiple compression operations to run in
parallel.
It's possible to get a MatrixForbidden error when trying to retrieve a
offline room member's presence, if that member actually left the room
but the server hasn't yet sent the update.
This required us to set the media downloaded local path on events
entirely from python instead of simply lazy-fetching them when needed
from QML, due to pyotherside's async nature and files that must be open
in a certain order.
A healthy client must not only have a sync task running, but also have
finished its initial sync and have been succesful in its last sync
attempt.
The previous weak requirement caused this issue:
Have two clients, one on a failing server, and try to fetch a media,
thumbnail or profile: since these functions don't need auth, any
healthy client is picked to do the request, but the previous
requirement made it possible to pick the failing client.
Replace the poorly implemented 2-in-1 "copy address" media event
menu option with:
- Copy <mediaType> address: visible for non-encrypted media, always
copies the http URL
- Copy local path: always visible for already downloaded media, even if
they were downloaded before mirage was started
Fix bug introduced in 11fb32:
When loading an encrypted thumbnail, QML lacks the decryption dict for
half a second at first.
When calling python like this, python calls the wrong matrix API
for fetching the encrypted thumbnail, and the added retry code
would be forever stuck.
The retry code has been moved to QML, and now works for all HImage.
