| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
That is until ubports move to xenial.
|
|
|
|
It's only available in CMake 3.7 and later and is not needed for any known project anyway.
|
|
This is to support uMatriks that still has to compile on xenial codebase.
|
|
It's not version 2, it's still version 0.2.
|
|
|
|
|
|
It's been long overdue to separate them from the rest of the stuff (docs etc.). Also, this allows installing to a directory within the checked out git tree (say, ./install/, similar to ./build/).
|
|
|
|
Closes #113.
|
|
|
|
tagevent.h -> accountdataevents.h now has a macro to define more
simplistic events along the lines of simplestateevents.h but inheriting
from Event instead. TagEvent and ReadMarkerEvent(m.fully_read) are
defined using this macro. ReadMarkerEvent is also wired through event.*
(but not further yet).
|
|
[skip ci]
|
|
|
|
Using them in rooms and connection comes in the next commit.
|
|
Instead of exposing a QIODevice as GetContentJob does it gets a filename
and saves the incoming payload into it.
|
|
|
|
Instead of exposing a QIODevice as GetContentJob does it gets a filename
and saves the incoming payload into it.
|
|
|
|
All of these new exclusions have parameters named 'signed', 'unsigned' and 'default' which are C++ reserverd words. GTAD does not give a proper workaround for these yet (see #24) so exclude them for now.
|
|
We have a better SyncJob and SetRoomStateJob yet.
|
|
|
|
SSL errors)
Closes #145.
|
|
No credentials, just type, host, and port.
|
|
|
|
The whole thing should go without or almost without warnings with GCC and with Clang (MSVC is another story and I don't care about it much).
|
|
Also a bit of code tightening with some C++14 (but not only) things.
|
|
|
|
Because a missing return in a non-void function is always an error.
|
|
Rewire Connection::postReceipt() to the generated job too; this call is still deprecated though.
|
|
|
|
|
|
NB: Dynamic library generation requires CMake; no libqmatrixclient.pro yet.
|
|
|
|
* 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.
|
|
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).
|
|
Avatars are also a property of rooms, and the supporting code is basically
the same. The only thing different will be emitted signals, and the cleanest
thing to support that (aside from making Avatar a QObject) seems to be to
parameterise the thumbnail-updating logic with a continuation invoked upon
completion of the thumbnail job.
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows to detect if a room has been encrypted (no room state, just
an event as of yet). Closes #84.
|
|
|
|
|
