This fixes a memory leak that would occur when the Android frontend
calls LogManager::Init more than once in order to reload settings.
Note that the log window listener is now owned by LogManager instead of
by the frontend, making it consistent with the other log listeners.
Remove ConfigChangedCallback in MainWindow's destructor to prevent the
callback from accessing the destroyed MainWindow afterward.
After MainWindow is destroyed UICommon::Shutdown calls
LogManager::Shutdown which ultimately triggers any remaining callbacks.
This resulted in calling MainWindow::OnHardcoreChanged, which crashed in
debug builds and didn't have any obvious effect in release builds.
Fixing an oversight: this was causing the debugger to be disabled if achievements were disabled but hardcore mode was still enabled in the .ini. This fix properly checks for hardcore state via AchievementManager which takes both settings into account.
Removed VolumeChanged signal, as ConfigChanged will trigger what is needed.
Only applies UpdateSoundStream to things that can change during emulation.
Settings::SetVolume might no longer be used, but left it in.
Gecko codes in Dolphin feature a dedicated field for the creator of the
cheat code. When saved into the INI file, the code name and the creator
name are concatenated, and then inserted in the `[Gecko]` section:
```ini
[Gecko]
$<cheat code name> [<creator>]
<code line 1>
<code line 2>
<code line 3>
<...>
$<other cheat code name> [<creator>]
<code line 1>
<code line 2>
<code line 3>
<...>
```
On the other hand, enabled codes are listed under the `[Gecko_Enabled]`
section, but in this case the creator name is omitted from the line:
```ini
[Gecko_Enabled]
$<cheat code name>
$<other cheat code name>
```
Having the creator name in the `[Gecko]` section but not in the
`[Gecko_Enabled]` section is arguably not ideal, but this is legacy
behavior in Dolphin.
The **Cheat Code Editor** dialog is not acknowledging this subtle
behavior in Dolphin: the cheat code name and the creator name *can* be
both inserted in the name field. This issue manifests as an inconsistent
state where a Gecko code that *appears* to be enabled has no effect when
the game is launched.
As part of this fix, the creator name (if present) is now moved into the
dedicated creator field before the code is stored internally.
Test plan:
- Right-click on any game and open the **Properties** dialog.
- Switch to the **Gecko Codes** tab.
- Press the **Add New Code...** button.
- In the **Cheat Code Editor** dialog:
- Enter `This is a test [Jane Doe]` in the **Name:** field.
- Enter `01234567 00000000` in the **Code:** field.
- Press **Save**.
- Observe that the newly added code is now in the list, and *appears* to
be enabled.
- Close the **Properties** dialog.
- Right-click on the same game and open the **Properties** dialog again.
**Without** the fix, the newly added code, while still on the list, has
been inadvertently disabled (it was never really enabled!).
**With** the fix, the newly added code is the list and remains enabled.
This fixes https://bugs.dolphin-emu.org/issues/13695.
Fix the following bug:
* Have a moveable ImGui overlay enabled, such as the Statistics window.
* Pause the game.
* Click and hold on the overlay's title bar as if you were going to move
it. Because the screen isn't updating while the game is paused, you
won't be able to actually move the overlay.
* Press the Frame Advance hotkey several times until it stops
responding.
At this point emulation hotkeys are no longer responsive. This can be
resolved by selecting Play from the toolbar or menu, or selecting Frame
Advance from the menu a couple times, but it's annoying and not obvious
what's gone wrong or how to fix it.
Why the bug is happening:
* Doing a framestep while clicking on the overlay title bar causes ImGui
to set IO.WantCaptureKeyboard to true, indicating that ImGui is
requesting Dolphin ignore any keyboard events while the overlay is
being interacted with.
* Dolphin complies with this request, causing
Host_UIBlocksControllerState to return true and thus setting the input
gate to ignore input.
* IO.WantCaptureKeyboard is only updated when ImGui::NewFrame() is
called, which only happens at the end of each present. It thus remains
true indefinitely since the game paused after the last framestep, and
so Dolphin ignores any hotkeys such as the framestep or play keys.
The fix:
Ignore IO.WantCaptureKeyboard when the game is paused. ImGui can't
meaningfully capture input anyway when the game is paused, so this
shouldn't cause any problems elsewhere.
Once async presentation is implemented we'll want to revert this change,
both because it'll become unnecessary and because ImGui will be able to
do stuff while paused and so suppressing emulation hotkeys will actually
be useful.
