]> git.saurik.com Git - wxWidgets.git/blobdiff - wxPython/docs/CHANGES.txt
Applied new master define for CommandBar vs. PocketPC mixed bar.
[wxWidgets.git] / wxPython / docs / CHANGES.txt
index ce2c94a478890870b91fd2132a26c654f10bf823..0b812f7ef5446f54ff45519bd1ca16fec996d6de 100644 (file)
-CHANGES.txt for wxPython
+Recent Changes for wxPython
 =====================================================================
 
-2.5.1.x
+2.5.2.1
 -------
 
-(See also the MigrationGuide.txt file for details about some of the
+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 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.
+
+The changes that implemented the incompatible wx.DC methods in 2.5.1.5
+have been reverted.  The wx.DC methods are now compatible with the 2.4
+implemetation.  In addition a set of renamed methods have been added
+that take wx.Point and/or wx.Size objects instead of individual
+parameters. 
+
+Added wx.lib.mixins.listctrl.TextEditMixin, a mixin class that allows
+all columns of a wx.ListCtrl in report mode to be edited.
+
+Deprecated the wx.iewin module.
+
+Deprecated the wx.Sizer.AddWindow, AddSizer, AddSpacer methods as well
+as their Insert* and Prepend* counterparts.
+
+Added a generic StaticBitmap class in wx.lib.statbmp for the same
+reasons that stattext was created, so it could be mouse sensitive on
+all platforms like normal windows.  Also updated stattext.py and
+buttons.py to handle attribute (font & colour) defaults and
+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
+
+EVT_STC_POSCHANGED has been removed as it has been deprecated in
+Scintilla for several releases now.
+
+All the Window and GDI (pen, bitmap, etc.) class constructors and also
+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.
+
+
+
+
+2.5.1.5
+-------
+
+(See also the MigrationGuide_ file for details about some of the
 big changes that have happened in this release and how you should
 adapt your code.)
 
+.. _MigrationGuide: MigrationGuide.html
+
+
+The wxWindows project and library is now known as wxWidgets.  Please
+see http://www.wxwindows.org/name.htm for more details.  This won't
+really affect wxPython all that much, other than the fact that the
+wxwindows.org domain name will be changing to wxwidgets.org, so mail
+list, CVS, and etc. addresses will be changing.  We're going to try
+and smooth the transition as much as possible, but I wanted you all to
+be aware of this change if you run into any issues.
+
+
 Many, many little fixes, changes and additions done as part of the move
 to wxWidgets 2.5 that I have forgotten about.
 
@@ -42,7 +168,7 @@ installing them also on my main Mandrake 9.2 box.
 
 There are some big changes in the OS X disk image.  The actual
 Installer package now *only* installs the wxMac dynlibs, wxPython
-extension modules and Python pacakges, and also the command-line tool
+extension modules and Python packages, and also the command-line tool
 scripts. The remaining items (demo, samples, and application bundles
 for the Demo, PyCrust and XRCed) are now top-level items in the disk
 image (.dmg file) that users can just drag and drop to wherever they
@@ -69,6 +195,37 @@ it.
 Updated wx.lib.calendar with many fixes and enhancements from Joerg
 "Adi" Sieker. 
 
+Added wx.Display and wx.VideoMode.
+
+AppleEvents can be handled by overriding wx.App methods MacOpenFile,
+MacPrintFile, MacNewFile, and MacReopenApp.
+
+Added wx.PlatformInfo which is a tuple containing strings that
+describe the platform and build options of wxPython.  See the
+MigrationGuide for more details.
+
+Created a new extension module "activex" from Lindsay Mathieson's
+newest wxActiveX_ class.  (The existing iewin module used an older
+version of this code, but only exposed the wxIEHtmlWin class.)  This
+new module will (in theory ;-) ) allow you to host arbitrary ActiveX
+controls in a wx.Window, **without** requiring the use of the win32com
+and other PyWin32 modules!  This should eliminate the cronic problems
+that have resulted from minor mismatches in how PyWin32 handles the
+GIL and tstate when making callbacks, etc.  The older iewin module
+will be left in this release as the new stuff is not fully backwards
+compatible, but you should migrate your code to the new IEHtmlWindow
+in wx.lib.iewin, so the old one can be eventually removed.
+Additionally, I've always considered that the wx.lib.activexwrapper
+module is an ugly hack that I only included in the lib because I
+couldn't figure out anything better.  Well now we have something that,
+if it isn't already, has the potential to be better.  So consider
+migrating away from using activexwrapper as well.  Please see the
+MigrationGuide for more details on using the new module.
+
+.. _wxActiveX: http://members.optusnet.com.au/~blackpaw1/wxactivex.html
+
+Floats are allowed again as function parameters where ints are expected.
+