"wxWindows" --> "wxWidgets"

[wxWidgets.git] / wxPython / docs / CHANGES.txt

diff --git a/wxPython/docs/CHANGES.txt b/wxPython/docs/CHANGES.txt
index 92636c139b5f2e231379d2b992d46865baa1b24b..f27ca527b73faa4f829b7c317e8951272b8f19c7 100644 (file)
--- a/wxPython/docs/CHANGES.txt
+++ b/wxPython/docs/CHANGES.txt
@@ -1,7 +1,7 @@
 Recent Changes for wxPython
 =====================================================================
 
-2.5.2.0
+2.5.2.7
 -------
 
 wx.ADJUST_MINSIZE is now the default behaviour for window items in
@@ -11,24 +11,8 @@ be used for the minimum size used by the sizer.  The wx.FIXED_MINSIZE
 flag was added that will cause the sizer to use the old behaviour in
 that it will *not* call the window's methods to determine the new best
 size, instead the minsize that the window had when added to the sizer
-(or the size the window was created with) will always be used.  
-
-Related to the above, when controls and some other window types are
-created either the size passed to the constructor, or their "best
-size" if an explicit size was not passed in, is set as the window's
-minimal size.  For non top-level windows that hasn't meant much in the
-past, but now the sizers are sensitive to the window's minimal size.
-The key point to understand here is that it is no longer the window's
-size it has when added to the sizer that matters, but its minimal
-size.  So you might have some issues to iron out if you create a
-control without a size and then set its size to something before
-adding it to the sizer.  Since it's minimal size is probably not the
-size you set then the sizer will appear to be misbehaving.  The fix is
-to either set the size when calling the window's constructor, or to
-reset the min size by calling SetSizeHints.  You can call SetSizeHints
-at anytime to change the minsize of a window, just call the sizer's
-Layout method to redistribute the controls as needed.
-
+(or the size the window was created with) will always be used.  Please
+see the Sizers section in the Migration Guide for more details.
 
 Added new MaskedEditControl code from Will Sadkin.  The modules are
 now locaed in their own sub-package, wx.lib.masked.  Demos updated.
@@ -100,6 +84,40 @@ many toplevel functions and static methods will now check that a
 wx.App object has already been created and will raise a
 wx.PyNoAppError exception if not.
 
+Added more default args as needed to allow most window types to be
+constructed with only the parent window arg.  In some cases other args
+may be required for normal operation, but they can usually be set
+after construction.
+
+Removed the deprecated ErrorDialogs and PythonBitmaps modules.  If you
+were using these in your apps then please join wxPython-dev and assist
+with a more modern reimplementation.
+
+Added a new version (0.8.3) of FloatCanvas from Chris Barker.  It's now
+in a subpackage of wx.lib.
+
+It is now possible to change the tab traversal order of controls on a
+panel or dialog.  For details see the new MoveAfterInTabOrder and
+MoveBeforeInTabOrder methods of wx.Window.
+
+Applied (and heavily modified) a patch from Eugene
+<svip123@fastmail.fm> that allows the sample modules in the demo to be
+edited and reloaded, all from within the demo.  You can switch back
+and forth between the default and your edited version, and any errors
+ocurring upon the reload are reported on the Demo tab.
+
+Added a menu item in the demo that will open a PyShell window that has
+the app and demo frame preloaded in the namespace.  This is another
+good way to explore and play with the objects in the currently running
+sample.  For example, load the Button sample and then do the following
+in the PyShell::
+
+       >>> b = frame.demoPage.GetChildren()[0]
+       >>> for x in range(0, 500, 10):
+       ...     b.Move((x, 50))
+       ...     app.Yield(True)
+       ...     wx.MilliSleep(10)
+