| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This commit introduces a few things to further reduce the boilerplate
across event type definitions:
- Event type is no more separately stored in Event and therefore no more
passed to base event constructors. Until the previous commit, it was
used by is() to quickly match the event type; with the new event
metatype class, the same is achieved even quicker by comparing
metatype pointers.
- EventTemplate is a generalisation of StateEvent for all event types
providing common constructor signatures and content() for (most) leaf
event types. StateEvent therefore has become a partial specialisation
of EventTemplate for types derived from StateEventBase; as the known
client code base does not use it directly, a compatibility alias is
not provided. Also, DEFINE_SIMPLE_EVENT now expands into a class
deriving from EventTemplate.
- On top of StateEvent->EventTemplate specialisation,
KeyedStateEventBase and KeylessStateEventBase types are introduced
with appropriate constructor signatures (with or without state_key,
respectively) to allow `using` of them from derived event types.
To facilitate writing of constraints, concepts for keyed and keyless
state event types are also introduced; RoomStateView, e.g., makes use
of those to provide appropriate method signatures.
- typeId(), unknownEventTypeId(), UnknownEventTypeId are no more
provided - they weren't used throughout the known code base
(Quaternion, NeoChat), and the concept of "unknown event types" is
hereby eliminated entirely.
- RoomKeyEvent no more accepts senderId as a parameter; it has never
been a good practice as the sender is assigned by Connection anyway.
|
|
Besides having a misleading name (and it goes back to the spec),
EncryptedFile under `file` key preempts the `url` (or `thumbnail_url`)
string value so only one of the two should exist. This is a case for
using std::variant<> - despite its clumsy syntax, it can actually
simplify and streamline code when all the necessary bits are in place
(such as conversion to JSON and getting the common piece - the URL -
out of it). This commit replaces `FileInfo::url` and `FileInfo::file`
with a common field `source` of type `FileSourceInfo` that is an alias
for a variant type covering both underlying types; and `url()` is
reintroduced as a function instead, to allow simplified access
to whichever URL is available inside the variant.
Oh, and EncryptedFile is EncryptedFileMetadata now, to clarify that it
does not represent the file payload itself but rather the data necessary
to obtain that payload.
|
|
Main changes:
1. Base::fillJson() gets a QJsonObject& instead of QJsonObject* - c'mon,
there's nothing inherently wrong with using an lvalue reference for a
read-write parameter.
2. UrlWithThumbnailContent merged into UrlBasedContent. The original
UrlBasedContent was only used to produce a single class,
AudioContent, and even that can logically have a thumbnail even if
the spec doesn't provision that. And there's no guarantee even for
visual content (ImageContent, e.g.) to have thumbnail data; the
fallback is already tested.
3. toInfoJson is converted from a template to a couple of overloads
that supersede fillInfoJson() member functions in FileInfo/ImageInfo.
These overloads are easier on the eye; and clang-tidy no more warns
about ImageInfo::fillInfoJson() shadowing FileInfo::fillInfoJson().
4. Now that UrlWithThumbnail is gone, PlayableContent can directly
derive from UrlBasedContent since both its specialisations use it.
5. Instead of FileInfo/ImageInfo, fillInfoJson() has been reinvented
within UrlBasedContent so that, in particular, PlayableContent
wouldn't need to extract 'info' subobject and then roll it back
inside the content JSON object.
|
|
Get rid of that Q_ASSERT() in the middle that only worked in Debug
builds anyway.
|
|
RelatesTo and EventRelation have been two means to the same end in two
different contexts. (Modernised) EventRelation is the one used now both
for ReactionEvent and EventContent::TextContent. The modernisation
mostly boils down to using inline variables instead of functions to
return relation types and switching to QLatin1String from const char*
(because we know exactly that those constants are Latin-1 and
QLatin1String is more efficient than const char* to compare/convert to
QString).
|
|
When internal linkage is necessary, anonymous namespaces fulfil the same
purpose in a better way. See also:
https://stackoverflow.com/questions/4422507/superiority-of-unnamed-namespace-over-static
|
|
It's better than const char* because any interaction between const char*
and QString assumes that const char* contains UTF-8, which is
pessimistic and therefore inefficient; at the same time:
- construction of QString from QLatin1String is extremely fast
(boiling down to padding null bytes)
- "something"_ls is much shorter than QStringLiteral("something")
- "something"_ls produces a direct pointer to the literal at compile
time, using the benefits of raw string literals (deduplication, e.g.)
The library API will also transition to QLatin1String where applicable,
likely in 0.8.
|
|
There's a clash between Event::content() (a template function) and
RoomMessageEvent::content() (plain member). Out of these two, the name
more fits to the RME's member function - strictly speaking,
Event::content() retrieves a part of content, and so is renamed.
In addition, contentPart() defaults to QJsonValue now, which is pretty
intuitive (the function returns values from a JSON object) and allows
to implement more elaborate logic such as
if (const auto v = contentPart<>("key"_ls); v.isObject()) {
// foo
} else if (v.isString()) {
// bar
} else {
// boo
}
|
|
|
|
Closes #483.
|
|
Waiting for the Multimedia arrival in Qt 6.2.
|
|
(cherry picked from commit b25785d294669f2bab7dcd1e3cd1fba61991fe46)
|
|
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
|
|
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.
|
|
|
|
Co-Authored-By: Kitsune Ral <Kitsune-Ral@users.sf.net>
|
|
|
|
The prepared body got overwritten due to missing return statement.
|
|
|
|
That breaks API all over the place but:
1. The fixes are trivial.
2. More of std:: is used instead of home-baking the same stuff.
|
|
|
|
|
|
|
|
Unified *Key -> *KeyL identifiers in roommessageevent.cpp along the way.
|
|
|
|
|
|
# Conflicts:
# CMakeLists.txt
# lib/avatar.cpp
# lib/connection.cpp
# lib/connection.h
# lib/connectiondata.cpp
# lib/csapi/account-data.cpp
# lib/csapi/account-data.h
# lib/csapi/capabilities.cpp
# lib/csapi/capabilities.h
# lib/csapi/content-repo.cpp
# lib/csapi/create_room.cpp
# lib/csapi/filter.cpp
# lib/csapi/joining.cpp
# lib/csapi/keys.cpp
# lib/csapi/list_joined_rooms.cpp
# lib/csapi/notifications.cpp
# lib/csapi/openid.cpp
# lib/csapi/presence.cpp
# lib/csapi/pushrules.cpp
# lib/csapi/registration.cpp
# lib/csapi/room_upgrades.cpp
# lib/csapi/room_upgrades.h
# lib/csapi/search.cpp
# lib/csapi/users.cpp
# lib/csapi/versions.cpp
# lib/csapi/whoami.cpp
# lib/csapi/{{base}}.cpp.mustache
# lib/events/accountdataevents.h
# lib/events/eventcontent.h
# lib/events/roommemberevent.cpp
# lib/events/stateevent.cpp
# lib/jobs/basejob.cpp
# lib/jobs/basejob.h
# lib/networkaccessmanager.cpp
# lib/networksettings.cpp
# lib/room.cpp
# lib/room.h
# lib/settings.cpp
# lib/settings.h
# lib/syncdata.cpp
# lib/user.cpp
# lib/user.h
# lib/util.cpp
|
|
|
|
away TextContent when not needed
1. The spec says "if you support rich replies you MUST support fallbacks" - this commit only adds dealing with event JSON but not with textual fallbacks.
2. TextContent is only created if there's something on top of plain body (an HTML body or a reply).
|
|
resolution
The API version number should have been bumped long ago.
|
|
|
|
|
|
|
|
|
|
There were two common points that had to be updated every time a new event is introduced:
the EventType enumeration and one of 3 doMakeEvent<> specialisations. The new code
has a template class, EventFactory<>, that uses a list of static factory methods
to create events instead of typelists used in doMakeEvent<>(); the EventType enumeration
is replaced with a namespace populated with constants as necessary.
In general, EventType is considered a deprecated mechanism altogether; instead, a set
of facilities is provided: is<>() to check if an event has a certain type (to replace
comparison against an EventType value) and visit<>() to execute actions based on
the event type (replacing switch statements over EventType values).
Closes #129.
|
|
Many thanks to clang-tidy and clazy authors for the tools, and to Qt Creator developers for making them easily available in the IDE.
|
|
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/).
|
