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.
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.
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.
