| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
1. PostMessageJob is now SendEventJob, which reflects two things: first, it's a PUT instead of a POST (POST for /send is not supported by the latest spec anyway), so that we could enable tracking transaction ids for local echo in the near future; second, it's no more just about messages, the job can support sending any room events (topic changes etc.).
2. Room::postMessage() now uses the new RoomMessageEvent API to send m.room.message events.
|
|
|
|
|
|
|
|
|
|
The biggest change is we have no pimpls in Event objects anymore - because it's two new's instead of one per Event, and we have thousands and even more of Events created during initial sync. The other big change is introduction of RoomEvent, so that now the structure of events almost precisely reflects the CS API spec. The refactoring made UnknownEvent unnecessary as a separate class; a respective base class (either RoomEvent or Event) is used for this purpose now. All the other changes are consequences of these (mostly of RoomEvent introduction).
|
|
After adding some profiling it became clear that to recalculate the room name and emit namesChanged() upon each member event is a waste, especially when there are thousands of those coming at initial sync (*cough* Matrix HQ room). So the room name is recalculated only once and unconditionally (in most cases this will boil down to checking whether name/canonicalAlias changed after processing the events batch), and namesChanged is only emitted once per batch, if any name or alias changed.
|
|
introduced; Connection and Room cleanup
Helps to better encapsulate Room
|
|
Mainly it's about const-ification (in particular, passing const-refs instead of values) and deleting unneeded declarations/#includes. Since the changes alter the external interface, this is submitted as a PR for peer review.
One of unneeded declarations/definitions is a virtual destructor in BaseJob descendants. Since a job object should be deleted through QObject::deleteLater() anyway (and it's the only correct way of disposing of the object), all deletions will call the stack of destructors through virtual QObject::~QObject(). Therefore even BaseJob could get on with a non-virtual destructor but for the sake of clarity BaseJob::~BaseJob() is still declared virtual.
|
|
This greatly reduces the noise made by quaternion.
To enable full logging, export the following variable:
QT_LOGGING_RULES="libqmatrixclient.*.debug=true"
|
|
|
|
Because it's a recommended by Qt method to sort end-user-facing lists.
|
|
|
|
Room names conflicts should be handled at the client level, for example
by displaying the canonical alias in a tooltip or in the custom
delegate of the view.
If we extend the display name algorithm at the lib level, we
are just cluttering the display name in the most common scenario
(i.e. when there are no name clashes).
|
|
|
|
This will be used from Quaternion for a better algorithm dealing with read markers
|
|
timeline + no more discarding read markers to events that haven't arrived yet
When using deque::const_reverse_iterator for read markers and eventsIndex, I didn't realise that insertions into std::deque invalidate iterators (though preserve references and pointers). Therefore, a small TimelineItem class has been introduced that stores an event together with a persistent index that is generated upon insertion into the timeline (timeline.back()+1 for newer events, timeline.front()-1 for older events). Using such indices, we can still reach an event by it's index in constant time, while avoiding a problem with invalidating iterators.
While rewriting the code, another problem has been detected with read markers to events that haven't yet arrived to the timeline (in particular, older events). The old code simply discarded such read markers. The new code stores such read markers anyway, so that when that event arrives, it could be matched against the stored last-read-event id.
|
|
|
|
Also, Room now uses callApi<PostReceiptJob>() instead of postReceipt()
(to allow further removal of postReceipt() from Connection)
|
|
Fix adding events to the timeline
|
|
|
|
forbid empty event id's
Added assertions and enhanced debug messages along the way
|
|
Instead of QHash, use QVector< QPair<> > because it's more efficient and
we don't really need a hashmap functions, only direct iteration over the
list of event-to-receipt pairs. Also, iteration over QJsonObjects is
more efficient (and better conveys the intention) than collecting keys()
and then finding a value() for each of them. Also, fixed accidental
allocation of empty Receipt structures instead of reserving space for
them.
|
|
Turns out that because the read marker is positioned _after_ the last read message, a reverse iterator models it much better than the usual one. This commit switches the internal representation to reverse iterators (externally, we operate in terms of event id's, still).
|
|
|
|
A new hashmap, eventsIndex, is provided, that allows you to find the event in the timeline if you have eventId. This hashmap uses the fact that deque iterators don't invalidate upon insertion of elements to either end of the deque. Thanks to that, promoteReadMarker() and doAddNewMessageEvents() have been considerably simplified; also, it should be easier now to calculate event indices without rolling back and forth over the timeline.
|
|
|
|
|
|
Room::Private::member() filters out non-members of the room, which is not the right thing when adding messages from a person that left the room, e.g.
|
|
Thanks to @maralorn for pointing out.
|
|
|
|
|
|
The first change allows to use the read marker from QML (hint to Tensor). The second change is actually a fix for a case when markMessagesAsRead() is called with an iterator behind the last read event (in that case markMessagesAsRead() would post a receipt for that older event, which is not quite right).
|
|
This code is useful for any client that uses the Room class and needs to display the list of room members. Also removed an unused #include.
|
|
Kicking markMessagesAsRead() at each mouse move is still a bad idea - I'm looking at you Quaternion.
|
|
The implementation allows further extension to actually counting unread messages (in their Room::isEventNotable() sense - see the code) but so far just replicates what Quaternion previously provided. The only difference from the Quaternion implementation is that last own message is not marked as read immediately - so that we can allow the local user to send messages while staying with the read marker well above. This implies, though, that the read marker won't reset to the timeline bottom at any movement of the user - rather that it resets to the bottom of the current view (which is the ultimately correct behaviour, anyway).
|
|
|
|
Room::markMessagesAsRead: use the iterator to the message, not after the message.
Room::setLastReadEvent: moved to protected
|
|
setLastReadEvent() is called in any case (read marks a stored in a hashmap so it's a constant time operation anyway); postReceipt() is now called for the nearest previous non-local message.
|
|
receipts for own messages to the server
As discussed with Matthew in #quaternion: https://matrix.to/#/!PCzUtxtOjUySxSelof:matrix.org/$14768896199130qcJqe:matrix.org
|
|
|
|
Normally, this shouldn't happen anyway - just a double-check,
|
|
This fixes a case when another person mentions you by disambiguated name, and this is not highlighted because Riot uses () and Quaternion uses <> to decorate disambiguated names (as well as to check mentions).
|
|
|
|
|
|
|
|
This replaces the one-by-one timestamp-ordering algorithm of adding new
messages with copying the whole group of just-arrived messages to either
the beginning or the end of the timeline.
Since origin timestamps do not provide a reasonable order,
findInsertionPos() is entirely deleted. processMessageEvent() is
replaced by two functions: addNewMessageEvents() appends at
messageEvents.end() while addHistoricalMessageEvents() inserts them at
messageEvents.begin(). There's no official way to insert messages in the
middle; cases when getPreviousContent() is called in parallel or a
RoomMessagesJob runs on a gap somewhere in the middle of the timeline
weren't considered before this commit and aren't considered in it.
The new ordering requires you to understand where you have got your
events from (or rather, where you want to insert them). In particular,
updateData() that processes /sync results uses addNewMessageEvents();
getPreviousContent() calls addHistoricalMessageEvents().
In order to notify clients, a single newMessages() signal gives way to
3 new signals: 2 aboutToAdd*Messages() and a common addedMessages().
In addition, clients can derive from Room and use doAdd*Messages()
virtual functions to alter/extend the behaviour.
|
|
deconstruction log line
|
