When rendering to the main window, the wxGLCanvas should really
be owned by the DolphinWX code for it to be safely freed.
Hack around the problem by just hiding the canvas for now.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6890 8ced0084-cf51-0410-be5f-012b33b47a6e
a document icon.
Don't bother creating the game list until after an automatic
start has finished and with the -b option, not at all.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6884 8ced0084-cf51-0410-be5f-012b33b47a6e
and disconnect any wiimotes.
The Windows code has special handling of both exceptions
and bluetooth connection state, neither of which I really
understand, so this is enabled on the other platforms only.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6821 8ced0084-cf51-0410-be5f-012b33b47a6e
Put the filename back into the "Saving settings ..." notice log (soren don't remove this again.)
Added a "batch" mode command line option. Now dolphin will not exit with the emulator if a file is run from the command line unless you also use the "batch" option. For example in linux "dolphin-emu -b -e filename".
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5859 8ced0084-cf51-0410-be5f-012b33b47a6e
normally (on a fresh install) be triggered by the user clicking on
the GUI.
This notably includes refreshing the game list. The progress dialog
used in the course of updating the game list relies on wxWidgets
being able to yield to its event handler which isn't started until
after OnInit.
In fact, we might want to consider just moving all the initialization
currently triggered by OnInit into AfterInit so that we can rely on
the event handler running there. This would mean that we don't have to
worry about whether those code paths are triggered by a user click or
run at init time. This will require some more testing, though.
For now just move automatic booting along as this requires the game
list initialization to be done.
We also could instead choose to special-case cases like updating the
game list and simply not use a progress dialog there if the event
handler isn't running, but this approach is clearly cleaner.
See thread at http://code.google.com/p/dolphin-emu/source/detail?r=5848 .
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5849 8ced0084-cf51-0410-be5f-012b33b47a6e
Some general code cleanup, and removed a PanicAlert (made it a NOTICE_LOG instead) so that only one panic alert is shown when attempting to load from dvd/cdrom drives, and none are shown when "Show Drives" is selected from the menu.
Also removed the hack introduced in revision 5564 that prevents the GameListCtrl from being properly updated when a game is loaded from the command line or via the autostart feature of the debugger.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5848 8ced0084-cf51-0410-be5f-012b33b47a6e
game list, rely on the main event handler already running, which isn't
the case until after OnInit(). This is a problem when an ISO directory
is already set at startup.
To deal with such actions that can only properly be done after the wx
environment is fully functional, schedule AfterInit() where the initial
game list scan is done.
The underlying icon object for wxIcon on OS X didn't work with our
(non-square?) 96x32 game list graphics, but we weren't using any wxIcon
properties such as transparency anyhow, so just skip the wxBitmap to
wxIcon back to wxBitmap conversions.
Use wxID_ABOUT and wxID_PREFERENCES so that those menu items are
automagically teleported to their canonincal locations on each platform.
USE_XPM_BITMAPS has been implicit on all platforms for some time now.
AddGrowableCol() causes problems in a couple of inessential places for
some unknown reason, even though the same pattern works fine elsewhere.
These changes make us play a lot nicer with wxWidgets 2.9.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5564 8ced0084-cf51-0410-be5f-012b33b47a6e
Soren Jorvang