| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The previous code had no effect because QVector<Receipt> was instantiated before Q_DECLARE_TYPEINFO occurence.
|
|
|
|
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).
|
|
|
|
Push sender from RoomTopicEvent to Event
|
|
Fix messages ordering
|
|
Because it's supposed to exist in (at least) all events from /sync.
|
|
|
|
|
|
Connection: Don't return SyncJob* 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.
|
|
Given that Connection handles all the output from SyncJob already, there's no use in having the pointer. In fact, it's not used in Quaternion, and Tensor, to the contrary, has a problem _because_ this pointer is grabbed by the QML engine that mistakenly tries to handle its lifecycle.
|
|
deconstruction log line
|
|
Correct user sorting for room name creation
|
|
|
|
In the previous version, it was possible that u1 >= u2 and u2 >= u1:
Assume u1 == me, u1->id() < u2->id()
Then u1 >= u2, as u1 == me (i.e. it returns false)
but also u2 >= u1, as u2->id() > u1->id() (returns false again)
For me, this had the effect of having three rooms called fxrh.
|
|
Thanks to Clang for pointing this out.
|
|
To facilitate a possible change of a container type.
|
|
|
|
See https://marcmutz.wordpress.com/translated-articles/pimp-my-pimpl-
%E2%80%94-reloaded
|
|
|
|
[FEATURE] Add proper SONAME versioning
|
|
This doesn't affect the current build process much but distributions that
require libraries to be built as a shared object also often require
the use of symbol versioning using the SONAME, e.g openSUSE: https://en.opensuse.org/openSUSE:Shared_library_packaging_policy
|
|
|
|
This should avoid timeout event catching up on a not-yet-deleted-but-
already-invalid job object.
|
|
|
|
|
|
As the url-path seems to start with a slash, we had two slashes in the
request. This broke the feature for some servers, especially when
fetching icons from other servers.
|
|
|
|
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.
|
|
|
|
|
|
Settings classes
|
|
breaks highlighting
This reverts commit 0fe83d59d76cd8f9c8f92d40cc58d9f5b082a84a.
|
|
|
|
|
|
VS2013 doesn't like 'using' statements if a base class has private constructors (as in QSettings - Q_DISABLE_COPY makes a copy constructor private and deleted). Hence a workaround.
|
|
|
|
|
|
Settings is a trivial wrapper around QSettings that makes value() and setValue() available from QML (Tensor has the same class atm). SettingsGroup is a cleaner way to reach for sections inside QSettings. It doesn't refer to another QSettings class, rather derives from it and overrides functions that deal with groups. AccountSettings, contrary to the two above, is by no means generic: it serves the specific purpose of storing settings of a single account in a uniform way. Rationale of it is that key literals like "keep_logged_in" cannot be enforced, while function names can; and the same goes for QVariants stored inside - the class enforces specific types while allowing further extension by clients.
Note that functions in QSettings are not virtual, so all these classes are not polymorphic.
|
|
accessors de-virtualized
Details:
- New: Connection::homeserver(), returns the homeserver URL from inside ConnectionData
- New/Modify: Connection::accessToken() and ConnectionData::accessToken() - because we will also have refresh tokens eventually; deprecate token() for the same reason
- Modify: Connection::user(), token(), accessToken() are no more virtual (they should have never been, these are plain accessors, after all)
|
|
|
|
|
|
That might be not as efficient as a solution on variadic templates; but
arguably easier to understand.
|
|
|
