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.
* Add account type column in accounts page
* Show account type in account chooser
* Allow set skin and delete skin only on mojang accounts
* Rename Offline mode to Local
* Add injector
* Add uuid generation for profile
* Add auth server emulator
* Start auth server on random port and bypass it to injector
* Run injector only when account type is dummy
* Clean authlib injector
* Add ely by authentication
* Remove old comments
* Add response status text to auth server
* Fix json value access
as done by @maximmasterr
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.
