This would cause ODR violations when those headers were included in
other places that also included stuff like "Version.h" (note the
"meta/Version.h"), which can cause problems, especially in LTO.
Signed-off-by: flow <flowlnlnln@gmail.com>
- Copy game options, copy resource packs, copy shaders,
copy servers, and copy mods
- Also made a new InstanceCopyPrefs struct to store those
options rather than passing 7 different booleans into
InstanceCopyTask's constructor
Signed-off-by: Marcelo Hernandez <marcelohdez.inq@gmail.com>
Make labels fit to the contents, so Ibeam cursor doesn't appear
over empty space. Should have been done with 90025ed.
Signed-off-by: jn64 <23169302+jn64@users.noreply.github.com>
Meaning we don't have to wait for the searches to finish in the
background to finally start the modpack download, when we have already
selected it -_-
Signed-off-by: flow <flowlnlnln@gmail.com>
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>
