This commit was manufactured by cvs2svn to create tag 'wxPy_2_5_3_1'.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/tags/wxPy_2_5_3_1@30405 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2004-11-10 00:53:10 +00:00
parent d1f46a1c4d
commit ce096b777a
160 changed files with 11066 additions and 10325 deletions
--- a/wxPython/docs/BUILD.html
+++ b/wxPython/docs/BUILD.html
@@ -14,7 +14,7 @@
 development and testing, and is meant to help other people that want
 to do the same thing.  I'll assume that you are using either a CVS
 snapshot from <a class="reference" href="http://wxWidgets.org/snapshots/">http://wxWidgets.org/snapshots/</a>, a checkout from CVS, or
-one of the released wxPythonSrc-2.5.* tarballs.  I'll also assume that
+one of the released wxPython-src-2.5.* tarballs.  I'll also assume that
 you know your way around your system, the compiler, etc. and most
 importantly, that you know what you are doing!  ;-)</p>
 <p>If you want to also install the version of wxPython you build to be in
@@ -25,29 +25,29 @@ you only use the instructions in this <a class="reference" href="BUILD.html">BUI
 will end up with a separate installation of wxPython and you can
 switch back and forth between this and the release version that you
 may already have installed.</p>
-<p>If you want to make changes to any of the <tt class="literal"><span class="pre">*.i</span></tt> files, (SWIG interface
-definition files,) or to regenerate the extension sources or renamer
-modules, then you will need an up to date version of SWIG.  Either get
-and build the current CVS version, or version 1.3.20, and then apply
-the patches in wxPython/SWIG.  See the README.txt in that dir for
-details about each patch and also info about those that may already
-have been applied to the SWIG sources.  If you install this build of
-SWIG to a location that is not on the PATH (so it doesn't interfere
-with an existing SWIG install for example) then you can set a setup.py
-command-line variable named SWIG to be the full path name of the
-executable and the wxPython build will use it.  See below for an
-example.</p>
+<p>If you want to make changes to any of the <tt class="literal"><span class="pre">*.i</span></tt> files, (SWIG
+interface definition files,) or to regenerate the extension sources or
+renamer modules, then you will need an up to date version of SWIG,
+plus some patches.  Get the sources for version 1.3.22, and then apply
+the patches in wxPython/SWIG and then build SWIG like normal.  See the
+README.txt in the wxPython/SWIG dir for details about each patch and
+also info about those that may already have been applied to the SWIG
+sources.  If you install this build of SWIG to a location that is not
+on the PATH (so it doesn't interfere with an existing SWIG install for
+example) then you can set a setup.py command-line variable named SWIG
+to be the full path name of the executable and the wxPython build will
+use it.  See below for an example.</p>
 <p>In the text below I'll use WXDIR with environment variable syntax
-(either $WXDIR or %WXDIR%) to refer to the top level directory were
+(either $WXDIR or %WXDIR%) to refer to the top level directory where
 your wxWidgerts and wxPython sources are located.  It will equate to
 whereever you checked out the wxWidgets module from CVS, or untarred
-the wxPythonSrc tarball to.  You can either substitute the $WXDIR text
+the wxPython-src tarball to.  You can either substitute the $WXDIR text
 below with your actual dir, or set the value in the environment and
 use it just like you see it below.</p>
 <p>If you run into what appears to be compatibility issues between
 wxWidgets and wxPython while building wxPython, be sure you are using
-the wxWidgets sources included with the wxPythonSrc tarball or the CVS
-snapshot, and not a previously installed version or a version
+the wxWidgets sources included with the wxPython-src tarball or the
+CVS snapshot, and not a previously installed version or a version
 installed from one of the standard wxWidgets installers.  With the
 &quot;unstable&quot; releases (have a odd-numbered minor release value, where
 the APIs are allowed to change) there are often significant
@@ -81,23 +81,28 @@ cd bld
 </pre>
 <p>On OS X of course you'll want to use --with-mac instead of
 --with-gtk.</p>
-<p><strong>NOTE</strong>: Due to a recent change there is a dependency problem in the
-multilib builds of wxWidgets on OSX, so I have switched to a
-monolithic build on that platform.  (IOW, all of the core code in
-one shared library instead of several.)  I would also expect other
-unix builds to do just fine with a monolithic library, but I havn't
-tested it in a while so your mileage may vary.  Anyway, to switch
+<p><strong>NOTE</strong>: Due to a recent change there is currently a dependency
+problem in the multilib builds of wxWidgets on OSX, so I have
+switched to using a monolithic build.  That means that all of the
+core wxWidgets code is placed in in one shared library instead of
+several.  wxPython can be used with either mode, so use whatever
+suits you on Linux and etc. but use monolithic on OSX.  To switch
 to the monolithic build of wxWidgets just add this configure flag:</p>
 <pre class="literal-block">
 --enable-monolithic \
 </pre>
-<p>By default GTK2 will be selected if it is on your build system.  To
-force the use of GTK 1.2.x add this flag:</p>
+<p>By default GTK2 will be selected if its development pacakge is
+installed on your build system.  To force the use of GTK 1.2.x
+instead add this flag:</p>
 <pre class="literal-block">
 --disable-gtk2 \
 </pre>
-<p>To make the wxWidgets build be Unicode enabled (strongly
-recommended if you are building with GTK2) then add:</p>
+<p>To make the wxWidgets build be unicode enabled (strongly
+recommended if you are building with GTK2) then add the following.
+When wxPython is unicode enabled then all strings that are passed
+to wx functions and methods will first be converted to unicode
+objects, and any 'strings' returned from wx functions and methods
+will actually be unicode objects.:</p>
 <pre class="literal-block">
 --enable-unicode \
 </pre>
@@ -131,8 +136,7 @@ dir I don't lose my scripts too.)  This is what it looks like:</p>
 make $* \
    &amp;&amp; make -C contrib/src/gizmos $* \
    &amp;&amp; make -C contrib/src/ogl CXXFLAGS=&quot;-DwxUSE_DEPRECATED=0&quot; $* \
-    &amp;&amp; make -C contrib/src/stc $* \
-    &amp;&amp; make -C contrib/src/xrc $* 
+    &amp;&amp; make -C contrib/src/stc $* 
 </pre>
 <p>So you just use .make as if it where make, but don't forget to set
 the execute bit on .make first!:</p>
@@ -178,7 +182,7 @@ WX_CONFIG=/opt/wx/2.5/bin/wx-config
 GTK2.  If you built wxWidgets to use GTK 1.2.x then you should add
 this flag to the command-line:</p>
 <pre class="literal-block">
-WXPORT=gtk2 
+WXPORT=gtk 
 </pre>
 <p>If you would like to do a Unicode enabled build (all strings sent
 to or retruned from wx functions are Unicode objects) and your
@@ -235,7 +239,7 @@ compilers) can also be used but I've never done the work to make that
 happen.  If you want to try that then first you'll want to find out if
 there are any tricks that have to be done to make Python extension
 modules using that compiler, and then make a few changes to setup.py
-to accomodate that.  (And send the patches to me.)  If you plan on
+to accommodate that.  (And send the patches to me.)  If you plan on
 using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also
 have to build Python and any other extension modules that you use with
 that compiler because a different version of the C runtime library is
@@ -251,6 +255,12 @@ or python23_d.dll.  If you don't need to trace through the C/C++ parts
 of the code with the debugger then building the normal (or hybrid)
 version is fine, and you can use the regular python executables with
 it.</p>
+<p>Starting with 2.5.3.0 wxPython can be built for either the monlithic
+or the multi-lib wxWidgets builds.  (Monolithic means that all the
+core wxWidgets code is in one DLL, and multi-lib means that the core
+code is divided into multiple DLLs.)  To select which one to use
+specify the MONOLITHIC flag for both the wxWidgets build and the
+wxPython build as shown below, setting it to either 0 or 1.</p>
 <p>Just like the unix versions I also use some scripts to help me build
 wxWidgets, but I use some non-standard stuff to do it.  So if you have
 bash (cygwin or probably MSYS too) or 4NT plus unix-like cat and sed
@@ -343,7 +353,7 @@ clean up the build:</p>
 executing nmake with a bunch of extra command line parameters.
 The base set are:</p>
 <pre class="literal-block">
-f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1
+-f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1
 </pre>
 <p>If doing a debug build then add:</p>
 <pre class="literal-block">
@@ -363,7 +373,6 @@ same command from the following directories in order to build the
 contrib libraries:</p>
 <pre class="literal-block">
    %WXDIR%\contrib\build\gizmos
-    %WXDIR%\contrib\build\xrc
    %WXDIR%\contrib\build\stc
    %WXDIR%\contrib\build\ogl

@@ -385,10 +394,11 @@ version the rest of the time.  If you ever do want to install the
 development version please refer to INSTALL.txt.</p>
 <p>Change to the %WXDIR%\wxPython dir and run the this command,
 making sure that you use the version of python that you want to
-build for (if you have more than one on your system):</p>
+build for (if you have more than one on your system) and to match
+the MONOLITHIC flag with how you built wxWidgets:</p>
 <pre class="literal-block">
 cd %WXDIR%\wxPython
-python setup.py build_ext --inplace 
+python setup.py build_ext --inplace MONOLITHIC=1
 </pre>
 <p>If you are wanting to have the source files regenerated with swig,
 then you need to turn on the USE_SWIG flag and optionally tell it
--- a/wxPython/docs/BUILD.txt
+++ b/wxPython/docs/BUILD.txt
@@ -5,7 +5,7 @@ This file describes how I build wxWidgets and wxPython while doing
 development and testing, and is meant to help other people that want
 to do the same thing.  I'll assume that you are using either a CVS
 snapshot from http://wxWidgets.org/snapshots/, a checkout from CVS, or
-one of the released wxPythonSrc-2.5.* tarballs.  I'll also assume that
+one of the released wxPython-src-2.5.* tarballs.  I'll also assume that
 you know your way around your system, the compiler, etc. and most
 importantly, that you know what you are doing!  ;-)

@@ -21,31 +21,31 @@ may already have installed.
 .. _INSTALL: INSTALL.html
 .. _BUILD: BUILD.html

-If you want to make changes to any of the ``*.i`` files, (SWIG interface
-definition files,) or to regenerate the extension sources or renamer
-modules, then you will need an up to date version of SWIG.  Either get
-and build the current CVS version, or version 1.3.20, and then apply
-the patches in wxPython/SWIG.  See the README.txt in that dir for
-details about each patch and also info about those that may already
-have been applied to the SWIG sources.  If you install this build of
-SWIG to a location that is not on the PATH (so it doesn't interfere
-with an existing SWIG install for example) then you can set a setup.py
-command-line variable named SWIG to be the full path name of the
-executable and the wxPython build will use it.  See below for an
-example.
+If you want to make changes to any of the ``*.i`` files, (SWIG
+interface definition files,) or to regenerate the extension sources or
+renamer modules, then you will need an up to date version of SWIG,
+plus some patches.  Get the sources for version 1.3.22, and then apply
+the patches in wxPython/SWIG and then build SWIG like normal.  See the
+README.txt in the wxPython/SWIG dir for details about each patch and
+also info about those that may already have been applied to the SWIG
+sources.  If you install this build of SWIG to a location that is not
+on the PATH (so it doesn't interfere with an existing SWIG install for
+example) then you can set a setup.py command-line variable named SWIG
+to be the full path name of the executable and the wxPython build will
+use it.  See below for an example.

 In the text below I'll use WXDIR with environment variable syntax
-(either $WXDIR or %WXDIR%) to refer to the top level directory were
+(either $WXDIR or %WXDIR%) to refer to the top level directory where
 your wxWidgerts and wxPython sources are located.  It will equate to
 whereever you checked out the wxWidgets module from CVS, or untarred
-the wxPythonSrc tarball to.  You can either substitute the $WXDIR text
+the wxPython-src tarball to.  You can either substitute the $WXDIR text
 below with your actual dir, or set the value in the environment and
 use it just like you see it below.

 If you run into what appears to be compatibility issues between
 wxWidgets and wxPython while building wxPython, be sure you are using
-the wxWidgets sources included with the wxPythonSrc tarball or the CVS
-snapshot, and not a previously installed version or a version
+the wxWidgets sources included with the wxPython-src tarball or the
+CVS snapshot, and not a previously installed version or a version
 installed from one of the standard wxWidgets installers.  With the
 "unstable" releases (have a odd-numbered minor release value, where
 the APIs are allowed to change) there are often significant
@@ -86,23 +86,28 @@ place, then do the same for wxPython.
   On OS X of course you'll want to use --with-mac instead of
   --with-gtk.  

-   **NOTE**: Due to a recent change there is a dependency problem in the
-   multilib builds of wxWidgets on OSX, so I have switched to a
-   monolithic build on that platform.  (IOW, all of the core code in
-   one shared library instead of several.)  I would also expect other
-   unix builds to do just fine with a monolithic library, but I havn't
-   tested it in a while so your mileage may vary.  Anyway, to switch
+   **NOTE**: Due to a recent change there is currently a dependency
+   problem in the multilib builds of wxWidgets on OSX, so I have
+   switched to using a monolithic build.  That means that all of the
+   core wxWidgets code is placed in in one shared library instead of
+   several.  wxPython can be used with either mode, so use whatever
+   suits you on Linux and etc. but use monolithic on OSX.  To switch
   to the monolithic build of wxWidgets just add this configure flag::

 		     --enable-monolithic \

-   By default GTK2 will be selected if it is on your build system.  To
-   force the use of GTK 1.2.x add this flag::
+   By default GTK2 will be selected if its development pacakge is
+   installed on your build system.  To force the use of GTK 1.2.x
+   instead add this flag::

 		      --disable-gtk2 \

-   To make the wxWidgets build be Unicode enabled (strongly
-   recommended if you are building with GTK2) then add::
+   To make the wxWidgets build be unicode enabled (strongly
+   recommended if you are building with GTK2) then add the following.
+   When wxPython is unicode enabled then all strings that are passed
+   to wx functions and methods will first be converted to unicode
+   objects, and any 'strings' returned from wx functions and methods
+   will actually be unicode objects.::
                         
                      --enable-unicode \

@@ -137,8 +142,7 @@ place, then do the same for wxPython.
        make $* \
            && make -C contrib/src/gizmos $* \
            && make -C contrib/src/ogl CXXFLAGS="-DwxUSE_DEPRECATED=0" $* \
-            && make -C contrib/src/stc $* \
-            && make -C contrib/src/xrc $* 
+            && make -C contrib/src/stc $* 
   
   So you just use .make as if it where make, but don't forget to set
   the execute bit on .make first!::
@@ -250,7 +254,7 @@ compilers) can also be used but I've never done the work to make that
 happen.  If you want to try that then first you'll want to find out if
 there are any tricks that have to be done to make Python extension
 modules using that compiler, and then make a few changes to setup.py
-to accomodate that.  (And send the patches to me.)  If you plan on
+to accommodate that.  (And send the patches to me.)  If you plan on
 using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also
 have to build Python and any other extension modules that you use with
 that compiler because a different version of the C runtime library is
@@ -268,6 +272,13 @@ of the code with the debugger then building the normal (or hybrid)
 version is fine, and you can use the regular python executables with
 it.

+Starting with 2.5.3.0 wxPython can be built for either the monlithic
+or the multi-lib wxWidgets builds.  (Monolithic means that all the
+core wxWidgets code is in one DLL, and multi-lib means that the core
+code is divided into multiple DLLs.)  To select which one to use
+specify the MONOLITHIC flag for both the wxWidgets build and the
+wxPython build as shown below, setting it to either 0 or 1.
+
 Just like the unix versions I also use some scripts to help me build
 wxWidgets, but I use some non-standard stuff to do it.  So if you have
 bash (cygwin or probably MSYS too) or 4NT plus unix-like cat and sed
@@ -361,7 +372,7 @@ accordingly if you are using the bash shell.
   executing nmake with a bunch of extra command line parameters.
   The base set are::

-	-f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1
+	-f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1

   If doing a debug build then add::

@@ -381,7 +392,6 @@ accordingly if you are using the bash shell.
   contrib libraries::

 	%WXDIR%\contrib\build\gizmos
-	%WXDIR%\contrib\build\xrc
 	%WXDIR%\contrib\build\stc
 	%WXDIR%\contrib\build\ogl

@@ -404,10 +414,11 @@ accordingly if you are using the bash shell.

   Change to the %WXDIR%\\wxPython dir and run the this command,
   making sure that you use the version of python that you want to
-   build for (if you have more than one on your system)::
+   build for (if you have more than one on your system) and to match
+   the MONOLITHIC flag with how you built wxWidgets::

         cd %WXDIR%\wxPython
-         python setup.py build_ext --inplace 
+         python setup.py build_ext --inplace MONOLITHIC=1

   If you are wanting to have the source files regenerated with swig,
   then you need to turn on the USE_SWIG flag and optionally tell it
--- a/wxPython/docs/CHANGES.html
+++ b/wxPython/docs/CHANGES.html
@@ -11,7 +11,161 @@
 <div class="document" id="recent-changes-for-wxpython">
 <h1 class="title">Recent Changes for wxPython</h1>
 <div class="section" id="id1">
-<h1><a name="id1">2.5.2.8</a></h1>
+<h1><a name="id1">2.5.3.1</a></h1>
+<p>wxMac focus and border refreshes corrected.</p>
+<p>Updated internal PNG library.</p>
+<p>wxMac fix for metal appearance on wx.ToolBar.</p>
+<p>wx.grid.Grid fix allowing DoGetBestSize to be called before CreateGrid
+(which means that a min size doesn't need to be specified.)</p>
+<p>wxMac fix for not sending a native click to a control if it is not
+enabled (does an enable itself)</p>
+<p>Added wx.lib.ogl.DrawnShape, and fixed various little bugs in the new
+OGL.</p>
+<p>Added support to XRC and XRCed for the 3-state checkbox flags and also
+for wx.ToggleButton.  Updated the generic window styles supported by
+XRCed.</p>
+<p>It is now possible to create &quot;stock&quot; buttons.  Basically this means
+that you only have to provide one of the stock IDs (and either an
+empty label or a label that matches the stock label) when creating the
+button and wxWidgets will choose the stock label to go with it
+automatically.  Additionally on the platforms that have a native
+concept of a stock button (currently only GTK2) then the native stock
+button will be used.  For example, the following will result in a
+button with &quot;Cancel&quot; as the label and an accelerator on the &quot;C&quot;, and
+if run on wxGTK2 then there will also be an image of a red X:</p>
+<pre class="literal-block">
+b = wx.Button(parent, wx.ID_CANCEL) 
+</pre>
+<p>Added wx.lib.ticker.Ticker class from Chris Mellon.</p>
+<p>Fix some incorrect clipping regions in wxSTC on wxGTK.</p>
+<p>Added wrapper for wx.grid.Grid.GetOrCreateCellAttr.</p>
+<p>Removed my copy of distutils from the wxPython source tree.  Now that
+I am no longer doing builds on Python 2.1 the newest distutils is no
+longer needed.  (There is still one small bug in Python 2.2 distutils
+on win32, but it is easily worked around.) This sovles the problem of
+incorrect builds on some systems where the system installed distutils
+has been patched to behave slightly differently, for example SuSE on
+x86_64 or Chandler's build.</p>
+<p>Updated to SWIG 1.3.22 (plus my patch.)  See wxPython/SWIG/README.txt
+in the source tree if you need to use SWIG when building your own copy
+of wxPython, or other extension modules that need to integrate with
+the wxPython modules.</p>
+<p>Added wx.Frame.RequestUserAttention which, if the platform suports it,
+will do something (such as flash the task bar item) to suggest to the
+user that they should look at that window.</p>
+<p>&quot;Fixed&quot; wx.grid.Grid.SetDefaultEditor and SetDefaultRenderer by making
+them register the editor or renderer for the &quot;string&quot; data type.</p>
+<p>Added depth param to wx.Image.ConvertToBitmap.</p>
+<p>Extended the wx.calendar.CalendarCtrl class with methods that get/set
+a Python datetime or date object.  (These will only work with Python
+2.3+) The methods are PySetDate, PyGetDate, PySetLowerDateLimit,
+PySetUpperDateLimit, PySetDateRange, PyGetLowerDateLimit, and
+PyGetUpperDateLimit.  Also, CalendarEvent was extended with PySetDate
+and PyGetDate methods.</p>
+<p>wxMSW: SetBackgroundColour on a wx.Choice or a wx.ComboBox will now
+also set the colour of the dropdown.</p>
+<p>wxMac: MessageDialog now supports wx.NO_DEFAULT style</p>
+<p>wxMSW: added AssociateHandle and DissociateHandle to wx.Window</p>
+<p>wxMac: fix for toolbar tooltips</p>
+<p>wx.Sizer.Show (and Hide) now take an optional parameter specifying if
+the item to be shown should be searched for recursivly in subsizers,
+and return a boolean value indicating if the item was found.</p>
+<p>wxMSW: fixed MaximizeEvent generation in wx.Frame</p>
+<p>wxMSW: fixed sending duplicate EVT_COMBOBOX events</p>
+<p>Smoother time estimation updates in wx.ProgressDialog (patch 992813)</p>
+<p>Made wx.Listbook events more consistent with wx.Notebook ones (patch
+1001271)</p>
+<p>Fixed rounding errors in variable status bar panes widths computation
+(patch 1030021)</p>
+<p>Added possibility to specify printer bin (patch 910272)</p>
+<p>wxMSW: fixed wx.ListCtrl's SetWindowStyleFlag() to not remove
+WS_VISIBLE; also refresh the control automatically (closes bug
+1019440)</p>
+<p>Added wx.Choicebook, yet another notebook-like control.</p>
+<p>wxMSW: Make radiobutton tab behaviour the same on MSW as in standard
+MSW app, i.e. tab into the activated, not necessarily the first radio
+button.</p>
+<p>Added limited support for wxEventLoop (you can't derive from a
+wx.PyEventLoop version yet...)  Updated and moved the sample showing
+how to replace the MainLoop to samples/mainloop/mainloop.py.</p>
+<p>The C++ xrc lib has been moved out of contrib and into the core, so it
+is always built by default.  wxPython's build has also changed
+accordingly and will build the xrc module as part of the core set of
+modules built by default.  If you were axplicitly using BUILD_XRC then
+it will no longer be recognized as a build option, otherwise you
+should notice no difference.</p>
+<p>wxMac: Fixed radio toolbar buttons to correctly untoggle the others
+when a new one is selected.</p>
+<p>wxMac: Fixed GetLineLength and GetLineText for MLTE text controls</p>
+<p>wxMac: wx.TaskBarIcon is implemented by allowing you to change the
+app's icon on the Dock and also specifying a menu that should be
+merged with the normal dock popup menu.  See the MigrationGuide for
+more details and a warning.</p>
+<p>Added wx.TopLevelWindow.IsActive() which tells you if the frame or
+dialog is or containts the active window with the keyboard focus.</p>
+<p>Added ability to create a font based on pixel size rather than point
+size via the FontFromPixelSize constructor.</p>
+<p>Updated the Scintilla used by StyledTextCtrl to version 1.61</p>
+<p>Improved image HitTest for TreeListCtrl.</p>
+<p>Added wx.App.IsMainLoopRunning.</p>
+<p>wxGTK: Make wxComboBox spit out a bit fewer surplus events when
+holding down the mouse button.</p>
+<p>wxGTK: Enable key based navigation through notebook tabs as in the
+native control with Left and right keys. Support for vetoing.</p>
+<p>FloatCanvas updates from Chris Barker</p>
+<dl>
+<dt>PyPlot updates from Gordon Williams:</dt>
+<dd><ul class="first last simple">
+<li>Added bar graph demo</li>
+<li>Modified line end shape from round to square.</li>
+<li>Removed FloatDCWrapper for conversion to ints and ints in
+arguments</li>
+<li>Imported modules given leading underscore to name.</li>
+<li>Added Cursor Line Tracking and User Point Labels.</li>
+<li>Demo for Cursor Line Tracking and Point Labels.</li>
+<li>Size of plot preview frame adjusted to show page better.</li>
+<li>Added helper functions PositionUserToScreen and
+PositionScreenToUser in PlotCanvas.</li>
+<li>Added functions GetClosestPoints (all curves) and GetClosestPoint
+(only closest curve) can be in either user coords or screen
+coords.</li>
+</ul>
+</dd>
+<dt>MaskedEdit updates from Will Sadkin:</dt>
+<dd><ul class="first last simple">
+<li>Added '*' mask char that means &quot;all ansii chars&quot; (ords 32-255)</li>
+<li>Added proper unicode support to masked controls and wx.tools.dbg</li>
+<li>Fixed two reported missing import bugs introduced by package
+creation</li>
+<li>Converted masked package doc strings to reST format for better
+epydoc support</li>
+<li>lots of doc string improvements and function hiding to better
+reflect package's public contents.</li>
+</ul>
+</dd>
+</dl>
+<p>Restructured the installer packages slightly to help facilitate having
+multiple versions of wxPython installed at the same time.  See the
+Migrarion Guide for more information.</p>
+<dl>
+<dt>Applied patch from Pim Van Heuven that modifies 4 files:</dt>
+<dd><ul class="first last simple">
+<li>wxPython/demo/ListCtrl_edit.py (new demo)</li>
+<li>wxPython/demo/Main.py (include new demo in demo app)</li>
+<li>wxPython/wx/lib/mixins/listctrl.py (several improvements to 
+TextEditMixin)</li>
+<li>wxPython/wx/lib/wxpTag.py (some small fixes)</li>
+</ul>
+</dd>
+</dl>
+<p>Added (thanks to Kevin Ollivier!) wrappers for wx.WebKitCtrl for the
+OSX build.  Other platforms will raise an exception if you try to use
+it.</p>
+<p>wxPython on OSX can now be built in Unicode mode, can support multiple
+version installs, and comes with an uninstaller script.</p>
+</div>
+<div class="section" id="id2">
+<h1><a name="id2">2.5.2.8</a></h1>
 <p>Predominantly a bug-fix release.</p>
 <blockquote>
 <ul class="simple">
@@ -39,8 +193,8 @@ wxCheckListBox.</li>
 </ul>
 </blockquote>
 </div>
-<div class="section" id="id2">
-<h1><a name="id2">2.5.2.7</a></h1>
+<div class="section" id="id3">
+<h1><a name="id3">2.5.2.7</a></h1>
 <p>wx.ADJUST_MINSIZE is now the default behaviour for window items in
 sizers.  This means that the item's GetMinSize and/or GetBestSize will
 be called when calculating layout and the return value from that will
@@ -133,8 +287,8 @@ in the PyShell:</p>
 ...     wx.MilliSleep(10)
 </pre>
 </div>
-<div class="section" id="id3">
-<h1><a name="id3">2.5.1.5</a></h1>
+<div class="section" id="id4">
+<h1><a name="id4">2.5.1.5</a></h1>
 <p>(See also the <a class="reference" href="MigrationGuide.html">MigrationGuide</a> file for details about some of the
 big changes that have happened in this release and how you should
 adapt your code.)</p>
@@ -215,8 +369,8 @@ migrating away from using activexwrapper as well.  Please see the
 MigrationGuide for more details on using the new module.</p>
 <p>Floats are allowed again as function parameters where ints are expected.</p>
 </div>
-<div class="section" id="id5">
-<h1><a name="id5">2.4.2.4</a></h1>
+<div class="section" id="id6">
+<h1><a name="id6">2.4.2.4</a></h1>
 <p>Use wxSTC in the demo for displaying the soucre code of the samples.</p>
 <p>Lots of bug fixes and such from the wxWindows folks.</p>
 <p>Added wxPython.lib.newevent from Miki Tebeka.  Its usage is
@@ -225,8 +379,8 @@ demonstrated in the Threads sample in the demo.</p>
 <p>Added wxMaskedNumCtrl.</p>
 <p>Added Chris Barker's FloatCanvas.</p>
 </div>
-<div class="section" id="id6">
-<h1><a name="id6">2.4.1.2</a></h1>
+<div class="section" id="id7">
+<h1><a name="id7">2.4.1.2</a></h1>
 <p>Added wxScrolledPanel from Will Sadkin</p>
 <p>Added SetShape method to top level windows (e.g. wxFrame.)</p>
 <p>Changed wxSWIG to not generate Python code using apply, (since it will
@@ -277,8 +431,8 @@ release,) SetItemMinSize can now take a wxSize (or 2-tuple) parameter,
 and Spacers can be specified with a wxSize (or 2-tuple) parameter</p>
 <p>Added wxCursorFromBits.</p>
 </div>
-<div class="section" id="id7">
-<h1><a name="id7">2.4.0.7</a></h1>
+<div class="section" id="id8">
+<h1><a name="id8">2.4.0.7</a></h1>
 <p>Gave up on generating a warning upon the use of the old true/false or
 TRUE/FALSE values.</p>
 <p>Fixed wxGenericTreeCtrl (used on wxGTK and wxMac for wxTreeCtrl) so
@@ -308,8 +462,8 @@ think I am testing in the future...</p>
 <p>Updated pycolourchooser.</p>
 <p>Updated to 0.9b of PyCrust.</p>
 </div>
-<div class="section" id="id8">
-<h1><a name="id8">2.4.0.4</a></h1>
+<div class="section" id="id9">
+<h1><a name="id9">2.4.0.4</a></h1>
 <p>Added missing wxRect methods</p>
 <p>Add OOR support for wxApp objects too.</p>
 <p>Added wxCursorFromImage, which works on wxMSW and wxGTK so far.</p>
@@ -365,25 +519,25 @@ doesn't have a standard place for them.</p>
 <p>Fixed typemaps for wxGridCellCoordsArray.</p>
 <p>Updated to the 0.9a version of PyCrust</p>
 </div>
-<div class="section" id="id9">
-<h1><a name="id9">2.4.0.2</a></h1>
+<div class="section" id="id10">
+<h1><a name="id10">2.4.0.2</a></h1>
 <p>Several bug fixes.</p>
 <p>Added wxIntCtrl from Will Sadkin.</p>
 <p>Added wxPyColourChooser by Michael Gilfix.</p>
 </div>
-<div class="section" id="id10">
-<h1><a name="id10">2.4.0.1</a></h1>
+<div class="section" id="id11">
+<h1><a name="id11">2.4.0.1</a></h1>
 <p>No major new features since 2.3.4.2, mostly bug fixes and minor
 enhancements.</p>
 <p>Added function wrappers for the common dialogs from Kevin Altis.  See
 wxPython/lib/dialogs.py for more details.</p>
 </div>
-<div class="section" id="id11">
-<h1><a name="id11">2.3.4.2</a></h1>
+<div class="section" id="id12">
+<h1><a name="id12">2.3.4.2</a></h1>
 <p>Various bug fixes.</p>
 </div>
-<div class="section" id="id12">
-<h1><a name="id12">2.3.4.1</a></h1>
+<div class="section" id="id13">
+<h1><a name="id13">2.3.4.1</a></h1>
 <p>Updated XRCed and wxTimeCtrl contribs.</p>
 <p>Show a couple new wxGrid features in the demo.</p>
 <p>Several bug fixes in wxWindows.</p>
@@ -437,8 +591,8 @@ windows when desired.</p>
 HTMLHelp viewer does.  Changed how the wxPythonDocs tarball is built
 and added a script to launch the doc viewer.</p>
 </div>
-<div class="section" id="id13">
-<h1><a name="id13">2.3.3.1</a></h1>
+<div class="section" id="id14">
+<h1><a name="id14">2.3.3.1</a></h1>
 <p>Added wxSplashScreen.</p>
 <p>Added wxGenericDirCtrl.</p>
 <p>Added wxMultiChoiceDialog.</p>
@@ -580,15 +734,15 @@ example.</p>
 <p>Added wxPython.lib.mixins.rubberband module from Robb Shecter.</p>
 <p>Added wxTimeCtrl from Will Sadkin.</p>
 </div>
-<div class="section" id="id14">
-<h1><a name="id14">2.3.2.1</a></h1>
+<div class="section" id="id15">
+<h1><a name="id15">2.3.2.1</a></h1>
 <p>Changed (again) how the Python global interpreter lock is handled as
 well as the Python thread state.  This time it works on SMP machines
 without barfing and is also still compatible with Python debuggers.</p>
 <p>Added some patches from library contributors.</p>
 </div>
-<div class="section" id="id15">
-<h1><a name="id15">2.3.2</a></h1>
+<div class="section" id="id16">
+<h1><a name="id16">2.3.2</a></h1>
 <p>Added EVT_HELP, EVT_HELP_RANGE, EVT_DETAILED_HELP,
 EVT_DETAILED_HELP_RANGE, EVT_CONTEXT_MENU, wxHelpEvent,
 wxContextMenuEvent, wxContextHelp, wxContextHelpButton, wxTipWindow,
@@ -670,8 +824,8 @@ SendCommand method, but it is still quite powerful.  See
 wxPython/contrib/dllwidget and wxPython/demo/dllwidget for more
 details.</p>
 </div>
-<div class="section" id="id16">
-<h1><a name="id16">2.3.1</a></h1>
+<div class="section" id="id17">
+<h1><a name="id17">2.3.1</a></h1>
 <p>Added EVT_GRID_EDITOR_CREATED and wxGridEditorCreatedEvent so the user
 code can get access to the edit control when it is created, (to push
 on a custom event handler for example.)</p>
@@ -684,8 +838,8 @@ subclass wxXmlResourceHandler, etc...</p>
 <p>Fixed img2py to work correctly with Python 2.1.</p>
 <p>Added enhanced wxVTKRenderWindow by Prabhu Ramachandran</p>
 </div>
-<div class="section" id="id17">
-<h1><a name="id17">2.3.0</a></h1>
+<div class="section" id="id18">
+<h1><a name="id18">2.3.0</a></h1>
 <p>Removed initial startup dependency on the OpenGL DLLs so only the
 glcanvasc.pyd depends on them, (on wxMSW.)</p>
 <p>Changed wxFont, wxPen, wxBrush to not implicitly use the
@@ -781,13 +935,13 @@ please send it to me for inclusion in this package.</p>
 by having smaller functional apps to play with.  They can be found in
 wxPython/samples.</p>
 </div>
-<div class="section" id="id18">
-<h1><a name="id18">2.2.6</a></h1>
+<div class="section" id="id19">
+<h1><a name="id19">2.2.6</a></h1>
 <p>No changes happened in the Python wrappers for this release, only
 changes and fixes in the wxWindows library.</p>
 </div>
-<div class="section" id="id19">
-<h1><a name="id19">2.2.5</a></h1>
+<div class="section" id="id20">
+<h1><a name="id20">2.2.5</a></h1>
 <p>New typemaps for wxString when compiling for Python 2.0 and beyond
 that allow Unicode objects to be passed as well as String objects.  If
 a Unicode object is passed PyString_AsStringAndSize is used to convert
@@ -1030,7 +1184,7 @@ an EVT_SIZE handler that calls Layout().</p>
 <p>Fixed deadlock problem that happened when using threads.</p>
 <p>Added new HTML printing classes.</p>
 <p>Added wxWindow.GetHandle</p>
-<p>Apparently wxMouseEvent.Position has been depreciated in wxWindows as
+<p>Apparently wxMouseEvent.Position has been deprecated in wxWindows as
 it is no longer available by default.  You can use GetPositionTuple
 (returning a tuple with x,y) instead, or GetPosition (returning a
 wxPoint.)</p>
@@ -1088,7 +1242,7 @@ pages.  See the demo for an example.</p>
 wxGTK.  Added them back in since the methods exist now.</p>
 <p>Wrapped the wxHtmlHelpController and related classes.</p>
 <p>Wrapped the C++ versions of wxSizer and friends.  The Python-only
-versions are still in the library, but depreciated.  (You will get a
+versions are still in the library, but deprecated.  (You will get a
 warning message if you try to use them, but the warning can be
 disabled.) The usage of the C++ versions is slightly different, and
 the functionality of wxBorderSizer is now part of wxBoxSizer.  I have
@@ -1227,7 +1381,7 @@ matches MSW's.</p>
 <p>Added wxGrid.GetCells</p>
 <p>Added wxSystemSettings static methods as functions with names like
 wxSystemSettings_GetSystemColour.</p>
-<p>Removed wxPyMenu since using menu callbacks have been depreciated in
+<p>Removed wxPyMenu since using menu callbacks have been deprecated in
 wxWindows.  Use wxMenu and events instead.</p>
 <dl>
 <dt>Added alternate wxBitmap constructor (for MSW only) as</dt>
--- a/wxPython/docs/CHANGES.txt
+++ b/wxPython/docs/CHANGES.txt
@@ -1,7 +1,7 @@
 Recent Changes for wxPython
 =====================================================================

-2.5.3.0
+2.5.3.1
 -------

 wxMac focus and border refreshes corrected.
@@ -152,8 +152,17 @@ FloatCanvas updates from Chris Barker
 PyPlot updates from Gordon Williams:
   - Added bar graph demo
   - Modified line end shape from round to square.
-   - Removed FloatDCWrapper for conversion to ints and ints in arguments
-
+   - Removed FloatDCWrapper for conversion to ints and ints in
+     arguments
+   - Imported modules given leading underscore to name.
+   - Added Cursor Line Tracking and User Point Labels. 
+   - Demo for Cursor Line Tracking and Point Labels.
+   - Size of plot preview frame adjusted to show page better.
+   - Added helper functions PositionUserToScreen and
+     PositionScreenToUser in PlotCanvas.
+   - Added functions GetClosestPoints (all curves) and GetClosestPoint
+     (only closest curve) can be in either user coords or screen
+     coords.

 MaskedEdit updates from Will Sadkin:
    - Added '*' mask char that means "all ansii chars" (ords 32-255)
@@ -165,6 +174,24 @@ MaskedEdit updates from Will Sadkin:
    - lots of doc string improvements and function hiding to better
      reflect package's public contents.

+Restructured the installer packages slightly to help facilitate having
+multiple versions of wxPython installed at the same time.  See the
+Migrarion Guide for more information.
+
+Applied patch from Pim Van Heuven that modifies 4 files:
+    - wxPython/demo/ListCtrl_edit.py (new demo)
+    - wxPython/demo/Main.py (include new demo in demo app)
+    - wxPython/wx/lib/mixins/listctrl.py (several improvements to 
+      TextEditMixin)
+    - wxPython/wx/lib/wxpTag.py (some small fixes)
+
+Added (thanks to Kevin Ollivier!) wrappers for wx.WebKitCtrl for the
+OSX build.  Other platforms will raise an exception if you try to use
+it. 
+
+wxPython on OSX can now be built in Unicode mode, can support multiple
+version installs, and comes with an uninstaller script.
+



@@ -1558,7 +1585,7 @@ Added new HTML printing classes.

 Added wxWindow.GetHandle

-Apparently wxMouseEvent.Position has been depreciated in wxWindows as
+Apparently wxMouseEvent.Position has been deprecated in wxWindows as
 it is no longer available by default.  You can use GetPositionTuple
 (returning a tuple with x,y) instead, or GetPosition (returning a
 wxPoint.)
@@ -1640,7 +1667,7 @@ wxGTK.  Added them back in since the methods exist now.
 Wrapped the wxHtmlHelpController and related classes.

 Wrapped the C++ versions of wxSizer and friends.  The Python-only
-versions are still in the library, but depreciated.  (You will get a
+versions are still in the library, but deprecated.  (You will get a
 warning message if you try to use them, but the warning can be
 disabled.) The usage of the C++ versions is slightly different, and
 the functionality of wxBorderSizer is now part of wxBoxSizer.  I have
@@ -1800,7 +1827,7 @@ Added wxGrid.GetCells
 Added wxSystemSettings static methods as functions with names like
 wxSystemSettings_GetSystemColour.

-Removed wxPyMenu since using menu callbacks have been depreciated in
+Removed wxPyMenu since using menu callbacks have been deprecated in
 wxWindows.  Use wxMenu and events instead.

 Added alternate wxBitmap constructor (for MSW only) as
--- a/wxPython/docs/INSTALL.html
+++ b/wxPython/docs/INSTALL.html
@@ -65,9 +65,11 @@ all.</p>
 </li>
 <li><p class="first">In addition to building wxPython as described in BUILD.txt, you can
 install it to Python's site-packages dir, as well as some scripts
-into the same bin dir used by Python by using this command:</p>
+into the same bin dir used by Python by using this command, plus
+whatever WXPORT, UNICODE, etc. settings you used for the initial
+build step:</p>
 <pre class="literal-block">
-python2.3 setup.py install
+python2.3 setup.py install 
 </pre>
 <p>If you would like to install to some place besides the prefix where
 Python is installed, (such as to your home directory) then you can
@@ -105,9 +107,9 @@ machines be careful to install to /Library/Python/2.3.  To
 complicate things further, the Jaguar version, or a custom build
 you do yourself will end up in /Library/Frameworks even on
 Panther...</li>
-<li>You need to use pythonw at the command line or PythonLauncher app
-to run wxPython apps, otherwise the app will not be able to fully
-use the GUI display.</li>
+<li>You need to use pythonw at the command line or the PythonLauncher
+app to run wxPython apps, otherwise the app will not be able to
+fully use the GUI display.</li>
 </ol>
 </div>
 <div class="section" id="installing-on-windows">
--- a/wxPython/docs/INSTALL.txt
+++ b/wxPython/docs/INSTALL.txt
@@ -112,9 +112,9 @@ instructions above, except for a few small, but important details:
   you do yourself will end up in /Library/Frameworks even on
   Panther...

-3. You need to use pythonw at the command line or PythonLauncher app
-   to run wxPython apps, otherwise the app will not be able to fully
-   use the GUI display.
+3. You need to use pythonw at the command line or the PythonLauncher
+   app to run wxPython apps, otherwise the app will not be able to
+   fully use the GUI display.



--- a/wxPython/docs/MigrationGuide.html
+++ b/wxPython/docs/MigrationGuide.html
@@ -358,7 +358,7 @@ class MyDialog(wx.Dialog):
 <div class="section" id="sizers">
 <h1><a name="sizers">Sizers</a></h1>
 <p>The hack allowing the old &quot;option&quot; keyword parameter has been removed.
-If you use keyword args with w.xSizer Add, Insert, or Prepend methods
+If you use keyword args with wx.Sizer Add, Insert, or Prepend methods
 then you will need to use the <tt class="literal"><span class="pre">proportion</span></tt> name instead of
 <tt class="literal"><span class="pre">option</span></tt>.  (The <tt class="literal"><span class="pre">proportion</span></tt> keyword was also allowed in 2.4.2.4.)</p>
 <p>When adding a spacer to a sizer you now need to use a wx.Size or a
@@ -376,7 +376,7 @@ be used from XRC.</p>
 <p>You should not use AddWindow, AddSizer, AddSpacer (and similar for
 Insert, Prepend, and etc.) methods any longer.  Just use Add and the
 wrappers will figure out what to do.  <strong>[Changed in 2.5.2.x]</strong>
-AddWindow, AddSize, AddSpacer and etc. will now issue a
+AddWindow, AddSizer, AddSpacer and etc. will now issue a
 DeprecationWarning.</p>
 <p><strong>[Changed in 2.5.2.x]</strong> The Sizers have had some fundamental internal
 changes in the 2.5.2.x release intended to make them do more of the
@@ -393,7 +393,7 @@ flag then when layout was calculated the item's <tt class="literal"><span class=
 would be used to reset the minimal size that the sizer used.</li>
 </ul>
 </blockquote>
-<p>The main thrust of the new Sizer changes was to make behaviour like
+<p>The main thrust of the new Sizer changes was to make behavior like
 <tt class="literal"><span class="pre">wx.ADJUST_MINSIZE</span></tt> be the default, and also to push the tracking of
 the minimal size to the window itself (since it knows its own needs)
 instead of having the sizer take care of it.  Consequently these
@@ -401,7 +401,7 @@ changes were made:</p>
 <blockquote>
 <ul class="simple">
 <li>The <tt class="literal"><span class="pre">wx.FIXED_MINSIZE</span></tt> flag was added to allow for the old
-behaviour.  When this flag is used the size a window has when
+behavior.  When this flag is used the size a window has when
 added to the sizer will be treated as its minimal size and it
 will not be readjusted on each layout.</li>
 <li>The min size stored in <tt class="literal"><span class="pre">wx.Window</span></tt> and settable with
@@ -603,9 +603,7 @@ mask and the rest would be made fully opaque.</p>
 channel and will now only create a mask when all the pixels in the
 image are either fully transparent or fully opaque.  In addition, the
 wx.DC.DrawBitmap and wx.DC.Blit methods are able to correctly blend
-the pixels in the image with partially transparent alpha values.
-(Currently only on MSW and Mac, if anybody knows how to do it for GTK
-then please submit a patch!)</p>
+the pixels in the image with partially transparent alpha values.</p>
 <p>If you are using a PNG with an alpha channel but you need to have a
 wx.Mask like you automatically got in 2.4 then you can do one of the
 following:</p>
@@ -674,7 +672,7 @@ later into the main namespace via Python code.</p>
 the &quot;internal&quot; module names have changed, but you shouldn't have been
 using them anyway so it shouldn't bother you. ;-) In case you were
 erroneously using them in 2.4, here are the internal extension modules
-no longer exist:</p>
+that no longer exist:</p>
 <blockquote>
 <ul class="simple">
 <li>clip_dnd</li>
@@ -715,8 +713,93 @@ the objects in these modules only via the wx or wxPython.wx packages:</p>
 <p>The help module no longer exists and the classes therein are now part
 of the core module imported with wxPython.wx or the wx package.</p>
 </div>
-<div class="section" id="other-stuff">
-<h1><a name="other-stuff">Other Stuff</a></h1>
+<div class="section" id="wx-taskbaricon">
+<h1><a name="wx-taskbaricon">wx.TaskBarIcon</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>wx.TaskbarIcon now works on all three platforms, although for wxGTK it
+depends on support from the Window Manager.  On OS X the icon replaces
+the application's icon on the dock and when you right click on it the
+app's default popup menu is merged with the wx.TaskBarIcon's menu.
+Because of how it is implemented on the Mac using the Dock most of the
+TaskBarIcon events will _not_ be emitted on that platform, but since
+98% of the time you simply want to display an icon and have a popup
+menu it shouldn't be much of a problem.  You can still use the other
+events on the other platforms, you'll just want to be sure that you
+can do everything you want via the menu too.</p>
+<p>Since popping up a menu is the most common thing to do with a
+TaskBarIcon the class has some new built in functionality to
+facilitate that.  To use the TaskBarIcon in this new way, simply
+derive a new class from TaskBarIcon and implement a CreatePopupMenu
+method that creates and returns the menu.  That's all there is to it,
+besides binding event handlers for the menu items of course.  Take a
+look at the DemoTaskBarIcon class in the demo/Main.py module for an
+example.</p>
+<p><strong>NOTE</strong>:  Unfortunately due to being able to support virtualizing
+CreatePopupMenu the C++ TaskBarIcon instance now holds a reference to
+the Python instance, and so you will need to explicitly Destroy() your
+TaskBarIcon instance when you are done with it.  (Like you do with
+wx.Dialogs.)  If you don't destroy it then wxWidgets will assume that
+you want the app to keep running with just the icon in the task bar
+and the MainLoop will not exit.</p>
+</div>
+<div class="section" id="version-number-change">
+<h1><a name="version-number-change">Version Number Change</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>Starting with 2.5.3.0 the Unicode versions of wxPython will no longer
+have a 'u' appended to the fourth component of the version number.
+Please check for the presence of &quot;unicode&quot; in the <cite>wx.PlatformInfo</cite>
+tuple instead.  (This tuple of strings has been available since the
+first 2.5 version.) For example:</p>
+<pre class="literal-block">
+if &quot;unicode&quot; in wx.PlatformInfo:
+    # do whatever
+    ...
+</pre>
+</div>
+<div class="section" id="multi-version-installs">
+<h1><a name="multi-version-installs">Multi-Version Installs</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>Starting with 2.5.3.0 the wx and wxPython package directories will be
+installed in a subdirectory of the site-packages directory, instead of
+directly in site-packages.  This is done to help facilitate having
+multiple versions of wxPython installed side-by-side.  Why would you
+want to do this?  One possible scenario is you have an app that
+requires wxPython 2.4 but you want to use the newest 2.5 to do your
+own development with.  Or perhaps you want to be able to test your app
+with several different versions of wxPython to ensure compatibility.
+Before everyone panics, rest asured that if you only install one
+version of wxPython then you should notice no difference in how things
+work.</p>
+<p>In addition to installing wxPython into a &quot;versioned&quot; subdirectory of
+site-packages, a file named <cite>wx.pth</cite> is optionally installed that will
+contain the name of the versioned subdirectory.  This will cause that
+subdirectory to be automatically added to the sys.path and so doing an
+&quot;import wx&quot; will find the package in the subdirectory like it would
+have if it was still located directly in site-packages.  I say
+&quot;optionally&quot; above because that is how you can control which install
+of wxPython is the default one.  Which ever version installs the
+wx.pth file will be the one that is imported with a plain &quot;import wx&quot;
+statement.  Of course you can always manipulate that by editing the
+wx.pth file, or by setting PYTHONPATH in the environment, or by the
+method described in the next paragraph.</p>
+<p>Finally, a new module named wxversion.py is installed to the
+site-packages directory.  It can be used to manipulate the sys.path at
+runtime so your applications can select which version of wxPython they
+would like to to have imported.  You use it like this:</p>
+<pre class="literal-block">
+import wxversion
+wxversion.select(&quot;2.4&quot;)
+import wx
+</pre>
+<p>Then even though a 2.5 version of wxPython may be the default the
+application that does the above the first time that wx is imported
+will actually get a 2.4 version.  <strong>NOTE:</strong> There isn't actually a 2.4
+version of wxPython that supports this, but there will be.</p>
+<p>Please see this wiki page for more details, HowTo's and FAQ's:
+<a class="reference" href="http://wiki.wxpython.org/index.cgi/MultiVersionInstalls">http://wiki.wxpython.org/index.cgi/MultiVersionInstalls</a></p>
+</div>
+<div class="section" id="miscellaneous-stuff">
+<h1><a name="miscellaneous-stuff">Miscellaneous Stuff</a></h1>
 <p>wxPyDefaultPosition and wxPyDefaultSize are gone.  Use the
 wxDefaultPosition and wxDefaultSize objects instead.</p>
 <p>Similarly, the wxSystemSettings backwards compatibiility aliases for
@@ -742,15 +825,6 @@ wxPyTypeCast at all.</p>
 there are compatibility aliases for much of the above items.</p>
 <p>The wxWave class has been renamed to wxSound, and now has a slightly
 different API.</p>
-<p>wx.TaskbarIcon works on wxGTK-based platforms (for some window
-managers,) however you have to manage it a little bit more than you
-did before.  Basically, the app will treat it like a top-level frame
-in that if the wx.TaskBarIcon still exists when all the frames are
-closed then the app will still not exit.  You need to ensure that the
-wx.TaskBarIcon is destroyed when your last Frame is closed.  For
-wxPython apps it is usually enough if your main frame object holds the
-only reference to the wx.TaskBarIcon, then when the frame is closed
-Python reference counting takes care of the rest.</p>
 <p>Before Python 2.3 it was possible to pass a floating point object as a
 parameter to a function that expected an integer, and the
 PyArg_ParseTuple family of functions would automatically convert to
--- a/wxPython/docs/MigrationGuide.txt
+++ b/wxPython/docs/MigrationGuide.txt
@@ -403,7 +403,7 @@ Sizers
 ------

 The hack allowing the old "option" keyword parameter has been removed.
-If you use keyword args with w.xSizer Add, Insert, or Prepend methods
+If you use keyword args with wx.Sizer Add, Insert, or Prepend methods
 then you will need to use the ``proportion`` name instead of
 ``option``.  (The ``proportion`` keyword was also allowed in 2.4.2.4.)

@@ -441,14 +441,14 @@ First a bit about how things used to work:
      flag then when layout was calculated the item's ``GetBestSize``
      would be used to reset the minimal size that the sizer used.

-The main thrust of the new Sizer changes was to make behaviour like
+The main thrust of the new Sizer changes was to make behavior like
 ``wx.ADJUST_MINSIZE`` be the default, and also to push the tracking of
 the minimal size to the window itself (since it knows its own needs)
 instead of having the sizer take care of it.  Consequently these
 changes were made:

    * The ``wx.FIXED_MINSIZE`` flag was added to allow for the old
-      behaviour.  When this flag is used the size a window has when
+      behavior.  When this flag is used the size a window has when
      added to the sizer will be treated as its minimal size and it
      will not be readjusted on each layout.

@@ -669,8 +669,6 @@ channel and will now only create a mask when all the pixels in the
 image are either fully transparent or fully opaque.  In addition, the
 wx.DC.DrawBitmap and wx.DC.Blit methods are able to correctly blend
 the pixels in the image with partially transparent alpha values.
-(Currently only on MSW and Mac, if anybody knows how to do it for GTK
-then please submit a patch!)

 If you are using a PNG with an alpha channel but you need to have a
 wx.Mask like you automatically got in 2.4 then you can do one of the
@@ -786,6 +784,7 @@ The help module no longer exists and the classes therein are now part
 of the core module imported with wxPython.wx or the wx package.


+
 wx.TaskBarIcon
 --------------

@@ -821,9 +820,76 @@ and the MainLoop will not exit.



+Version Number Change
+---------------------

-Other Stuff
-----------
+**[Changed in 2.5.3.x]** 
+
+Starting with 2.5.3.0 the Unicode versions of wxPython will no longer
+have a 'u' appended to the fourth component of the version number.
+Please check for the presence of "unicode" in the `wx.PlatformInfo`
+tuple instead.  (This tuple of strings has been available since the
+first 2.5 version.) For example::
+
+     if "unicode" in wx.PlatformInfo:
+         # do whatever
+	 ...
+
+
+
+
+Multi-Version Installs
+----------------------
+
+**[Changed in 2.5.3.x]** 
+
+Starting with 2.5.3.0 the wx and wxPython package directories will be
+installed in a subdirectory of the site-packages directory, instead of
+directly in site-packages.  This is done to help facilitate having
+multiple versions of wxPython installed side-by-side.  Why would you
+want to do this?  One possible scenario is you have an app that
+requires wxPython 2.4 but you want to use the newest 2.5 to do your
+own development with.  Or perhaps you want to be able to test your app
+with several different versions of wxPython to ensure compatibility.
+Before everyone panics, rest asured that if you only install one
+version of wxPython then you should notice no difference in how things
+work.
+
+In addition to installing wxPython into a "versioned" subdirectory of
+site-packages, a file named `wx.pth` is optionally installed that will
+contain the name of the versioned subdirectory.  This will cause that
+subdirectory to be automatically added to the sys.path and so doing an
+"import wx" will find the package in the subdirectory like it would
+have if it was still located directly in site-packages.  I say
+"optionally" above because that is how you can control which install
+of wxPython is the default one.  Which ever version installs the
+wx.pth file will be the one that is imported with a plain "import wx"
+statement.  Of course you can always manipulate that by editing the
+wx.pth file, or by setting PYTHONPATH in the environment, or by the
+method described in the next paragraph.
+
+Finally, a new module named wxversion.py is installed to the
+site-packages directory.  It can be used to manipulate the sys.path at
+runtime so your applications can select which version of wxPython they
+would like to to have imported.  You use it like this::
+
+      import wxversion
+      wxversion.select("2.4")
+      import wx
+
+Then even though a 2.5 version of wxPython may be the default the
+application that does the above the first time that wx is imported
+will actually get a 2.4 version.  **NOTE:** There isn't actually a 2.4
+version of wxPython that supports this, but there will be.
+
+Please see this wiki page for more details, HowTo's and FAQ's:
+http://wiki.wxpython.org/index.cgi/MultiVersionInstalls
+
+
+
+
+Miscellaneous Stuff
+-------------------

 wxPyDefaultPosition and wxPyDefaultSize are gone.  Use the
 wxDefaultPosition and wxDefaultSize objects instead.
--- a/wxPython/docs/bin/everything
+++ b/wxPython/docs/bin/everything
@@ -3,7 +3,7 @@

 b 23 gtk2 t
 b 23 gtk2   BUILD_RENAMERS=0 PREP_ONLY=1 FULL_DOCS=1
-docs/bin/simplify.py
+##docs/bin/simplify.py
 docs/bin/makeapidocs
 b 23 gtk2 t
 b 23 gtk2   BUILD_RENAMERS=0 PREP_ONLY=1
--- a/wxPython/docs/wxPackage.html
+++ b/wxPython/docs/wxPackage.html
@@ -169,8 +169,8 @@ wxPython, so there are lots of examples to look at and to play with.
 Here is one of them, it is the <tt class="literal"><span class="pre">simple</span></tt> sample.</p>
 <pre class="literal-block">
 #----------------------------------------------------------------------
-# A very simple wxPython example.  Just a wxFrame, wxPanel,
-# wxStaticText, wxButton, and a wxBoxSizer, but it shows the basic
+# A very simple wxPython example.  Just a wx.Frame, wx.Panel,
+# wx.StaticText, wx.Button, and a wx.BoxSizer, but it shows the basic
 # structure of any wxPython application.
 #----------------------------------------------------------------------

@@ -244,11 +244,14 @@ class MyFrame(wx.Frame):
 class MyApp(wx.App):
    def OnInit(self):
        frame = MyFrame(None, &quot;Simple wxPython App&quot;)
-        frame.Show(True)
        self.SetTopWindow(frame)
+
+        print &quot;Print statements go to this stdout window by default.&quot;
+
+        frame.Show(True)
        return True
        
-app = MyApp(True)
+app = MyApp(redirect=True)
 app.MainLoop()


--- a/wxPython/docs/xml/wxPython-metadata.xml
+++ b/wxPython/docs/xml/wxPython-metadata.xml
@@ -5724,7 +5724,7 @@ value as used by the parent. In addition, if the window overrides
 ShouldInheritColours to return false, the colours will not be changed
 no matter what and only the font might.

-This rather complicated logic is necessary in order to accomodate the
+This rather complicated logic is necessary in order to accommodate the
 different usage scenarius. The most common one is when all default
 attributes are used and in this case, nothing should be inherited as
 in modern GUIs different controls use different fonts (and colours)