-1->wxID_ANY, wxDefaultSize, wxDefaultPosition, TRUE->true and FALSE->false replacements.

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

diff --git a/wxPython/docs/CHANGES.txt b/wxPython/docs/CHANGES.txt
index ad7f25d0ae61d2647869f1c70a2f1f42220b250d..2873dcb92e73e74689cd85eab54cdc51c6cb4b66 100644 (file)
--- a/wxPython/docs/CHANGES.txt
+++ b/wxPython/docs/CHANGES.txt
@@ -1,21 +1,34 @@
 Recent Changes for wxPython
 =====================================================================
 
-2.5.1.6
+2.5.2.0
 -------
 
 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
-be used for the minimum size.  The wx.FIXED_MINSIZE flag was added
-that will cause the sizer to *not* call window 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.  When a window is added to a sizer it's initial size, if any, is
-set as the window's minimal size using SetSizeHints if there isn't
-already a minimal size.  You can set the window's minimal size (via
-SetSizeHints) to manually control wha tthe sizer will use when
-calculating layout.
+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.
+
 
 Added new MaskedEditControl code from Will Sadkin.  The modules are
 now locaed in their own sub-package, wx.lib.masked.  Demos updated.
@@ -42,6 +55,44 @@ inheritance the new way.  If you have custom controls of your own you
 should review stattxt.py or one of the others to see how it is to be
 done.
 
+wx.InitAllImageHandlers is now an empty function that does nothing but
+exist for backwards compatibility.  The C++ version is now called
+automatically when wxPython is initialized.  Since all the handlers
+are included in the wxWidgets shared library anyway, this imposes only
+a very small amount of overhead and removes several unneccessary
+problems.
+
+Replaced wx/lib/pubsub.py with a version that uses weak references to
+track the subscribers, plus other fixes/additions.  Thanks go to
+Oliver Schoenborn and Robb Shecter.
+
+wxGTK now uses gtk_init_check so wxPython can raise an exception if
+there is no DISPLAY available or other initializaion problem.
+
+wx.GetKeyState now has an implementation for wxGTK and is able to
+detect the up/down or toggle state of modifier and toggle keys.
+
+The LC_NUMERIC locale is now reset back to "C" (compatibility) when
+running on wxGTK to work around the fact that GTK requires the locale
+to be set to the system settings but Python depends on LC_NUMERIC
+remaining compatible with "C".
+
+Switched gizmos.TreeListCtrl to the newer version of the code from the
+wxCode project.
+
+OGL is dead! LONG LIVE OGL!  (Oops, sorry.  A bit of my dramatic side
+leaked out there...)  The wx.ogl module has been deprecated in favor
+of the new Python port of the OGL library located at wx.lib.ogl
+contributed by Pierre Hjälm.  This will hopefully greatly extend the
+life of OGL within wxPython by making it more easily maintainable and
+less prone to getting rusty as there seems to be less and less
+interest in maintaining the C++ version.  At this point there are just
+a couple minor known compatibility differences, please see the
+MigrationGuide_ file for details.
+
+.. _MigrationGuide: MigrationGuide.html
+
+
 
 
 2.5.1.5