I didn't know that telling that you don't schedule from the CPU thread prevents an assert because it by default assumes you use the CPU thread, but in the case of ClearCacheThreadSafe, it's used from the GUI thread.
If the strings for the debugger shouldn't be included
in translations, we simply shouldn't use any translation
macro for those strings, instead of having a special
check to exclude debugger-related code from being
searched for translatable strings.
The "Debug" check is a hack that essentially nobody has
been aware of (including me). For instance, 14facbc made
a lot of strings translatable just because they were
moved to a file that doesn't have "Debug" in its path,
and as far as I know, nobody noticed that change until
the newly translatable strings were live on Transifex.
Commit 4969415 modified calls to GetInterpolationQualifier, but mistakenly changed the order of some boolean parameters: GetInterpolationQualifier(true, false) was changed to GetInterpolationQualifier(…, false, true).
Should fix#9783.
On macOS, wxWidget’s tooltip.mm tries to include a system header with an improper capitalization (Appkit instead of AppKit), which causes the build to fail if the system headers are located on a case-sensitive filesystem.
Currently, `g_controller_interface` is initialized and shut down by each
of `GCKeyboard`, `GCPad`, `Wiimote`, and `HotkeyManager`.
This 1) is weird conceptually, because it necessitates passing a pointer
to the native window to each of those classes, which don't need it, and
2) can cause issues when controller backends are initialized or shutdown
multiple times in succession.
For Wii graceful shutdown to work, the emulated software has to open
the STM event hook and install a hook. Without this, there is no way
to inform them about the shutdown, so trying to do a graceful shutdown
and requiring the use of the shutdown fallback (exiting a second time
to force) is pointless.
Previously Dolphin would only exit if the main window is closed,
and Confirm on Stop is enabled.
This makes Dolphin's behaviour more consistent by always exiting
if the main window is closed or on shutdown signal.
s_dvd_thread_done_working makes the logic more complicated,
and degasus pointed out a race condition that can happen if
the CPU thread calls WaitForIdle right in between the DVD
thread executing done_working.Set() and done_working.Reset()
while there is work left to do. To avoid this, let's just get
rid of s_dvd_thread_done_working. It's a relic from the old
DVDThread design. Thanks to the last few commits, WaitUntilIdle
only gets called rarely (disc change and savestate), so it's
not a problem if WaitUntilIdle ends up being slower.
Léo Lam