This makes sure that the
users for an invitation are
correctly loaded so that we
can display the avatar, the
room displayname and
wether the room is a direct
chat or not.
This fixes the bug that the
actual dart Map in the state
has been manipulated because
we have not worked with a
copy of the map. Also this
crashes if the powerlevelmap
would had a wrong type in
users.
When using the searchEvent()
method it was impossible to
paginate to the next
chunk when one chunk had
0 returned events. This
fixes it by returning the
prevBatch and makes it
possible to insert the prevBatch
again. sinceEventId is still
working but now deprecated.
Original issue and former solution by
The one with the braid <info@braid.business>
Special thanks for pointing out the problem.
This fixes that dart:io is imported into the
SDK database by moving it into it's own mixin which
makes it reusable and platform independent by
using conditional imports.
- removes `Directory` field in high-level `MatrixSdkDatabase`
- migrates `Directory fileStoragePath` to `Uri fileStorageLocation`
- makes file operations in `MatrixSdkDatabase` conditional on
`dart.libraries.js_util`
- implements a tiny stub of the file operations used in `MatrixSdkDatabase`
It seems like the Flutter tool can compile despite these imports. Sadly
the Dart standalone dart2js compiler doesn't reach there. While
refactorying the code, I decided it's likely cleaner to have a `Uri` as
storage location provider than using some fake directory or String as
relacement.
The advantage of a `Uri` at this place is the explicit `Uri.directory`
constructor available to ensure type and encoding safe directory
locations supporting both Windows and *nix.
Additionally, admitted, that's an edge-case, one could even
easily extend the use of a `Uri` based descriptor to support future
storage location accesses (e.g. IPFS or custom schemes for e.g. local
web browser based file system APIs). Using a `Uri`, one would only need
to override the three methods making use of the `fileStorageLocation`
property to handle different Uri schemes too.
Signed-off-by: The one with the braid <info@braid.business>
When user A invites user B to
a group chat, the avatar getter
should not return the
avatar of the inviting user A.
This is not intuitive. A client might
decide to do so but IMO it makes
no sense to do this by default.
If the
room is a DM invite, user A's
avatar is already used in the
code block before.
td
td
Nicolas Werner
Krille
krille-chan
morguldir
Karthikeyan S
Karthikeyan S
The one with the braid
Krille