| Age | Commit message (Collapse) | Author |
|---|
|
This allows to batch updates into signals being emitted only once per
sync. Also supercedes emitNamesChanged flag used in a few places.
|
|
SyncData now resides in its own pair of files and is capable to load either from file or from JSON. There is also (yet untested) capability to load rooms from files if a file name stands is the value for a given room id. This allows to store the master cache file separately from cache files for each room, massively easing the problem of bulky accounts that can overflow the poor capacity of Qt's JSON engine.
|
|
These two are intermingled in Room::addHistoricalMessageEvents because
processing empty events found in a historical batch is no different from
discovering (not lazy-loaded) members.
|
|
This was one more cause of #257 - the case when a redaction on a state
event arrives in the same batch as the redacted event.
|
|
|
|
|
|
|
|
Closes #258.
|
|
Also: use Matrix type instead of internal type id in StateEventKey
(Because internal type id maps to the library type system which will not
discern between Unknown events and therefore will mix together events of
different types in Room::Private::baseState/currentState. The Room code
is updated accordingly (bonus: more asserts there).)
Closes #255.
|
|
Also: make moveEventsToTimeline() always put historical events from
position -1 rather than 0 so that Private::baseState could always
correspond to the before-0 position.
|
|
- registerEventType(): comment the cryptic _ variable
- Room::postEvent: document the return value
- Room::Private: upgrade comments to doc-comments - even though in Private, they still are helpful to show hints in IDEs.
- General cleanup
|
|
|
|
Synced events always have their event ids, so checking those for event id renders most of the function useless (and returns an incorrect result). Closes #248.
|
|
|
|
Closes #194.
|
|
|
|
No-order is already modelled with the other overload, and Omittable<>
breaks interfacing with QML.
|
|
|
|
Call events no more store deserialised values; instead they deserialise
values on the fly, same as all other events. They are no more treated as
state events (The Spec doesn't define them as state events in the first
place). A common base class, CallEventBase, is introduced that defines
data pieces common to all call events (call id and version).
|
|
|
|
Instead of overwriting the entire set of tags even on single-tag
operations, SetRoomTagJob and DeleteRoomTagJob are used now.
(Room::setTags() still uses SetRoomAccountDataJob).
|
|
TagRecord::order_type is float now, not QString.
|
|
|
|
|
|
|
|
Merge to latest commit.
|
|
The Spec wasn't entirely consistent on this until recently but floats actually are used in the wild, rather than strings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also: general cleanup.
|
|
|
|
Speeds up lookup of user(s) in a direct chat room.
Also: "The other one's" avatar is used to set the avatar of direct
chats only, not any room with 2 participants.
|
|
|
|
Not that it felt right but Riot does it and so should we. Closes #220.
|
|
Redaction events are now processed before, not after/along with normal
events. This complicates logistics a bit but makes sure to-be-redacted
events get redacted even before the client is notified about new
arrivals. Also, redaction events are unconditionally out of the timeline
for the moment (the non-starter KEEP_REDACTIONS_IN_TIMELINE macro is
gone). This reinstates #196 for now, which will be addressed separately.
|
|
Closes #227.
|
|
|
|
|
|
|
|
* TimelineItem and a newly introduced PendingEventItem are now
inheriting from the common EventItemBase class
* PendingEventItem has its own status and annotation, serving to track
transition of the item through pending states
|
|
|
|
See https://github.com/matrix-org/matrix-doc/pull/1457 for the background.
|
|
This is at least some (actually, not even that bad) identification of a message. Ideally it would probably be to return some handler that would allow to track the end-to-end status of the event - from getting sent to landing in the timeline. Right now the experience is crippled - transactionId always exists but only works for message events and Room has no way to give the event status by transactionId. pendingEvent* signals are somewhat helping, though.
|
|
This needed to split the container with the freshly arrived events into parts that don't have local echo and echo'ed events, and add them to the timeline emitting two different pairs of signals. Instead of being removed, pending events are now merged (effectively they are removed from unsyncedEvents container anyway but models can represent this as an echo event being "transformed" into a full-fledged one on a timeline).
|
|
The Room class has gained a new internal container, unsyncedEvents, storing
locally-created Event objects that are about to be sent or are sent but not yet synced.
These objects are supposed to be complete enough to be displayed by clients
in a usual way; access to them is provided by Room::pendingEvents() accessor.
A set of pendingEvent* signals has been added to notify clients about changes
in this container (adding, removal, status update). Yet unsent events don't
have Event::id() at all; sent but yet unsynced ones have Event::id() but have
almost nothing else except the content for now (probably a sender and an
(at least local) timestamp are worth adding).
Also: SendEventJob is removed in favor of GTAD-generated SendMessageJob.
|
|
Many thanks to @encombhat for pinpointing.
|
