dynamic.copy returned a type
error so I reverted the previous
change of the copyMap
method to an extension. Also
I found out that we have used
two copyMap methods in the
SDK which did exactly the same.
I deleted the old one and
changed the tests.
Unfortunately we need to copy
all maps. I took the opportunity
and abstracted the copy map
method to utils. I kept the
copyMap method as a
reference in HiveCollections
database to not require a
huge refactoring there as we
are going to ditch it anyway.
BREAKING CHANGE: This replaces the old dehydrated devices
implementation, since there is no way to query what is supported easily
and supporting both would be complicated.
fixes https://github.com/famedly/matrix-dart-sdk/issues/1579
There were several issues here. Key uploads in general failed, because
the await caused a Future<dynamic> to be returned, which failed type
checking.
But also we never unset our future, which was used for the online key
backup uploads, which meant we would very quickly stop uploading any
keys at all.
This changes the behavior
of the markdown method to
only convert linebreaks inside
of p blocks. I found no better
solution yet for the problem
as otherwise also lists
will have linebreaks between
the list items. Unfortunately
the default linebreak syntax
seems not to fulfill our needs.
BREAKING CHANGE: This changes the runInRoot method to not return a
future. As a user, if you need the result of an async computation passed
to runInRoot, please await it directly. Also the KeyVerification start
and a few call methods now return a future.
- store left rooms in archive during sync (as well as they are removed
on join already)
- refactor room archive code
- fix typo
Internal reference: SMC-385
Signed-off-by: The one with the braid <info@braid.business>
Removes two test cases in the markdown test which do not work anymore.
Reason for this is that just parsing a word inside of $$ word $$
katex is not valid anyway because katex is only made for mathematical
things. So the output is undefined behavior anyway.
At least in our CI this throws a null assertion error and since we
explicitly expect this to sometimes be null in our code, we should store
it as such.
Krille
Karthikeyan S
Nicolas Werner
Nicolas Werner
Mohammad Reza Moradi
td
krille-chan
td
The one with the braid
Clemens-Toegel
Ray