| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Similar to hasFileContent(), allows to ascertain that an event has TextContent without checking against all possible msgtypes.
|
|
MSVC is not good at dealing with type parameter packs of member functions, which is what the whole mixin magic in UrlBasedContent<> relied on. So it's one more level of inheritance instead of mixins now.
|
|
The whole inheritance/templating structure has been considerably simplified by using a trick with mixin classes; thanks to that, *Info classes are no more templated, they are just mixed together by the almighty UrlBasedContent<> template (but the same can easily be done outside of it, as LocationContent implementation shows). RoomMessageEvent has gained hasFileContent(); it's also possible to easily get a FileInfo core object just by calling msgEvent->content()->fileInfo().
|
|
Two changes to make EventContent hierarchy easier to understand and use:
- InfoBase is unbound from Base, and downstream classes use multiple inheritance
to work "info" objects
- MIME types are separated from Base into a separate TypedBase class because
MIME typing is not common to all content kinds.
|
|
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).
|
|
|
|
QString msgType allows non-standard types (we don't want to restrict clients to types from the spec)
|
|
mimeType is relevant to most of the content types, and at the same time getting a MIME type in a generic way is handy for clients to uniformly detect whether they can display the content and what renderer to use for it.
|
|
RoomMessageEvent and MessageContentEvent::* classes have been massively overhauled to enable creation of m.room.message events locally instead of from JSON.
|
|
|
|
The biggest change is we have no pimpls in Event objects anymore - because it's two new's instead of one per Event, and we have thousands and even more of Events created during initial sync. The other big change is introduction of RoomEvent, so that now the structure of events almost precisely reflects the CS API spec. The refactoring made UnknownEvent unnecessary as a separate class; a respective base class (either RoomEvent or Event) is used for this purpose now. All the other changes are consequences of these (mostly of RoomEvent introduction).
|
|
Mainly it's about const-ification (in particular, passing const-refs instead of values) and deleting unneeded declarations/#includes. Since the changes alter the external interface, this is submitted as a PR for peer review.
One of unneeded declarations/definitions is a virtual destructor in BaseJob descendants. Since a job object should be deleted through QObject::deleteLater() anyway (and it's the only correct way of disposing of the object), all deletions will call the stack of destructors through virtual QObject::~QObject(). Therefore even BaseJob could get on with a non-virtual destructor but for the sake of clarity BaseJob::~BaseJob() is still declared virtual.
|
|
|
|
The spec is told to allow any event to have a thumbnail in future, and the thumbnail will reside under "content" JSON key rather than "info".
|
|
|
|
TextContent is a class to deal with formatted (HTML, RTF, Markdown) text messages. Right now it only supports Vector's non-standard "formatted_body".
|
|
|
|
According to the spec, this key has the same status as msgtype: both should exist in any message. Besides, it's always supposed to be a plain text so there's no polymorphism allowed here.
|
|
|
|
Fortunately, the clients don't seem to use it atm.
|
|
|
|
|
