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>
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>
The Modrinth changelog is fairly straight-forward, as it's given to us
directly with the API call we already did. Flame, on the other hand,
requires us to do another call to get the changelog, so it can introduce
quite a heavy performance impact. This way, we make it optional to get
such changelog.
Signed-off-by: flow <flowlnlnln@gmail.com>
We have been asked by CurseForge to remove this workaround as it
violates their terms of service. This is just a partial revert, as the
UI changes were otherwise unrelated.
This reverts commit 92e8aaf36f, reversing
changes made to 88a93945d4.
Right now we want to include Fabric mods in our searches where possible.
Modrinth allows definining multiple loaders, while Flame only allows a
single value.
As a compromise we ask for Fabric mods only on Flame and for both Fabric
and Quilt mods on Modrinth.
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.
Fixes#206 partially. Although we don't list mods that have no
compatibility with the mod loader we are using, mods that have support
for both loaders still show up, and the versions for both the loaders
are still shown.
Also simplifies a little the logic in
FlameModIndex::loadIndexedPackVersions
