| Age | Commit message (Collapse) | Author |
|---|
|
This way, we don't get stuck with an aborted job in our way! :o
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
|
|
Projects with no icon return a null icon URL in Modrinth's API.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
THis fixes a FIXME, now that we fixed the issue :o
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Some more UI / UX improvements to the mod downloader!
|
|
Avoids lots of code duplication
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>
|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
I've discovered even more functional programming! :^)
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
I've discovered functional programming :^)
This makes this route more fit for general use.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
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>
|
|
Preventing undefined behaviour hooray! :D
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
|
|
More links for CF / Modrinth mods / modpacks
|
|
|
|
|
|
Makes it easier to find which mods are selected in case you want to
change those.
|
|
|
|
|
|
|
|
Still needs a clear indication that the filter only applies after you
click the search button...
|
|
|
|
|
|
|
|
Update Credits and Branding
|
|
|
|
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.
|
|
Also removes unused imports and organize the ModModel header
|
|
|
|
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)
|
|
|
|
|
|
This seems more reasonable
|
|
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.
|
