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>
It has a delay of 350ms from the last typed character to search, in
order to cache small changes while typing.
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 makes ModDownloadTask into a SequentialTask with 2 subtasks:
Downloading the mod files and updating the index with the new
information.
The index updating is done first so that, in the future, we
can prompt the user before download if, for instance, we discover
there's another version already installed.
This hopefully makes it easier to the user to know that their changes
will only apply after hitting the search button.
I tried setting the background color, but it seems more unreliable on
cross-platform than underlining. Also, it could be worse for daltonic people,
so I don't know what to do :(
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.
