| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
If KEEP_REDACTIONS_IN_TIMELINE is defined, the library adds redaction
events to the timeline as well. If not, the legacy behaviour is used:
redaction events themselves are dropped from the timeline and only
stored as parts of redacted events. Closes #220. Closes #196 (requires
KEEP_REDACTIONS_IN_TIMELINE for that).
|
|
They should not come anywhere around Room.
|
|
|
|
Easier to read, and also easier compiler diagnostics if things go wrong. Still using visit() for state events processing though - it maintains that all lambdas return some value.
|
|
It confuses compilers and adds a mostly unneeded null check; it's dead easy
to just dereference a pointer before passing it to visit<>().
|
|
code into blocks
A template member variable in it seemed to cause internal compiler error in MSVC 2017, let alone MSVC 2015...
|
|
There were two common points that had to be updated every time a new event is introduced:
the EventType enumeration and one of 3 doMakeEvent<> specialisations. The new code
has a template class, EventFactory<>, that uses a list of static factory methods
to create events instead of typelists used in doMakeEvent<>(); the EventType enumeration
is replaced with a namespace populated with constants as necessary.
In general, EventType is considered a deprecated mechanism altogether; instead, a set
of facilities is provided: is<>() to check if an event has a certain type (to replace
comparison against an EventType value) and visit<>() to execute actions based on
the event type (replacing switch statements over EventType values).
Closes #129.
|
|
|
|
This mandated some rearrangement of toJson() overloads and FromJson<>
specializations for QVariant* types - instead of variant_converters.h they are
now in converters.cpp.
|
|
There's no case for a nullptr in that function, and I'm fine to use
non-const ref parameters.
|
|
So that it could be used outside of room context.
|
|
|
|
one-on-one
|
|
|
|
The template part (not exposed in the auto-generated class) goes to Room::Private::requestSetState(). Also, Room::setMemberState() to interface with User class.
|
|
The latter one causes linkage errors when used from a template method (but not from a template class, puzzlingly).
|
|
1. Updates in this commit (see further) allow to generate and build
GetRoomEventsJob from message_pagination.yaml; this job completely
preempts RoomMessagesJob.
2. EventsBatch<> is no more a thing; there's EventsArray<> to replace it
but it's loaded from a JSON array rather than an event batch (a JSON
array inside another JSON object). SyncJob that used it extensively has
been moved to "conventional" containers (Events, RoomEvents and the
newly introduced StateEvents). RoomMessagesJob that also used
EventsBatch<> is decommissioned (see above).
3. RoomEventsRange is now an alias for Range<RoomEvents>, defined in
util.h (otherwise almost the same).
4. Connection::getMessages() is no more. Use Room::getPreviousContent()
and Connection::callApi<GetRooMEventsJob>() instead.
5. Moving things around in Room, since SyncJob now supplies state events
in more specific StateEvents, rather than RoomEvents.
|
|
|
|
So that eventual switch from std::unique_ptr to some other pointer (as a
case - QSharedPointer) would be as painless as possible.
|
|
That is, add "using std::move" and strip std:: from actual usages.
|
