This must be done carefully though, because the call to SDL_WarpPointer
generates a mouse motion event of its own. To work around this, I have
added code that should ignore motion events generated by SDL_WarpPointer.
This should fix bug [ 619283 ] SDL: os mouse pointer leaves the window.
On Linux, SDL 1.2.3 it works fine.
bx_list_c can now be displayed as either a wxStaticBox with the
child parameters inside, or as a wxNotebook with each child
parameter in a separate tab. (The children can also be lists of
course.) The default display is the wxStaticBox type, but if you
set the option bit bx_list_c::USE_TAB_WINDOW in the list,
ParamDialog will use the wxNotebook display instead.
- to get the param trees working, I created a new struct
AddParamContext, which is passed to AddParam(). This struct is
critical when AddParam calls itself recursively to display lists
within lists.
- use the wxNotebook display feature for the ATA0,1,2,3 controller
dialog box. Now instead of being hundreds of pixels tall, it is
reasonable height with three different tabs. This fixed bug
#619074: "wx: ATA interface editor too tall" and was the whole
reason I started messing with this at all.
plus some minor cleanups
- when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also
removed the BX_ prefix from all the other enum constants that are
used in parameter options in siminterface.cc. Since these constants
are enums within a class, there is no possibility of namespace
conflicts so the prefix is not needed.
- added wxADJUST_MINSIZE to all wxChoice controls, since that tells
wxWindows to adjust its size to the length of the longest string.
- instead of calling SetSize or SetSizeHints on every textcontrol with
a hardcoded width, I am using just two wxSize specifications for
everything: either normalTextSize or longTextSize.
- edit names of a few menus and params. For example now instead of
the tab saying "Master ATA device on channel 0" it will say
"First HD/CD on channel 0".
Modified Files:
main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h
gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
to be signed instead of unsigned, it was looking up color values
like wxBochsPalette[-126] instead of wxBochsPalette[130]. This affected
any colors in the palette between 128 and 255. I simply hanged newBits
to signed, and it fixed bug #618462: wx: 256 color modes not working properly
- I am still not satisfied with the way that wxWindows maps colors on an
8-bit display, but that is a different issue.
after the palette changes. This makes the iodev/vga.cc code do the
right thing. This also fixes the toolstar splash screen, but at a
fraction of the cost of the solution in rev 1.37.
need to be updated. This was impossible before, because we only stored the
RGB values in wxScreen. I added a new array called wxPixel that stores the
8-bit color index that should be displayed. Now if the VGA palette changes,
I use wxPixel data to reconstruct wxScreen using the new palette.
- this fixes the display of the splash screen of the Toolstar disk, since
it relied on drawing the picture and then fading the colormap from back
up to the normal values. I was hoping it would fix the splash screen of
win95 too, but it does not.
so that windows types can be used in fields, for example in cdrom.h:
#ifdef WIN32
HANDLE cdrom_interface::hFile;
#endif
- since every file includes bochs.h, I removed includes of <windows.h>
everywhere else
- modified: bochs.h cpu/extdb.cc gui/win32.cc gui/wx.cc iodev/cdrom.cc
iodev/eth_win32.cc iodev/floppy.cc
instead of winmm being a part of GUI_LINK_OPTS_WIN32 only, it is
placed in @DEVICE_LINE_OPTS@ so that it will be used for sdl, rfb, wx,
etc.
- solve compile problems when building bximage, niclist, and any other
console based program. The compile flags returned by wx-config and
sdl-config did strange things to these console programs, for example
redefining main to SDL_main. Because I wanted to use the
configure-generated CFLAGS to compile the programs, but I wanted to
avoid including GUI specific compile options, I split up the configure's
@CFLAGS@ variable into @CFLAGS@ and @GUI_CFLAGS@, and split
@CXXFLAGS@ into @CXXFLAGS@ and @GUI_CXXFLAGS@. All programs in the
Bochs binary will use both, but the console programs will just use
@CFLAGS@ or @CXXFLAGS@.
- gui/Makefile.in, I no longer use the gui specific CFLAGS variables,
SDL_CFLAGS and WX_CXXFLAGS. These values are included in CFLAGS and
CXXFLAGS now.
- modified: configure.in, configure, all Makefile.in's
conditionally include <windows.h>. This may seem like a drastic step
for just one little type, but I expect before long we may want to use
other symbols like VK_F12 which are also in windows.h. In a cygwin
compile this is required.
on the wxWindows interface. There are many more changes here than
absolutely required to fix the memory leaks. Instead, I've tried to
clean things up so that it does the right thing, and is easier to
read and maintain.
- For events that the text mode interface is going to ignore anyway, I #ifdefed
the event creation code instead of calling new and then delete.
- now all synchronous events in siminterface.cc are created as local variables
on the stack. Some of them were allocated with new before, and yes some of
them leaked.
- now I ignore the result of sim_to_ci_event (&event). It was always
returning a pointer to the input event anyway. This makes the event
sending code simpler.
- wxmain.cc:
- in the BxEvent handling functions, now all cases "break" down to common
code at the end which deletes async events. This is easier to read than
having each case handle the delete individually.
- in OnLogMsg, do not delete the event here because it is now handled
in the common code of OnSim2CIEvent instead.
- thanks to Christophe for pointing out the location of the worst
memory leak.
- make bx_init_main return -1 if any parse errors occur.
- wxWindows: if bx_init_main returns -1, don't even show the application
window. You'll get an error dialog and then it exits. So far this
only happens if you run with -q and the parse fails.
- non-wxWindows: if bx_init_main returns -1, just exit. So far this
only happens if you run with -q and the parse fails.
- with these changes, handling of bochsrc parse errors seems to work
as you would expect. And it certainly doesn't go into an infinite
recursive loop, as it used to!
- a little more testing and I can close
bug 614175: infinite panic loop if bochsrc buggy
- modified: main.cc gui/siminterface.h gui/wxmain.cc
and into wxmain.cc, like other actions.
- set a default siminterface callback for the whole application, which is used
whenever the simulator is not running. This is important when the wx code
calls simulator or param code and triggers a BX_PANIC or something.
The default callback is responsible for displaying error messages which
appear while reading the bochsrc, for example.
- move the implementation of BX_SYNC_EVT_LOG_ASK and BX_ASYNC_EVT_LOG_MSG
into a separate function OnLogMsg(). In the future, OnLogMsg() may be called
from the application default callback on errors.
- modified: gui/wx.cc gui/wxmain.cc gui/wxmain.h
- Features :
. number of active channels defined at boot-time config
. new options in bochsrc
. up to 8 devices support (disks or cdroms)
. up to 4 cdrom devices can be changed at runtime config
. wxwindows config interface
parameter values associated with the dialog and updated the wxWindows
controls. At the time I didn't realize that I was overriding
wxWindow::Refresh() which repaints the window. Later, I renamed the method
to CopyParamToGui() to make it more clear, but many of the callers in
wxmain.cc continued to call Refresh(), which now reverted to the parent class
wxWindow::Refresh(). Since there was no compile error I didn't notice for a
while, but it caused the ParamDialogs to repaint themselves constantly but
never actually change their values. This is now fixed by changing those
method calls to CopyParamToGui().
started using a wxTimer to trigger the redraws. Now instead of calling
MyPanel::OnPaint directly, I call Refresh() instead. This makes the Windows
display work correctly.
I'm not sure why this wasn't needed before, but after switching to
wxWindows 2.3.3 it seems to be important.
- in a wxLogDebug() call I was trying to pass a struct instead of a string.
Fixed that.
