Age | Commit message (Collapse) | Author |
|
For QML to easily make URLs to thumbnails.
|
|
Given that it's a sidedoor anyway, it should at least be straightforward to use.
|
|
MSVC is not good at dealing with type parameter packs of member functions, which is what the whole mixin magic in UrlBasedContent<> relied on. So it's one more level of inheritance instead of mixins now.
|
|
The whole inheritance/templating structure has been considerably simplified by using a trick with mixin classes; thanks to that, *Info classes are no more templated, they are just mixed together by the almighty UrlBasedContent<> template (but the same can easily be done outside of it, as LocationContent implementation shows). RoomMessageEvent has gained hasFileContent(); it's also possible to easily get a FileInfo core object just by calling msgEvent->content()->fileInfo().
|
|
|
|
This will hold common logic for all state events, including the newly introduced repeatsState() that returns true when prev_content repeats content. This will be used to address QMatrixClient/Quaternion#245.
|
|
|
|
Because we should practice what we preach in CONTRIBUTING.md.
|
|
|
|
Closes #135.
|
|
|
|
|
|
This causes the following changes along the way:
- Owning<> template is decommissioned.
- event.h has been rearranged, and Event/RoomEvent::fromJson static methods have been replaced with an external makeEvent<> function template. A side effect of that is that one cannot use a factory with a type other than the one it's defined for (i.e. you cannot call makeEvent<TypingEvent>) but that feature has been out of use for long anyway.
- Room::doAddNewMessageEvents() and Room::doAddHistoricalMessageEvents() have been removed, giving place to Room::onAddNewTimelineEvents() and Room::onAddHistoricalTimelineEvents(). The most important difference is that all code that must be executed now resides in addNewMessageEvents() (it moved from Room to Room::Private) and classes inheriting from Room are not obliged to call the overridden function from the overriding function (they can do it but those functions have empty bodies in Room). This was a long overdue change, and owning pointers simply mandated it. Room::onAddNewTimelineEvents/onAddHistoricalTimelineEvents should not do anything with the passed range in terms of ownership, it's just a way to allow the derived class to update his data in due course.
- Room::Private::dropDuplicateEvents() and Room::Private::insertEvents(), notably, have been updated to work with owning pointers. insertEvents() move()s pointers to the timeline, while dropDuplicateEvents uses remove_if instead of stable_partition and doesn't explicitly delete event objects.
Also, a bugfix: Event accidentally had not virtual destructor for quite a long time. According to the standard, deleting an object through a pointer to a base class without a virtual destructor leads to UB. So the fact that libqmatrixclient clients even worked all these months is mere coincidence and compiler authors good will :-D
|
|
|
|
|
|
The Spec doesn't mention it but both Synapse and Riot act as if origin_server_ts was whitelisted, and it was also confirmed in #matrix-dev to be reasonable behaviour.
|
|
A RoomEvent now has an optional pointer to a RedactionEvent that is non-null if the room event is redacted. transactionId and serverTimestamp are only filled if the event is not redacted. There's no way to construct a redacted event as of yet.
|
|
Will be used in Room to work with ranges of events.
|
|
|
|
|
|
This impacts the cache as well, as we don't save state_keys for most
state events.
|
|
|
|
|
|
It now allows to check what exactly has happened to the member (display name change, joining, avatar update), fixing #105.
|
|
Event::isStateEvent() is an easier way to make checking an event kind (instead of enumerating through all types corresponding to state changes). StateEvent::_prev (accessible through prev_content) should only be initialised if there's a previous state in the original JSON.
|
|
* StateEvent<> is a new class template for all state events. It provides a uniform interface to the state content, as well as a means to serialize the content back to JSON. In addition, StateEvent now parses the "prev_content" JSON object, so one can refer to the previous state now (a notable step to proper reflection of state changes in the displayed timeline in clients).
* EventContent::SimpleContent, together with StateEvent<>, forms a generalisation for simple state events, such as room name, topic, aliases etc. that boil down to a single key-value pair. DECLARE_SIMPLE_STATE_EVENT is a macro defined to streamline creation of events based on SimpleContent, providing API back-compatibility for events defined so far. As a result, a very concise simplestateevents.h replaces all those room*event.* files.
* Event/RoomEvent::fromJson() code is squeezed down to plain type lists passed to makeIfMatches() "chained factory" function template. TypeId is mandatory for an event type to be included into that factory.
* Event::toTimestamp() and Event::toStringList are completely superseded by respective fromJson<>() converters.
|
|
|
|
Event::toTimestamp() duplicates fromJson<>() code, so it should go.
|
|
We don't use them for several months already.
|
|
Two changes to make EventContent hierarchy easier to understand and use:
- InfoBase is unbound from Base, and downstream classes use multiple inheritance
to work "info" objects
- MIME types are separated from Base into a separate TypedBase class because
MIME typing is not common to all content kinds.
|
|
The events are detected in /sync output, and avatars for rooms are loaded from respective URLs. Clients can use Room::avatar() method to request a pixmap of a certain size, and react to avatarChanged() in order to update the UI when new pixmaps/avatars arrive. avatarChanged() signal is overloaded with two tasks - the first firing merely indicates that a new avatar is available (without actual pixmap yet available) while the second firing means that an actual pixmap has arrived (all this is entirely transparent for clients, they just should update their pixmaps from Room::avatar() every time when Room::avatarChanged() is emitted).
|
|
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).
|