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>
This could cause issues on some environments. Users should just put
MangoHud libs into global LD_LIBRARY_PATH, just like with any other
library
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Even though it was using a QMutableHashIterator, sometimes it didn't
work quite well, so this is a bit better.
Signed-off-by: flow <flowlnlnln@gmail.com>
Since network requests are, for the most part, asynchronous, there's a
chance a request only comes through after the request sender has already
been deleted.
This adds a global (read static) hash table relating models for the mod
downloader to their status (true = alive, false = destroyed). It is a
bit of a hack, but I couldn't come up with a better way of doing this.
To reproduce the issue before this commit: scroll really quickly through
CF mods, to trigger network requests for their versions and description.
Then, in the middle of it close the mod downloader. Sometimes this will
create a crash.
Signed-off-by: flow <flowlnlnln@gmail.com>
It has a delay of 350ms from the last typed character to search, in
order to cache small changes while typing.
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>
Heavy workloads can consume a ton of time doing their stuff, and starve
the event loop out of events. This adds an event processing call after
every concurrent task has been completed, to decrease the event loop
stravation on such loads.
Signed-off-by: flow <flowlnlnln@gmail.com>
For some reason, using setFilterFixedString() doesn't seem to update the
QRegularExpression object with a new value, instead leaving it empty. It
updates QRegExp just fine, so maybe that's an Qt bug? o.O
Anyway, using regex in the filter is kinda cool actually :D
Signed-off-by: flow <flowlnlnln@gmail.com>
This uses the 'Age', 'Cache-Control' and 'Expires' HTTP headers to more
accurately set up the cache lifetime, falling back to a static 1-week
time if they're not present in the response.
Signed-off-by: flow <flowlnlnln@gmail.com>
Before this change, you had to specify custom LD_* variables using the
prefix GAME_LD_*. Now instead of dropping all LD_* variables by default,
we should just filter them and remove the values we *know* are from our
start script.
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>
- Get Project: Already existed but required a specific caller type. This
is more general.
- Get Projects: A single call to multiple of the above
Both providers support these calls.
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 is, in many cases, more reliable than name comparisons, so it's
useful specially in cases where a mod changes name between versions
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>
The Modrinth changelog is fairly straight-forward, as it's given to us
directly with the API call we already did. Flame, on the other hand,
requires us to do another call to get the changelog, so it can introduce
quite a heavy performance impact. This way, we make it optional to get
such changelog.
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>
Previously, it would not update the global counter if the subTask didn't
update its progress, even though progress was being made.
This also prevents a segmentation fault while aborting the task.
Signed-off-by: flow <flowlnlnln@gmail.com>
This is to prevent problems where the cache entry would still be used
way after the remote resource got updated. The limit is hardcoded for 1
week, which I think is a reasonable time, but this could be further
tweaked.
Signed-off-by: flow <flowlnlnln@gmail.com>
This is needed so that we can show time stats in the UI without having
to load all type-specific settings, which would make all the previous
changes useless :c
This is apparently done with console settings too, so I don't think
there's a problem doing this too :>
Signed-off-by: flow <flowlnlnln@gmail.com>
