macOS seems to dislike changing files in the APPBUNDLE.app/Contents directory because it has to re-scan the directory every launch. As a result, large amounts of data there seems to cause freezes of MultiMC. Moving the default location outside of this directory, and thus the data, stops these freezes.
There is also a dialogue when the user first opens the app that asks them if they'd like to migrate their data folder, if they select yes it will move it, and if they select no it will not move it and allow them to move it later with an option in settings.
Resolves a bug that was introduced with [1], furthermore and in
specific relation to the intent of said commit, this brings the
version selection combo box inline with other mod platforms.
[1] f7c144c393
Fixes GH-3118
Fixes GH-3720
Fixes GH-3731
Icons and Ok button state will now switch consistently when moving
between tabs. ATLaunchers packlist is now no longer redownloaded
each time you open its Tab. All lists are striped now. And all
search and filter fields now have a placeholder text.
Support URLs (bug tracker, Discord guild, subreddit) are now specified
as cache variables in cmake, and the buttons are not shown if no value
is set for them.
This is an early-stage move towards debranding the MultiMC codebase,
and will (hopefully) alleviate support requests coming to us from
illicit forks.
Presumably this is caused by the bump to GCC 11 in Fedora 34. See
the error that did occur below...
./MultiMC5/application/KonamiCode.cpp: In member function ‘void KonamiCode::input(QEvent*)’:
./MultiMC5/application/KonamiCode.cpp:38:23: error: comparison of integer expressions of different signedness: ‘int’ and ‘std::array<Qt::Key, 10>::size_type’ {aka ‘long unsigned int’} [-Werror=sign-compare]
38 | if(m_progress == konamiCode.size())
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
This resolves an issue with the modpacks.ch search functionality, in
which a search issued while one is currently in progress won't be made
and the UI won't allow for the search to be made after.
Reproduction Steps:
1. Open the FTB pane in the Add Instance Dialog
2. Perform a search while MMC is still performing the initial search
The search won't be performed, the existing search will have been
aborted, and you are unable to try the search again (without trying a
different search in the meantime).
This was caused by 2 things:
1. A search cannot be re-attempted, and this logic doesn't consider
failures.
2. The failure slot wasn't called when the NetJob was aborted, so
the search would never be performed - but the term would be
stored as if it had (trigering point 1).
I have resolved this by doing 2 things:
1. If the failure slot is called, set a searchState of Failed. Allow
search re-attempts in this case.
2. If there is a present NetJob, abort and reset it. The immediately
continue with the search.
