- for external access, Client.accountData should be read only
- added corresponding getter and private Map
Signed-off-by: Lanna Michalke <l.michalke@famedly.com>
When opening a room we need to
fetch all users from the database.
Otherwise we would need to
update the timeline per user after
creation which should be much slower.
For thumbnail generation, encrypting
and uploading it is not necessary
to block the UI. The given file
event should already be displayed
in the timeline. This placed it in
the UI and adds a additional
fileSendingStatus property so the
app can fetch the current status.
Reactions are triggering push
notifications and should therefore
be displayed as last events
in the room list of a client.
The body should just display
the reaction key.
This fixes that rooms with
new reactions can't set to
read.
Please note that this does not implement *modifying* widgets,
as this requires a full implementation of the Matrix Integration Manager
API first. This is to be done later.
Signed-off-by: TheOneWithTheBraid <the-one@with-the-braid.cf>
- By using [package:image](https://pub.dev/packages/image), the
`MatrixImageFile` was given automatically generated width and heigth.
- Moreover, `MatrixImageFile` was given a factory to create the image
file from a given maximal dimension.
- When sending images without explicitly providing a thumbnail, the
thumbnail is automatically generated based on the provided image.
- The blur hash in generated automatically based on the provided image.
Fixes:
https://gitlab.com/famedly/company/frontend/famedly-web/-/issues/162, https://gitlab.com/famedly/fluffychat/-/issues/756
Signed-off-by: Lanna Michalke <l.michalke@famedly.com>
Due to server bugs or whatever it sometimes
happens that old state events appear
in the setState method in the room class.
Previously we checked if we already know
this event ID, but for this we needed to
check the timeline which is very fluid.
Also this is a database operation in a
non-async method which works in Hive but
not in Sembast.
Using originServerTs is not 100% safe as
well but should be more stable because
the chance that servers have veeery wrong
time (which is necessary here) is much
lower than the risk that the timeline
is not long enough to know the
old event.
This can improve the start-up time of apps.
The three big db reads on init are
loading account data, rooms and
device keys.
This makes it now possible to let
them run parallel
(while it may depend on platform
if this has any effect)
and the init() method can skip
awaiting them. They will
be at least awaited before handling
the first received sync.
So the app can already display the
room list before device keys are
loaded and request the first sync
from the server before anything
else is loaded from the DB.
Apps had a hard time to just set
the marker for the last event.
The lastEvent in the Room may
not be the actual last event
because we ignore several
event types there. Therefore
it makes sense to refactor
the setUnread method.
Now the timeline class has an
easy method to set the read
marker to the last synced
event, which can only be
known by the timeline if we
want to avoid another DB access.
Previously we had a check which uses the old
sortOrder value.
This check has been removed with the refactoring which leads to
bug #209. This fixes it by checking if the
event is already known in the database.
I am not 100% happy with this solution as this database api is impossible
to be implemented with a sqlite db. Once we start to refactor the whole sync update logic
we maybe could find a better way, but only the fox god knows.
The current implementation of sortOrder can be made way more easier now
by just keeping the sortOrder of the list
and the timelineFragments in the hiveStore. This needed a huge
change but mostly removes a lot of code which can be done
way more easy now. This also needed some rewriting of the setState logic and changes to
the prevEvent calculation. This solution should also be more stable.
More information:
https://www.reddit.com/r/fluffychat/comments/pfnlhq/the_sort_order_of_matrix_timelines/
Normally we do not need a workaround here at all but we had
one in the displayname calculation for
historical reasons. A "good" server should always send the mHeroes correctly.
Instead of removing this workaround completely we do a compromise and implement a more
lightweight alt behaviour by just saying that in a DM room with no
heroes, the directChatMatrixId will be used. This is the same behaviour like in Element
and needs way less lines than before and also covers the avatar
calculation. For Synapse we seem to not need this but for Conduit it
might be helpful.
As it turns out, some of the code set the prev_batch for rooms too
early to an empty string. For synapse this means "request from the start",
for conduit it is just an error. This commit fixes that by never resolving
null --> empty string, but instead throw an error.
The old mentionMap was very inefficient to build and scaled badly with
room member size. This resulted in noticable lag when sending any message
in a large room, no matter if it contained a message or not.
Now, the algorithm is severly optimized and mentions (and emotes) are
only loaded when actually used.
Using JoinedRoomUpdate() in a fake
sync for archived rooms when requesting
the history leads to the problem that
the room is stored as a joined room
in the store which is wrong.
This PR adds support for nicer mentions in markdown: You can now
fetch the mention string of a user with `user.mention` which is
human-friendly (typically contains the display name), which will get
properly pillified upon passing through the markdown parser.
Krille Fear
Reza
Nicolas Werner
Henri Carnot
Lanna Michalke
Duan Weiwei
TheOneWithTheBraid
Marcel
Sorunome
Jindra
Jindřich Pikora
Lukas Lihotzki
Jayesh Nirve