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>
Integrates support for Feral Gamemode, discrete GPU support for Mesa and the proprietary Nvidia driver and MangoHud support
Signed-off-by: Jan200101 <sentrycraft123@gmail.com>
Previously, the Shaders, Texture packs and Resource packs tabs had as
parent the ModFolderPage, making it so that making changes only to the
Mods page would require checking the id of the page for the correct one.
This was hackish and error-prone.
Now, those pages all inherit from a single class, ExternalResourcesPage,
that handles the basic behaviour of all of them, while allowing for
individual modification in code.
This is still not a clear separation, since internally, all those
resources are derived from Mods, so for now there's still some awkward
common code :/
* 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
- Very basic wizard just to allow the user to choose whether to keep
their old paste settings or use the new default settings.
- People who used custom 0x0 instances would just be kept on those
settings and won't see the wizard.
(Hopefully) this makes implementing updaters using external libraries easier on other platforms. To implement an updater on a new platform, create a new class that implements the pure virtual methods from `ExternalUpdater` and add code in the `UpdateChecker` initializer to initialize the new class.
To actually get automatic updates going, all that needs to happen is that `SparkleUpdater` needs to be initialized.
The rest of the functions can be connected to elements in the UI.
