| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The latter obsoleted the former since Qt 5.9, actually.
|
|
QChar now accepts more types for construction, and that unraveled
concatenation of a Type/SecondaryType character with a QString.
To fix it, give the compiler a hint by casting to the enum's underlying
type (which also nicely documents that we _actually_ switch from enum
to character type).
|
|
Now that QMetaType introspects into types, it reveals hidden problems
(which is very nice of it).
|
|
|
|
Waiting for the Multimedia arrival in Qt 6.2.
|
|
This fixes reliance on QIODevice being magically available for
std::unique_ptr<> by indirect inclusion. Since Qt 6 this inclusion no
more happens, time to #include <QIODevice> explicitly.
|
|
|
|
erase_if is now also provided by Qt; doing pretty much the same thing,
the Qt implementation only returns the number of removed entries instead
of returning a collection of them, however. Worth admitting at this
point that the function in connection.cpp has never had the semantics
of STL's erase_if() and doesn't quite have the semantics of remove_if()
either; but at least it's closer to remove_if().
|
|
See https://www.qt.io/blog/whats-new-in-qmetatype-qvariant#qmetatype-knows-your-properties-and-methods-types
|
|
This is an adjustment to the earlier fix of #471: if a join is
immediately followed by a leave (e.g. from another client/bot - you
can't do it programmatically from libQuotient) the sync may bring the
room already in the Leave state; therefore `joinRoom` should not
impose the state but rather ask `provideRoom` to create a `Join` room -
just as it's designed when passed an empty `joinState`.
|
|
An alternative implementation of #463 (and thanks to Carl for spotting
the original problem).
|
|
In the normal case there is always a room that is associated with an
user. So it is in most of the cases, possible to load the metadata
(display name and avatar url) with the help of the room.
In some cases, it is not possible. For example, when opening an user
matrix link pointing to an user and not to a room. In this case, we need
to load the metadata independly of the room, since the user is not
linked to a room.
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
|
|
Adds ability remove the avatar
|
|
Not possible previously
|
|
(cherry picked from commit b25785d294669f2bab7dcd1e3cd1fba61991fe46)
|
|
As per the latest iteration of MSC2312, room/, user/ and event/ are
only supported for parsing and replication but not for emitting from
Matrix identifiers.
(cherry picked from commit 86f24d1ecf300b82b3a7253b81a2c392669d2c2b)
|
|
Load user info (display name + avatar) for the local user.
|
|
Fix rich edits (transmit)
|
|
The new formatted_body was not included into new content on edit
due to badly constructed json.
|
|
With this patch it looks like:
"m.relates_to": {
"m.in_reply_to": {
"event_id": "$another:event.com"
}
}
instead of:
"m.relates_to": {
"event_id": "$another:event.com",
"rel_type": "m.in_reply_to"
},
So it fits the specification by now.
https://matrix.org/docs/spec/client_server/r0.6.1#rich-replies
|
|
Maybe it's not even that bad, given that an effort is taken to recover
from the internal member list corruption.
|
|
This is needed for a few cases like the account list in NeoChat or the
account switcher. In this cases we don't have a room binded to the user
and can't fetch the real display name and avatar.
|
|
|
|
After going through all the files and the history of commits on them
it was clear that some copyright statements are obsolete (the code has
been overwritten since) and some are missing. This commit tries best to
remedy that, along with adding SPDX tags where they were still not used.
Also, a minimal SPDX convention is documented for further contributions.
Closes #426.
|
|
|
|
Port existing copyright statement to reuse using licensedigger
|
|
|
|
|
|
|
|
A new field of std::any type is added that allows clients to "annotate"
any event item with arbitrary kind of data. This is mainly intended so
that clients could calculate certain information about the item (e.g.
special formatting depending on the event contents, or position) without
having to calculate this information every time it is visualised.
In case of Quaternion, the idea is to calculate the "spamminess" of
the event basing on the past activity of a given user in this room -
calculating it upon displaying each event is extremely heavyweight.
|
|
See #437 for the discussion.
|
|
To be very clear what this function checks. See also #437.
|
|
Fixes #437.
(cherry picked from commit 12e00b234e5c5f4ed57b5c400d06f780e71014f4)
|
|
So just reset the base URL and return, with no error signals.
(cherry picked from commit be00308ad67286b45912202750fe49fb87f16e4a)
|
|
(cherry picked from commit 4f06d46d6d6062d6d17f69eeaddb7810edac5bbf)
|
|
...because finished() includes abandoning and should only be relevant
when lifecycle issues are involved.
(cherry picked from commit 90d41b697af39253483d9bcca4e57b11d2197112)
|
|
Add support for stickers
|
|
|
|
The breakage was caused by 639f1d48.
|
|
|
|
|
|
This removes now-deprecated RoomMemberEvent API usages and also does
a few more things differently from the stable branch. Rather than rely
on prev_content (the way pre-0.7 goes), processStateEvent() now
includes a pre-check for no-op state events (the fix in ff020f3b
turned out to be insufficient for such events and they still caused
the same assertion failure at some point down the line). Now the state
event is only added to currentState and, where relevant, to baseState,
if it actually changes the room state; otherwise, it is ignored for
the purpose of state tracking (even when still added to the timeline,
if it came in the timeline block).
One side-effect of this change is that processStateEvent() now returns
OtherChange instead of NoChange for unknown state events.
At the same time removeMemberFromMap() now has an additional safety net,
making sure that a given user is actually deleted from the map even
if their name is mismatched. This comes at a cost of looking through
the whole hashmap but normally should not occur with the current code
that shaves away no-op state events. We'll only see when some client
starts to actively use 0.7 (quotest doesn't trigger those).
|
|
MEMBERS, aka quotient.events.members.* - this was promised in ff020f3b
but not actually done "before merging".
|
|
|
|
...to show the sunny-day case.
|
|
|
