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.
The UI should decide on where it wants the user directory, not our core system.
This is in anticipation of some upcoming work on Android which will need proper user directory setting.
My recent update to that check broke compilation on 10.9:
https://code.google.com/p/dolphin-emu/issues/detail?id=7900
However, on further review, the check isn't actually necessary. If the
OS X version is older than LSMinimumSystemVersion in Info.plist, the
system will generally refuse to run the binary in the first place. You
can try to launch it via a terminal, but at that point it's the user's
problem if it crashes.
