| Age | Commit message (Collapse) | Author |
|---|
|
ImageContent is usable outside of m.room.message (in particular, m.room.avatar
uses the same structure for content. And EventContent::Base is very suitable to
derive from even for standard event content structures (such as in room name
events), let alone non-standard ones.
Also, renamed MessageEventContent to EventContent (for obvious reasons).
|
|
|
|
Notably:
* API for SendEventJob and SetRoomStateJob has been altered to accept references, not pointers.
* Methods on Room that invoke requests to the server, have lost const, because they may be reflecting the changed state on the fly, within themselves
|
|
The CS API, turns out, has a quite official extension point inside m.read event content - clients are allowed to put whatever extra data they feel reasonable.
|
|
This allows to detect if a room has been encrypted (no room state, just
an event as of yet). Closes #84.
|
|
|
|
|
|
Since there's no such thing as "unread messages flag" in the CS API spec, there's now a non-standard key-value in cached m.read receipts for that.
|
|
* Event::originalJsonObject() exposes the original JSON for the event without converting it to QByteArray. This is useful to quickly dump an event into a bigger JSON without reconstructing a JSON object.
* Validations in RoomEvent::RoomEvent() do more harm than good. The rest of the library tolerates absence of those attributes pretty well (it wouldn't be able to do much with that anyway); at the same time, dumping JSON to logs turns out to be pretty heavy, and throwing many invalid events at a client is a good way to hit its performance.
|
|
|
|
|
|
|
|
QString msgType allows non-standard types (we don't want to restrict clients to types from the spec)
|
|
mimeType is relevant to most of the content types, and at the same time getting a MIME type in a generic way is handy for clients to uniformly detect whether they can display the content and what renderer to use for it.
|
|
RoomMessageEvent and MessageContentEvent::* classes have been massively overhauled to enable creation of m.room.message events locally instead of from JSON.
|
|
This includes RoomEvent gaining transactionId property and addId() method so that it could gain ids when being/having been sent.
|
|
|
|
|
|
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).
|
|
The Dispatch<> template and dispatch(), a facility function for it, simplify dispatching to functions that have different signatures that still can be converted to the same std::function<> type. The case in point is in event.cpp; Event::fromJson calls make() that always returns the type we need; however, once we have several possible base types (Event, RoomEvent, StateEvent), we'd have to either write a specific make() incarnation for each of them, or mess with function return type conversions. Dispatch<> helps to keep the code clean.
REGISTER_ENUM is a cross-Qt versions approach to dumping enumeration values to qDebug() and the likes.
|
|
logging.h/logging.cpp is now a full-fledged pair for all things logging. Two more categories added, EPHEMERAL and SYNCJOB, that control logging for ephemeral events and SyncJob, respectively (in particular, switching off EPHEMERAL greatly reduces the logspam about moving read markers and how many users have read up to which event).
|
|
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"
|
|
The previous code deviated from the spec, trying to guess on the content type of body as if there could be HTML in some cases. The spec openly states that 'body' value should always be in plain text.
|
|
there
Because these fall outside of SyncJob and Event context, respectively. In addition, Owning<> has gained a move assignment operator (because we have a move constructor) and assign() convenience method to take ownership over an existing container; also, Owning<>::release() is done the right way now (the previous version was copying the return value to a new container instead of releasing the old container).
|
|
This is not quite correct because only room events are guaranteed by the spec to have an id and a timestamp. But we don't parse all room events as of yet, so that's a way to at least make those attributes universally available for even unknown room events. It matters, because read receipts can refer to any room event id and because we'll use event id's to filter out duplicate events in further commits; and missing timestamps used to break the timeline display (showing <> instead of <valid timestamps>).
|
|
|
|
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.
|
|
|
|
|
|
associated with Event objects anyway
|
|
|
|
|
|
The previous code had no effect because QVector<Receipt> was instantiated before Q_DECLARE_TYPEINFO occurence.
|
|
Push sender from RoomTopicEvent to Event
|
|
Because it's supposed to exist in (at least) all events from /sync.
|
|
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.
|
|
|
|
Feel free to use whenever you need to convert another JSON key to some C++ object, or dispatch anything based on a JSON key.
|
|
That might be not as efficient as a solution on variadic templates; but
arguably easier to understand. Doesn't have the typo bug the previous version of this commit had.
|
|
breaks highlighting
This reverts commit 0fe83d59d76cd8f9c8f92d40cc58d9f5b082a84a.
|
|
|
|
That might be not as efficient as a solution on variadic templates; but
arguably easier to understand.
|
|
|
|
The spec is told to allow any event to have a thumbnail in future, and the thumbnail will reside under "content" JSON key rather than "info".
|
|
|
|
TextContent is a class to deal with formatted (HTML, RTF, Markdown) text messages. Right now it only supports Vector's non-standard "formatted_body".
|
|
|
|
According to the spec, this key has the same status as msgtype: both should exist in any message. Besides, it's always supposed to be a plain text so there's no polymorphism allowed here.
|
|
|
