* Move out boot parameters to a separate struct, which is not part
of SConfig/ConfigManager because there is no reason for it to
be there.
* Move out file name parsing and constructing the appropriate params
from paths to a separate function that does that, and only that.
* For every different boot type we support, add a proper struct with
only the required parameters, with descriptive names and use
std::variant to only store what we need.
* Clean up the bHLE_BS2 stuff which made no sense sometimes. Now
instead of using bHLE_BS2 for two different things, both for storing
the user config setting and as a runtime boot parameter,
we simply replace the Disc boot params with BootParameters::IPL.
* Const correctness so it's clear what can or cannot update the config.
* Drop unused parameters and unneeded checks.
* Make a few checks a lot more concise. (Looking at you, extension
checks for disc images.)
* Remove a mildly terrible workaround where we needed to pass an empty
string in order to boot the GC IPL without any game inserted.
(Not required anymore thanks to std::variant and std::optional.)
The motivation for this are multiple: cleaning up and being able to add
support for booting an installed NAND title. Without this change, it'd
be pretty much impossible to implement that.
Also, using std::visit with std::variant makes the compiler do
additional type checks: now we're guaranteed that the boot code will
handle all boot types and no invalid boot type will be possible.
This is something that should be the responsibility of the frontend
booting the game. Making this part of the host 'interface' inherently
requires frontends to leak internal details (much like the other
UI-related functions in the interface).
This also decouples more behavior from the debugger and the
initialization process in the wx frontend. This also eliminates several
usages of the parent menubar in the debugger code window.
Simple quality-of-life addition that allows "uninstalling" WADs
(removing the corresponding installed title) from the NAND.
The option is only enabled when the WAD can be uninstalled
The motivation for this is actually to encourage proper usage of the
WAD launch feature (installing it to the NAND first), so we can
drop the "direct WAD title launch" hack.
When playing a game on OS X, although the screen does not go to
sleep, the screensaver is still enabled, and therefore, during
gameplay, the screensaver may start running, which is not in
accordance to the behaviour on other other environments (Windows
and X11). It can be argued that the screensaver interrupting
gameplay is a nuissance to many players.
The changes in this commit are intended to allow Dolphin to disable
the screensaver during gameplay, just as intended on other platforms.
The changes have been tested on OS X 10.11 (El Capitan).
Rather than destroy and reinitialize the dialog whenever it's closed,
and opened this dialog can just be hidden from view when it's not
needed, and shown again when it is needed.
Also, a dialog should really not be managing any live instances of
itself, including the one directly in the main frame.
This gets rid of another usage of the main frame global.
Amends the TAS callbacks to internally store functions using
std::function instead of raw function pointers. This allows binding
extra contextual state via lambda functions, as well as keeping the
dialogs internal to the main frame (on top of being a more flexible
interface).
This is currently unused and shouldn't actually be a part of the frame's
public interface. The event system should be used instead to dispatch
messages to the game list control if necessary.
Any functions left exposed are used elsewhere through the main_window
global. May as well prevent any more functions from being used in that
manner where possible.
Utilizes the event system (which is what should have been done here
initially), in order to prevent coupling between two different window frames.
This also makes booting games more versatile using the UI event system,
as the event can just act as a carrier for the filename, making directly
calling boot functions unnecessary. All that's needed is for the event to
propagate to the frame.
This fixes a bug which caused Movie (input recording or playback) or
netplay not to be stopped. DolphinWX previously triggered a STM power
event, and then the STM directly stopped the emulation; the code
which stops Movie/Netplay was completely skipped.
This is fixed by moving it /before/ sending the shutdown event.
OnBootDrive used the "drives" member std::vector for drive paths, but
since PR #4363, this vector is not populated anymore, so we were
accessing it out of bounds.
Actually, drives was not needed in the first place, since we can
get the wxMenu from the event, and from there, get the label directly.
This eliminates public usage of the GetMenuBar() function in CodeWindow.
The benefit of this is it also gets rid of the need to perform direct
access across the config dialog and the main frame. It also gets rid of
the use of the main_frame global.
GetMenuBar() will be removed entirely from CodeWindow in a follow-up that
also removes any related remnants of code made obsolete with its removal.
Gets rid of more menu-related code from CodeWindow and puts it back in
CFrame where it belongs.
This turns the previous menu update function within CodeWindow into one
that simply updates the debugger font for its managed controls. It also
improves how the font is actually updated. Previously, fonts would change,
however this wouldn't actually reflect onto the respective controls until
a refresh or update event occurred. Since codeview, callstack, symbols,
callers, and calls windows are all managed by a wxAuiManager instance,
calling Update() on it after the font has been set will reflect font
changes immediately.
On Linux, the FindFocus method from wx simply doesn't work, it would on some environment report that dolphin has the focus while it doesn't have it. This is why an alternative method has to be used which is to set a focus flag whenever the render frame gets activated.
Unifies the creation of all the menus into the main frame class.
Now it isn't spread out across the main frame and the code window.
This doesn't alter the placement of the handling functions, as this would
involve unrelated changes, since it would require modifying where
window-related variables are placed. This will be amended in a follow up
changeset.
Keeps related menu items together based on top level menu. This will be
more convenient in the future when debugger menu bar item handling is
moved to CFrame, as it won't be a huge amount of code in one function.
This also makes it easier to locate menu bar code whenever it needs to be
changed.
Leo Lam