- The launch option is no longer empty.
- The program now checks on startup whether an instance is selected to decide whether to disable instance options.
Also, get rid of a dynamic cast.
It wouldn't bring much utility.
- The keyboard shortcuts for copy/paste/etc. already work and are well-known. The menu bar likely doesn't need to advertise them.
- There's not very many places you would be able to use these options in the main window (because there's not many places to type stuff in the main window). It would only be applicable on systems with a native menu bar that shows in all other windows as well (but again, the keyboard shortcuts still work).
Also, rename `actionWiki` -> `actionOpenWiki` to match the corresponding `on_actionOpenWiki_triggered`
The code is now much cleaner.
Because the actions already present are enabled elsewhere even when the menu bar is hidden, keyboard shortcuts added to them automatically work regardless of whether the menu bar is visible. This means that the hacky workaround related to this can be removed.
Systems with native menu bars show the same menu bar for all child windows. As a result, you cannot assume that the menu bar's parent (the `MainWindow`) will be the window in focus.
This hopefully makes it easier to the user to know that their changes
will only apply after hitting the search button.
I tried setting the background color, but it seems more unreliable on
cross-platform than underlining. Also, it could be worse for daltonic people,
so I don't know what to do :(
Only applicable for systems without a native menu bar (i.e. almost anything that is not macOS or Ubuntu Unity). On these systems, the menu bar appears on top of the window, which does not look good next to the tool bar already up there.
When the menu bar is hidden, the keyboard shortcuts set by the menu bar are disabled. They should always work, so this also adds a workaround for that.
Some stuff still needs to be fixed:
- The close window option always closes the main window, even if it is not the currently active window (only applicable on systems with native menu bar)
- None of the (text) editing actions are enabled
- Actions related to instances should only be active when an instance is selected
- The open wiki option ("PolyMC Help") needs to be implemented
- Delete instance keyboard shortcut does not seem to work on my system. Test further
- It would be nice if the profiles menu had all of the logged in accounts, and if they could be selected from that menu (preferably with keyboard shortcuts, probably Ctrl + 1, Ctrl + 2, ...)
This mimics the behaviour that the Technic launcher has, and their
website displays API URLs for.
The big benefit of this, is to be able to install private packs now :)
This puts all mod downloading tasks inside a SequentialTask, which is,
for more than one task, a multi step task. This is handled by the
ProgressDialog by showing both the global progress of tasks executed,
and the individual progress of each of them.
This uses more arguments in the GET request for mod versions on the
Modrinth API, filtering what versions can be returned, decreasing load
on Modrinth servers and improving a little the time it takes for the versions to be
available to the user.
This also removes the now unneeded check on correct modloaders in
ModrinthPackIndex, since it is now filtered by the Modrinth server.
Lastly, this adds a couple of helper functions in ModModel.
Keep track of compatible Java versions from meta. Launch-step
VerifyJavaInstall will check if current instance's Java version is
compatible.
Also add override option both globally and per-instance in-case the user
doesn't care about the requirement.
Offline usernames longer than 16 characters won't be able to connect to
LAN games or offline-mode servers, so just don't let it happen.
Add a checkbox to allow people to unrestrict usernames if they want.
Signed-off-by: Jim Ramsay <i.am@jimramsay.com>
The checks used are roughly the same as the ones proposed in the
clang-tidy PR (except perhaps that I used modernize-* instead of listing
them individually,though I don't think this caused any readability
detriments).
In ModrinthModel.cpp and FlameModModel.cpp I ignored the
modernize-avoid-c-arrays one, mostly because making the sorts array an
std::array would most likely increase the code complexity because of the
virtual function. Aside from that, the static_cast warning from
Application.h was not dealt with, since it's not in this PR's scope.
This also adds some comments around ModModel.cpp and ModPage.cpp to add
some ease of reading the code.
Also move some things from headers to cpp files.
This is done so that 1. ModAPI behaves more like an actual API instead
of just a helper, and 2. Allows for more easily creating other mod
providers that may or may not use network tasks (foreshadowing lol)
Rename MultiMC to Legacy
Simple (Colored) is now the first icon theme
Custom is now the last icon theme, which also fixes a loading issue when
Legacy was selected
Fix loading of Legacy theme
Moves all things related to creating the URLs of the mod platforms
that go to network tasks to a single place, so that:
1. Maintaining and fixing eventual issues is more straightforward.
2. Makes it possible to factor out more common code between the
different modplatform pages
This creates a hierarchy in which ModPage and ModModel are the parents
of every mod provider, providing the basic functionality common to all
of them.
It also imposes a unique .ui file (they were already equal before, just
duplicated basically) on all mod providers.
Fixes#206 partially. Although we don't list mods that have no
compatibility with the mod loader we are using, mods that have support
for both loaders still show up, and the versions for both the loaders
are still shown.
Also simplifies a little the logic in
FlameModIndex::loadIndexedPackVersions
When selecting multiple mods at once, it can become hard to keep track
of which ones you selected.
To address this, a dialog is now displayed
when you finish selecting the mods to download, showing you which ones
you selected and their filenames. From there, you can either accept it
and download the mods, or you can cancel it and go back to the mod
selection dialog.
Previously, we used a unique_ptr to a ModDownloadTask to keep track of
the selected mod to download when we accepted the dialog.
In order to allow multiple mods to be selected at once for download,
this has been changed to a QHash where the key is the mods name (since
it doesn't seem right to allow for multiple versions of the same mod to
be downloaded at once), and the value is a pointer to the corresponding
ModDownloadTask.
