| Age | Commit message (Collapse) | Author |
|---|
|
...and therefore deprecated for use in clients _yet_.
|
|
|
|
|
|
It's present on the vast minority of events so better be embedded into
JSON instead.
|
|
It's not always a JSON object; it's either a SetTweakAction object or a string. (Unfortunately, QVariant isn't a template type and there's no easy way to put Q_DECLARE_METATYPE(SetTweakAction) in a Mustache template, so adding one is left as an exercise to the user now.)
|
|
Most of the actual change was in the API definition files (thanks to @anoadragon453), plus a converter from a QJsonObject map to the URL query string.
|
|
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).
|
|
A spin on the standard algorithm.
|
|
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.
|
|
Time and again I need one-off slots that disconnect once they are done. The code has been inside Connection implementation for quite some time, now it's put to the interface for usage in other places (notably qmc-example).
|
|
|
|
[ci skip]
|
|
Omittable<> doesn't work with reference types and returning an unknown
event spoils the experience. It's much simpler to just deal with event
pointers instead.
|
|
...against unwrapping omitted values (the release build will return a
default-constructed value).
|
|
Fix compilation issue of qmc-example.
|
|
|
|
Many thanks to @encombhat for pinpointing.
|
|
{{>}} instead of {{#@filePartial}}, library macros begin with _ instead
of @, mustache/definitions split - see the GTAD commit log.
|
|
|
|
Expose Room::addTag() and Room::removeTag() to QML
|
|
|
|
|
|
|
|
|
|
latest GTAD
|
|
|
|
|
|
|
|
The actual change is in API definition files, this is just regeneration.
|
|
|
|
Also: as of the previous commit, we officially bump API version to 0.4
|
|
|
|
As per the latest API definitions.
|
|
|
|
...leading to uploadFile() being never even functional - the code really
needs tests. Closes #221.
|
|
|
|
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).
|
|
|
|
Presence requires authentication; GetConfigJob; GetLoginFlowsJob; serverName parameter in JoinRoomJob.
|
|
If defined (value doesn't matter), it will suppress generation of
deprecated EventType constants. Not defined by default, as of 0.4.
|
|
Otherwise factory chaining doesn't work right (an unknown event returned
by a chained factory is treated as successful parsing).
|
|
|
|
|
|
They should not come anywhere around Room.
|
|
|
|
|
