While implementing the resource pack downloader in another branch, I
noticed that most of the code in the success callback was identical in
both cases, safe for a few minute differences in strings. So, this tries
to make it easier to share this piece of code.
However, it still leaves the possibility of extending the methods in
ResourceModel to accomodate for cases where this similarity may not
hold.
Signed-off-by: flow <flowlnlnln@gmail.com>
This refactors the sorting methods to join every bit of it into a single
list, easing maintanance. It also removes the weird index contraint on
the list of methods by adding an index field to the DS that holds the
method.
Lastly, it puts the available methods on their respective API, so other
resources on the same API can re-use them later on.
Signed-off-by: flow <flowlnlnln@gmail.com>
This makes it so that we don't need a reference to the parent page in
the model. It will be useful once we change the page from a widget-based
one to a QML page.
It also makes tasks be created in the dialog instead of the page, so
that the dialog can also have the necessary information to mark versions
as selected / deselected easily. It also makes the task pointers into
smart pointers.
Signed-off-by: flow <flowlnlnln@gmail.com>
Puts them all inside the 'ResourceDownload' namespace, so that it's a
bit clearer from the outside that those belong to the same 'module'.
Signed-off-by: flow <flowlnlnln@gmail.com>
Firstly, this abstract away behavior in the mod download models that can
also be applied to other types of resources into a superclass, allowing
other resource types to be implemented without so much code duplication.
For that, this also generalizes the APIs used (currently, ModrinthAPI
and FlameAPI) to be able to make requests to other types of resources.
It also does a general cleanup of both of those. In particular, this
makes use of std::optional instead of invalid values for errors and,
well, optional values :p
This is a squash of some commits that were becoming too interlaced
together to be cleanly separated.
Signed-off-by: flow <flowlnlnln@gmail.com>
Since network requests are, for the most part, asynchronous, there's a
chance a request only comes through after the request sender has already
been deleted.
This adds a global (read static) hash table relating models for the mod
downloader to their status (true = alive, false = destroyed). It is a
bit of a hack, but I couldn't come up with a better way of doing this.
To reproduce the issue before this commit: scroll really quickly through
CF mods, to trigger network requests for their versions and description.
Then, in the middle of it close the mod downloader. Sometimes this will
create a crash.
Signed-off-by: flow <flowlnlnln@gmail.com>
This allows us to define custom painting for list view items. In
particular, this is applied to the mod downloader, in order to allow
displaying both the mod name and mod description, and settings their
effects (like bold or underline) independent of each other.
Signed-off-by: flow <flowlnlnln@gmail.com>
This uses more arguments in the GET request for mod versions on the
Modrinth API, filtering what versions can be returned, decreasing load
on Modrinth servers and improving a little the time it takes for the versions to be
available to the user.
This also removes the now unneeded check on correct modloaders in
ModrinthPackIndex, since it is now filtered by the Modrinth server.
Lastly, this adds a couple of helper functions in ModModel.
The checks used are roughly the same as the ones proposed in the
clang-tidy PR (except perhaps that I used modernize-* instead of listing
them individually,though I don't think this caused any readability
detriments).
In ModrinthModel.cpp and FlameModModel.cpp I ignored the
modernize-avoid-c-arrays one, mostly because making the sorts array an
std::array would most likely increase the code complexity because of the
virtual function. Aside from that, the static_cast warning from
Application.h was not dealt with, since it's not in this PR's scope.
This also adds some comments around ModModel.cpp and ModPage.cpp to add
some ease of reading the code.
Also move some things from headers to cpp files.
This is done so that 1. ModAPI behaves more like an actual API instead
of just a helper, and 2. Allows for more easily creating other mod
providers that may or may not use network tasks (foreshadowing lol)
Moves all things related to creating the URLs of the mod platforms
that go to network tasks to a single place, so that:
1. Maintaining and fixing eventual issues is more straightforward.
2. Makes it possible to factor out more common code between the
different modplatform pages
This creates a hierarchy in which ModPage and ModModel are the parents
of every mod provider, providing the basic functionality common to all
of them.
It also imposes a unique .ui file (they were already equal before, just
duplicated basically) on all mod providers.
