| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Necessary as the pixmap may be deleted at any moment if another caller
requests a differently sized pixmap.
|
|
|
|
|
|
| |
The pixmap should have the size requested and not the original size.
Note that it may be better to do resizing on the callee/method user side
as recreating a pixmap instead of scaling an existing one is expensive.
|
| |
|
|
|
|
|
|
| |
This should provide a light performance improvement as the QString is
built at compile time, with the generated data being stored in the
read-only segment of the built object file.
|
|
|
|
|
| |
This class still has improvements to be made, but it works and I am
satisfied with it!
|
|
|
|
|
| |
This allows terser usage and removes the need for manually invoking
QVariant's .value<T>() method.
|
| |
|
|
|
|
|
| |
Finish consolidating every AP…Field in one file to avoid circular
include dependencies which are very hard/impossible to work with.
|
|
|
|
|
|
|
| |
This commit adds support for dealing with ActivityPub Questions, which
are polls. They are like Notes (posts) but contain a few more keys that
record information about the poll options, number of votes and poll
closure date.
|
|
These objects allow, and will allow us, to move HTML rendering out of
the archive parser and into separate classes. Each of the derived
classes specialise HTML rendering for their specific requirements.
Furthermore, these ActivityPub objects will be able to be expanded upon
and have support to be written to disk, in a database, for instance.
Separating ActivityPub object retrieving from rendering allows us to
implement other retrieving sources and methods, such as downloading
posts from a configured remote instance.
|