These help us keep track of relevant metadata information about
overrides, so that we know what they are when we update a pack.
Signed-off-by: flow <flowlnlnln@gmail.com>
This parses the pack format ID and the description from the local file,
from both a ZIP and a folder, and hooks it into the model.
Signed-off-by: flow <flowlnlnln@gmail.com>
In order to access the ModFolderModel from the ModFolderPage, i created
a new m_model for the correct type, shadowing the m_model of type
ResourceFolderModel. This creates two shared_ptr references to the same object,
but since they will have the same lifetime, it doesn't generate a memory
leak.
Signed-off-by: flow <flowlnlnln@gmail.com>
This aims to continue decoupling other types of resources (e.g. resource
packs, shader packs, etc) from mods, so that we don't have to
continuously watch our backs for changes to one of them affecting the
others.
To do so, this creates a more general list model for resources, based on
the mods one, that allows you to extend it with functionality for other
resources.
I had to do some template and preprocessor stuff to get around the
QObject limitation of not allowing templated classes, so that's sadge :c
On the other hand, I tried cleaning up most general-purpose code in the
mod model, and added some documentation, because it looks nice :D
Signed-off-by: flow <flowlnlnln@gmail.com>
This allows us to create other resources that are not Mods, but can
still share a significant portion of code.
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 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>
Those tasks take a list of mods and check on the mod providers for
updates. They assume that the mods have metadata already.
Signed-off-by: flow <flowlnlnln@gmail.com>
This task is responsible for checking if the mod has metadata for a
specific provider, and create it if it doesn't.
In the context of the mod updater, this is not the best architecture,
since we do a single task for each mod. However, this way of structuring
it allows us to use it later on in more diverse scenarios.
This way we decouple this task from the mod updater, trading off some performance
(though that will be mitigated when we have a way of running arbitrary tasks
concurrently).
Signed-off-by: flow <flowlnlnln@gmail.com>
Calls added:
- Get version from hash
- Get versions from hashes
- Latest version of a project from a hash, loader(s), and game version(s)
- Latest versions of multiple project from hashes, loader(s), and game version(s)
Some of those are not used yet, but may be of use later on, so we have
it if we need it :)
Signed-off-by: flow <flowlnlnln@gmail.com>
This is a variation of a Sequential Task, in which a subtask failing
will prompt the next one to execute, and a subtask being successful will
stop the task.
This way, this can be used for easily managing fallbacks with tasks. :D
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>
