The audio backend option automatically gets disabled when
emulation is running, so it's pointless to tell people what
would (not) happen if they changed the audio backend while
emulation is running.
Also removes the unused Event_Adapter event stub which did nothing. It
wasn't even hooked up to wx's event system.
Allows removing several includes from the header file and moving them to
the cpp file. Prevents includes being dumped into other source files
that include the header.
This uncovered an indirect include in Main for MsgHandler utilities.
I replaced "1x IR" with "native internal resolution" because
the IR setting never says "1x" or "IR", and I also did some
minor rewording and normalized the sentence-ending spaces.
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.
This is only ever queried and not set outside of the Core.cpp, so this
should just be hidden internally and just have a function exposed that
allows querying it.
wxQueueEvent/wxPostEvent are useful when the event is being dispatched
to another separate window, but aren't really necessary when the event
will be handled by the same window it's dispatched from.
GetEventHandler() is unnecessary here for the same reason. It's an event
intended to be handled by the dialog itself.
As all UI controls are essentially constructed with new expressions, the
type is already visible on the right-hand side, so repeating the type
twice isn't necessary.
This clashes with X11's preprocessor define named Success (because using
non-prefixed lowercase identifiers in C was apparently a fantastic idea
at some point), causing compilation errors.
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.
JosJuice