| Age | Commit message (Collapse) | Author |
|---|
|
Avoids lots of code duplication
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Preventing undefined behaviour hooray! :D
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
When you change a copy thinking you're changing the original data smh
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Always scale mod icons to the right size
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
i forgor macos is cringe with static arrays :skull:
edit: WHY DONT MAC LET ME USE STD::ARRAY ;----;
|
|
|
|
|
|
|
|
Make it more consistent with the others
|
|
|
|
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...
|
|
|
|
chore: add license header
|
|
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.
|
|
my lsp is weird sometimes
|
|
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)
|
|
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.
|
|
Since there's little difference between them, let's remove duplication
and merge them.
|
|
|
|
|
|
|
|
|
|
|
|
Also having a mod loader is now enforced
|
|
|
