Domumentation updates and cleanups
This commit is contained in:
Volker Ruppert
parent
2aa810012a
commit
67b3157e13
@ -413,7 +413,7 @@ vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest
|
||||
|
||||
#=======================================================================
|
||||
# VOODOO:
|
||||
# This defines the Voodoo Graphics emulation.
|
||||
# This defines the Voodoo Graphics emulation (experimental).
|
||||
#
|
||||
# Examples:
|
||||
# voodoo: enabled=1, model=voodoo1
|
||||
|
||||
@ -127,6 +127,9 @@ display
|
||||
screenmode
|
||||
vga_extension
|
||||
vga_update_interval
|
||||
voodoo
|
||||
enabled
|
||||
model
|
||||
|
||||
keyboard_mouse
|
||||
keyboard
|
||||
|
||||
@ -42,9 +42,6 @@ HTML rendering of the documentation. Also, you can view the
|
||||
latest documentation on the web at
|
||||
http://bochs.sf.net/doc/docbook/index.html
|
||||
|
||||
Some information has not yet been transferred from the older
|
||||
HTML docs. These can be found at http://bochs.sf.net/docs-html
|
||||
|
||||
WHERE CAN I GET MORE INFORMATION? HOW DO I REPORT PROBLEMS?
|
||||
|
||||
Both the documentation and the Bochs website have instructions on how
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Readme for wxWidgets Interface
|
||||
updated Sat Dec 21 11:09:34 EST 2002
|
||||
Updated Tue Dec 24 09:54:00 CET 2013
|
||||
|
||||
Contributors to wxWidgets port:
|
||||
Don Becker (Psyon)
|
||||
@ -9,19 +9,18 @@ Contributors to wxWidgets port:
|
||||
|
||||
wxWidgets Configuration Interface
|
||||
|
||||
The wxWidgets port began in June 2001 around the time of Bochs 1.2.1. Dave
|
||||
Poirier and Bryce Denney started adding a wxWidgets configuration interface.
|
||||
We made some progress, but stopped after a while. Then in March/April 2002
|
||||
Bryce and Psyon revived the wxWidgets branch and turned it into a usable
|
||||
interface. Psyon did most of the work to get text and graphics working, and
|
||||
Bryce worked on event passing between threads, and keyboard mapping.
|
||||
Starting in August 2002, Bryce added lots of dialog boxes to allow you
|
||||
The wxWidgets (formerly called wxWindows) port began in June 2001 around the
|
||||
time of Bochs 1.2.1. Dave Poirier and Bryce Denney started adding a wxWidgets
|
||||
configuration interface. We made some progress, but stopped after a while.
|
||||
Then in March/April 2002 Bryce and Psyon revived the wxWidgets branch and turned
|
||||
it into a usable interface. Psyon did most of the work to get text and graphics
|
||||
working, and Bryce worked on event passing between threads, and keyboard
|
||||
mapping. Starting in August 2002, Bryce added lots of dialog boxes to allow you
|
||||
to set all the bochsrc parameters. At the time of release 2.0, there
|
||||
are still some bugs but it is pretty stable and usable.
|
||||
|
||||
Bochs should be build with wxWidgets 2.3.3 or later. It will probably
|
||||
not compile with 2.2.x without some work. wxWidgets 2.3.3 includes
|
||||
a patch by Bryce Denney to allow us to get raw keycode data for several
|
||||
Bochs should be build with wxWidgets 2.3.3 or later. The release wxWidgets 2.3.3
|
||||
includes a patch by Bryce Denney to allow us to get raw keycode data for several
|
||||
OSes.
|
||||
|
||||
On any UNIX platform with wxWidgets installed, configure with
|
||||
@ -44,50 +43,10 @@ To build in MS VC++:
|
||||
- build
|
||||
|
||||
Note that the project is set up for wxWidgets 2.3.3. To use on other
|
||||
wxwindows versions, you will have to change some of the names of the libraries
|
||||
to include. Use the samples that came with that version of wxwindows for
|
||||
wxWidgets versions, you will have to change some of the names of the libraries
|
||||
to include. Use the samples that came with that version of wxWidgets for
|
||||
reference.
|
||||
|
||||
To do:
|
||||
- now that ParamDialog works, I may rewrite some of the other dialogs
|
||||
as subclasses of ParamDialog. This would lead to more compact code,
|
||||
and fewer bugs.
|
||||
- configure time dialog
|
||||
- need to think about dialog layout
|
||||
- setting of IPS (controls how much time the PIT associates with each
|
||||
instruction for purposes of sending timer interrupts). How can we
|
||||
name this? instructions per simulated second.
|
||||
- enable realtime pit, realtime pit settings (?)
|
||||
- enable/disable X windows idle hack
|
||||
- report instructions per wall clock second in real time
|
||||
- decide which settings can be adjusted at runtime, and figure out how
|
||||
to disable the others. Do we need a set_enable() on the parameters
|
||||
themselves?
|
||||
- the power button has always "turned off" the power. Make it also
|
||||
turn ON the power. I think a few little green LEDs are in order.
|
||||
- floppy config screen: on win32, both not present and ejected are selected
|
||||
at first.
|
||||
- log events
|
||||
- Later: allow viewing of current log messages. Maybe this is a dialog that
|
||||
we append to, or maybe it should periodically display the last 1K of the
|
||||
log file (might be faster in high volume situations).
|
||||
- Later: should we allow multiple log files with different settings? for
|
||||
example dump cpu events to cpulog.txt and keyboard events to
|
||||
keyboardlog.txt?
|
||||
- debugger
|
||||
- bug: it's possible to make the GUI stop responding to mouse and keyboard
|
||||
input if you click the continue button in the debugger twice in very
|
||||
close succession. I don't know why yet.
|
||||
- probably the layout will be similar to BFE at first
|
||||
- need to show disassembly of the next instruction to be executed
|
||||
- clean up the biggest memory leaks and init/cleanup code. The gui allows you
|
||||
to kill the simulator and restart, but it doesn't do well after the first
|
||||
time. Valgrind should help with memory leak debugging, though until
|
||||
recently it couldn't run multithreaded programes.
|
||||
- disk change dialogs for floppy and cdrom need work.
|
||||
http://sourceforge.net/tracker/index.php?func=detail&aid=545414&group_id=12580&atid=112580
|
||||
-------------
|
||||
|
||||
------------------------------------------------------
|
||||
|
||||
Random notes follow
|
||||
@ -137,7 +96,7 @@ structure. How should it work?
|
||||
|
||||
vga gui detects a click on floppyA bitmap
|
||||
construct a BxEvent type BX_EVT_ASK_PARAM
|
||||
post the event to the wxwindows gui thread (somehow) and block for response
|
||||
post the event to the wxWidgets gui thread (somehow) and block for response
|
||||
when it arrives in the gui thread, show a modal dialog box
|
||||
get the answer back to the simulator thread
|
||||
|
||||
@ -152,186 +111,13 @@ notify_get_int_arg stuff.
|
||||
Starting and Killing Threads
|
||||
|
||||
When a detachable (default) thread finishes (returns from its Entry()
|
||||
function), wxwindows frees the memory associated with that thread.
|
||||
function), wxWidgets frees the memory associated with that thread.
|
||||
Unless the thread is never going to end, it is potentially dangerous to have a
|
||||
pointer to it at all. Even if you try to "check if it's alive" first, you may
|
||||
be dereferencing the pointer after it has already been deleted, leading to it
|
||||
claiming to be alive when it's not, or a segfault. To solve this, the approach
|
||||
used in the wxwindows threads example is to have code in the thread's OnExit()
|
||||
used in the wxWidgets threads example is to have code in the thread's OnExit()
|
||||
method remove the thread's pointer from the list of usable threads. In
|
||||
addition, any references or changes to the list of threads is controlled by a
|
||||
critical section to ensure that it stays correct. This post finally
|
||||
explained what I was seeing.
|
||||
|
||||
+-----------------------
|
||||
| From: Pieter van der Meulen (pgmvdm@yahoo.com)
|
||||
| Subject: Re: Thread Sample program - bug
|
||||
| Newsgroups: comp.soft-sys.wxwindows
|
||||
| Date: 2001-06-28 17:51:35 PST
|
||||
|
|
||||
|
|
||||
| At 06:24 PM 6/28/2001, you wrote:
|
||||
| >Hi,
|
||||
| >I have wxWindows 2.2.7 (wxMSW) installed.
|
||||
| >
|
||||
| >I just found in the thread.cpp sample code this section:
|
||||
| >
|
||||
| ><code>
|
||||
| >void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event) )
|
||||
| >{
|
||||
| > size_t count = wxGetApp().m_threads.Count();
|
||||
| > for ( size_t i = 0; i < count; i++ )
|
||||
| > {
|
||||
| >===> wxGetApp().m_threads[0]->Delete(); <=====
|
||||
| > }
|
||||
| >
|
||||
| > Close(TRUE);
|
||||
| >}
|
||||
| ></code>
|
||||
| >The indecated line should probably rather have a
|
||||
| >m_threads[i] rather than m_threads[0] .
|
||||
|
|
||||
| No, it should not, although it is not immediately obvious. When Delete() is
|
||||
| called, the thread will eventually delete itself, but not before it calls
|
||||
| MyThread::Exit(), which will remove itself from m_threads[] using
|
||||
| wxArray::Remove(this). wxArray::Remove (RemoveAt) will compact the array to
|
||||
| remove the element, it is now size-1. After this wxThread::Delete() returns.
|
||||
|
|
||||
|
|
||||
| >I have have a further question to this:
|
||||
| >Does this mean that a detached thread created with new
|
||||
| >HAS to be deleted manually ? Or is this only in case it might still
|
||||
| >be running?
|
||||
|
|
||||
| Firstly, you must create every detached thread using new since it will
|
||||
| delete itself, literally calling delete this.
|
||||
| Calling wxThread::Delete() is a correct way to terminate a thread, but
|
||||
| manually deleting (using delete) a detached wxThread object is not.
|
||||
| wxThread::Delete() will ask the thread to exit, the thread should check for
|
||||
| this in wxThread::Entry() regularly using wxThread::TestDestroy() and exit
|
||||
| when asked to do so.
|
||||
|
|
||||
| >(In general I have a unsatisfied felling about when delete is
|
||||
| >neccessary and when not -- "I only know, it's not , if the class is
|
||||
| >derived from wxWindows")
|
||||
|
|
||||
| For wxThreads: joinable threads must be deleted (when allocated on the
|
||||
| heap), detached threads may never be deleted. For other classes, consult
|
||||
| the documentation ;)
|
||||
|
|
||||
|
|
||||
| >Thanks for some feedback,
|
||||
| >Sebastian
|
||||
|
|
||||
| Regards,
|
||||
|
|
||||
| Pieter.
|
||||
+-----------------------
|
||||
|
||||
tracking some kind of deadlock bug in Linux.
|
||||
|
||||
seems to be in ReadMailcap, src/unix/mimetypes.cpp in wxwindows sources
|
||||
src/unix/mimetype.cpp:2312
|
||||
|
||||
SOLUTION: compile with -pthread on every compile and link line.
|
||||
|
||||
|
||||
|
||||
----------------------------------------------
|
||||
Suggested solution for putting sizers inside a scrolled window
|
||||
|
||||
From: Thaddaeus Frogley (codemonkey_uk@users.sourceforge.net)
|
||||
Subject: RE: Using sizers inside of a scrolled window
|
||||
Newsgroups: comp.soft-sys.wxwindows
|
||||
Date: 2001-10-02 02:41:04 PST
|
||||
|
||||
I have solved that same problem (scrolled windows / sizers) like so:
|
||||
|
||||
In the constructor for your wxFrame derived class,
|
||||
|
||||
//create a scrolling window
|
||||
myScrolledWindow = new wxScrolledWindow(this, -1);
|
||||
|
||||
//in the scolling window, create a panel
|
||||
myMainPanel = new wxPanel(myScrolledWindow, -1);
|
||||
|
||||
//place controls in the panel, laying them out with sizers
|
||||
|
||||
//...
|
||||
|
||||
myMainPanel->SetAutoLayout( TRUE );
|
||||
myMainPanel->SetSizer( sizer );
|
||||
sizer->Fit( myMainPanel );
|
||||
sizer->SetSizeHints( myMainPanel );
|
||||
|
||||
//set the scroll bars lengths based on the size of the inner panel
|
||||
wxSize size = myMainPanel->GetBestSize();
|
||||
myScrolledWindow->SetScrollbars( 1, 1, size.GetWidth(), size.GetHeight() );
|
||||
|
||||
//calculate the size of the window, and set it appropriately
|
||||
size.Set(size.GetWidth()+16,size.GetHeight()+16);
|
||||
|
||||
//Get the physical size of the display in pixels.
|
||||
int displaySizeX,displaySizeY;
|
||||
wxDisplaySize(&displaySizeX,&displaySizeY);
|
||||
|
||||
//clamp window size to % of screen
|
||||
if (size.GetWidth()>displaySizeX*0.75){
|
||||
size.SetWidth(displaySizeX*0.75);
|
||||
}
|
||||
if (size.GetHeight()>displaySizeY*0.75){
|
||||
size.SetHeight(displaySizeY*0.75);
|
||||
}
|
||||
|
||||
SetClientSize(size);
|
||||
|
||||
|
||||
|
||||
-----------------
|
||||
How to make wxChoice as wide as the longest string in the choice box?
|
||||
|
||||
From: Vadim Zeitlin (Vadim.zeitlin@dptmaths.ens-cachan.fr)
|
||||
Subject: Re: wxChoice
|
||||
Newsgroups: comp.soft-sys.wxwindows
|
||||
Date: 2001-09-18 04:41:07 PST
|
||||
|
||||
|
||||
On Sat, 15 Sep 2001 15:39:45 +0200 Merlijn Blaauw <merlijn@student-kmt.hku.nl> wrote:
|
||||
|
||||
MB> Also, I
|
||||
MB> would like the widget's parent window to change size (width) to fit the
|
||||
MB> widget's new content aswell.
|
||||
|
||||
You'll have to do it manually by calculating the length of the string you
|
||||
add to the control (use wxClientDC(combobox) and set correct font before
|
||||
calling GetTextExtent()!) and resizing the control to be slightly larger
|
||||
(yes, I know it's not nice at all but I don't see any other way to do it).
|
||||
|
||||
Regards,
|
||||
VZ
|
||||
|
||||
---------
|
||||
Hold on, this is even better!
|
||||
|
||||
From: Yann Rouillard (Y.Rouillard@exeter.ac.uk)
|
||||
Subject: wxChoice and wxADJUST_MINSIZE
|
||||
Newsgroups: comp.soft-sys.wxwindows
|
||||
Date: 2002-07-18 08:28:31 PST
|
||||
|
||||
I am trying to use a wxChoice widget in a little panel. The text length of
|
||||
the choices in the wxChoice can change so I used the wxADJUST_MINSIZE to
|
||||
have its width correctly set.
|
||||
|
||||
> the manual for wxSizer::Add() says:
|
||||
Finally, you can also specify wxADJUST_MINSIZE flag to make the minimal size of
|
||||
the control dynamically adjust to the value returned by its GetBestSize()
|
||||
method - this allows, for example, for correct relayouting of a static text
|
||||
control even if its text is changed during run-time.
|
||||
|
||||
relayouting? sounds like s/size/layout/g gone wrong.
|
||||
|
||||
Call Add() with wxADJUST_MINSIZE flag!
|
||||
--------------
|
||||
mno-cygwin guide on mingw webpage
|
||||
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/mno-cygwin-howto.txt
|
||||
www.mingw.org
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
The RFB server implementation is still lacking as of now, as a consequence
|
||||
you should force 8bit mode on the client to use it correctly, i.e. on Linux,
|
||||
use: "xvncviewer -8bit localhost" or similar.
|
||||
use: "xvncviewer -bgr233 localhost" or similar.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user