This avoids them getting deleted when the worker thread exits, due to
thread affinity on the created thread.
Signed-off-by: flow <flowlnlnln@gmail.com>
This allows us to emit all the necessary stuff when we're finished in
the case of starting a task with no subtasks. In particular, this caused
the mod updater to not work properly :)
Signed-off-by: flow <flowlnlnln@gmail.com>
This uses the proper version list to find all MC versions matching the
major number (_don't say anything about SemVer_ 🔫).
Signed-off-by: flow <flowlnlnln@gmail.com>
This fixes an issue in which, when adding a new resource pack externally
to PolyMC, when the resource pack view was open, would crash poly.
Signed-off-by: flow <flowlnlnln@gmail.com>
This takes care of evicting entries when the cache gets too big for us,
so we can add new entries without much worries.
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 a way, sequential tasks are just concurrent tasks with only a single
task running concurrently, so we can remove LOTS of duplicated logic :)
Signed-off-by: flow <flowlnlnln@gmail.com>
This fixes an annoying issue where concurrent tasks would try to start
multiple tasks even when there was not that many tasks to run in the
first place, causing some amount of log spam.
Signed-off-by: flow <flowlnlnln@gmail.com>
TIL that zip resource packs, when disabled, actually have the effect of
not showing up in the game at all. Since this can be useful to someone,
I moved the logic for it to the resources.
Signed-off-by: flow <flowlnlnln@gmail.com>
If the update never ends, the signal is not emitted and we become stuck
in the event loop forever. So a very lenient timer is added to prevent
that.
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 moves the QSortFilterProxyModel to the resource model files,
acessible via a factory method, and moves the sorting and filtering to
the objects themselves, decoupling the code a bit.
This also adds a basic implementation of methods in the
ResourceFolderModel, simplifying the process of constructing a new model
from it.
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 makes it possible to run a task in another thread.
I added a variable to toggle debug prints because they seem to trigger
an assertion on Qt internals when the task in on another thread. Of
course, this isn't awesome, but can wait until we improve our logging.
Signed-off-by: flow <flowlnlnln@gmail.com>
this should find java installs from scoop as well as any other installer, that registers java in the PATH environment variable.
Signed-off-by: Tayou <tayou@gmx.net>
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>
