Starting in #4916, upon startup wxWidgets pops up an assertion error:
> ./src/common/cmdline.cpp(527): assert ""Assert failure"" failed in
> FindOptionByAnyName(): Unknown option verbose
Fix this by overriding wxApp::OnCmdLineParsed to disable the default
handling (since we also disable the default options in
DolphinApp::OnInitCmdLine).
wxWidgets causes a segfault if Host_ConnectWiimote is called and we try
to create an event from the Wiimote scanner thread while the GUI is
still initialising.
Dolphin no longer lowers itself below the top window when opening.
Dolphin no longer draws garbage lines all over the game list.
Use the correct platform macros so Dolphin can actually find the
translation catalogs on Unix.
When 5.0-211 updated wxWidgets to 3.1.0, some entries in the
wxLanguage enum were moved and added, changing the wxLanguage
values. Because we save Dolphin's interface language to disk
as a wxLanguage, the language you have set will mean something
different depending on whether you have the updated wx version
or not. For instance, setting the language to English with the
updated version and then using an older version will make
Dolphin use Dutch. Because we can't rely on the enum anymore,
I'm replacing the "Language" setting with a "LanguageCode"
setting that uses standard ISO 639 codes.
This is something that was quite confusing for me while trying to get
netplay to work for me; once the Connect/Host buttons were pressed,
the UI would hang, only to work again a few seconds later, but with
no error message or explanation *at all*.
Turns out this is because panic alerts are shown in the netplay window
instead during netplay, even before it is even shown.
This fixes it by "piping" the alerts to the netplay chat only if the
netplay window is visible.
(regression introduced in #3823)
Fully opt-in, reports to analytics.dolphin-emu.org over SSL. Collects system
information and settings at Dolphin start time and game start time.
UI not implemented yet, so users are required to opt in through config editing.
EndPlayInput runs on the CPU thread so it can't directly call
UpdateWantDeterminism. PlayController also tries to ChangeDisc
from the CPU Thread which is also invalid. It now just pauses
execution and posts a request to the Host to fix it instead.
The Core itself also did dodgy things like PauseAndLock-ing
from the CPU Thread and SetState from EmuThread which have been
removed.
This check is not useful anymore since that website is not running their own
buildbots anymore. It's also trivially bypassable -- it just happened to work
when the builds were fully automated over there.
Previously, MacOpenFile only overrode anything on OS X; otherwise it was
just a useless method, which is presumably why it wasn't marked override
in the first place. Address this more sanely by wrapping it in #ifdef
__APPLE__.
Core::Shutdown was only called on app exit, yet the emu thread exits
whenever emulation stops; if you launched a new game it would just join
via the destructor when s_emu_thread was set to a new thread.
(Incidentally, the destructor also makes explicitly joining on app exit
rather pointless.)
Because the GUI thread wasn't waiting for the CPU thread to fully shut
down, Core::IsRunning would remain true briefly after CFrame::DoStop
which, given Dolphin's penchant for accessing variables belonging to
other threads, can only mean trouble... In my case, because the previous
commit caused UpdateGUI, which is called at the end of DoStop, to call
PauseAndLock, which checks IsRunning, pressing stop at the right time
would cause strange behavior.
Michael Maltese