This allows us to pass to the creation instances their actual pack ID
and version ID, that in Flame's case, are only available before starting
to create an instance.
Signed-off-by: flow <flowlnlnln@gmail.com>
While working on pack updating, instance naming always gets in the way,
since we need both way of respecting the user's name choice, and a
standarized way of getting the original pack name / version.
This tries to circunvent such problems by abstracting away the naming
schema into it's own struct, holding both the original name / version,
and the user-defined name, so that everyone can be happy and world peace
can be achieved! (at least that's what i'd hope :c).
Signed-off-by: flow <flowlnlnln@gmail.com>
This disables the optional mods by default and tell the user about it.
Pretty hackish, but a better solution would involve the modrinth
metadata to have the mod names...
Also sorry for the diffs, my clangd went rogue x.x
Things that don't work / work poorly (there's more for sure but those
are the evident ones):
- Icons are broken in the import dialog
- No way to search for private packs
- Icons are not downloaded when downloading a mod
- No support for multiple download URLs
- Probably a lot more...
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)
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.
