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>
The new versioning system is based on the versioning system used by the
GNOME Foundation for the GNOME desktop.
We are dropping the "major version" as defined by SemVer and move to a
version number with a most and least significant number.
The most significant number must be incremented, if there are new
features or significant changes since last major release.
Otherwise, the least significant number must be incremented, if there
are only minor changes since the last release. New features or
significant changes mustn't be introduced by a bump of the least
significant number.
If a minor change would introduce small user-facing changes (like a
message-box or slight UI changes), it could still be classified as a
minor change.
At the end of the day, a human shall decide, if a change is minor or
significant, as there is no clear line that would separate a "minor" and
a "significant" change in a GUI-application.
Definitions:
feature: New user-facing functionality
significant change: Something that changes user-facing behavior
minor change: Something that fixes unexpected behavior
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Don't update disabled mods to prevent mod duplication. Also, chop
filename in the metadata with a '.disabled'.
Signed-off-by: flow <flowlnlnln@gmail.com>
This makes the metadata generation code a lot messier and harder to use,
but there's not really much else that can be done about it while
preserving all it's capabilities :(
At least we now have speed
Signed-off-by: flow <flowlnlnln@gmail.com>
This subclasses the Review mods dialog to make a "Update review" one.
Also, all the necessary components built until now are put together in a
coherent unity that checks and generates metadata on-the-fly and checks for
mod updates, while giving and receiving feedback to the user.
Signed-off-by: flow <flowlnlnln@gmail.com>
Allows you to prompt the user for choosing a (mod) provider. This should
be fairly independent of the mod updater logic, so it can be used for
other ends later down the road :^)
Signed-off-by: flow <flowlnlnln@gmail.com>
* Use the bulk endpoint on mod resolution for faster download
* Search on modrinth for api blocked mods
* Display a dialog for manually downloading blocked mods
This puts all mod downloading tasks inside a SequentialTask, which is,
for more than one task, a multi step task. This is handled by the
ProgressDialog by showing both the global progress of tasks executed,
and the individual progress of each of them.
Offline usernames longer than 16 characters won't be able to connect to
LAN games or offline-mode servers, so just don't let it happen.
Add a checkbox to allow people to unrestrict usernames if they want.
Signed-off-by: Jim Ramsay <i.am@jimramsay.com>
When selecting multiple mods at once, it can become hard to keep track
of which ones you selected.
To address this, a dialog is now displayed
when you finish selecting the mods to download, showing you which ones
you selected and their filenames. From there, you can either accept it
and download the mods, or you can cancel it and go back to the mod
selection dialog.
Previously, we used a unique_ptr to a ModDownloadTask to keep track of
the selected mod to download when we accepted the dialog.
In order to allow multiple mods to be selected at once for download,
this has been changed to a QHash where the key is the mods name (since
it doesn't seem right to allow for multiple versions of the same mod to
be downloaded at once), and the value is a pointer to the corresponding
ModDownloadTask.
Let's move off our custom QuaZip. In the olden times we needed the
custom version of QuaZip, as it was basically unmaintained and on
SourceForge (eww). But nowadays it's maintained and on GitHub. See
new GitHub page: https://github.com/stachenov/quazip
