X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/71f1334b4019c59d11ee274a73adc1fc754eee38..a81c3c2383f9096ef5e96b708a0f1c1ffe7cc6a8:/wxPython/CHANGES.txt?ds=sidebyside diff --git a/wxPython/CHANGES.txt b/wxPython/CHANGES.txt index 0e00a7930e..157dcec7f6 100644 --- a/wxPython/CHANGES.txt +++ b/wxPython/CHANGES.txt @@ -2,8 +2,99 @@ CHANGES.txt for wxPython ---------------------------------------------------------------------- -2.3.2.? +2.3.3 +----- +Added wxSplashScreen. + +Added wxGenericDirCtrl. + +Added wxMultiChoiceDialog. + +The calltip window and autocomplete window in wxSTC will now use a +wxPopupWindow if available so they can extend beyond the client area +of the STC if needed. + +Finished wrapping and providing typemaps for wxInputStream and also +added the stream ctor and other methods for wxImage so images can now +be loaded from any Python "file-like" object. + +Changed the img2py tool to use PNG instead of XPM for embedding image +data in Python source code, and the generated code now uses streams to +convert the image data to wxImage, wxBitmap, or wxIcon. + +Added the wxPython.lib.rcsizer module which contains RowColSizer. +This sizer is based on code from Niki Spahiev and lets you specify a +row and column for each item, as well as optional column or row +spanning. Cells with no item assigned to it are just left blank. +Stretchable rows or columns are specified and work the same as in +wxFlexGridSizer. + +Updated XRCed from Roman Rolinsky + +Added wxBufferedDC. + +Upgraded wxSTC from Scintilla 1.40 to Scintilla 1.45 + +UNICODE! + + wxWindows/wxPython can be compiled with unicode support enabled or + disabled. Previous to wxPython 2.3.3 non-unicode mode was always + used. Starting with 2.3.3 either mode is supported, but only if + it is also available in wxWindows on the platform. Currently + wxWindows only supports unicode on MS Windows platforms, but with + the recent release of GTK+ 2.0 it is only a matter of time until + it can be done on wxGTK (Linux and other unixes) as well. + + Unicode works best on platforms in the NT branch of the Windows + family tree (NT, win2k, XP) but it is now also possible to use the + same unicode binaries on win95/98/ME platforms as well! This is + done by using a special library and DLL with the application + called MSLU, (Microsoft Layer for Unicode). It simply gets out of + the way if the app is run on an NT box, otherwise if run on a + win9x box it loads a special DLL that provides the unicode + versions of the windows API. So far I have not been able to get + this to work perfectly on win9x. Most things work fine but + wxTaskBarIcon for example will cause a crash if used with the + unicode build on win95. + + So how do you use it? It's very simple. When unicode is enabled, + then all functions and methods in wxPython that return a wxString + from the C++ function will return a Python unicode object, and + parameters to C++ functions/methods that expect a wxString can + accept either a Python string or unicode object. If a string + object is passed then it will be decoded into unicode using the + converter pointed to by wxConvCurrent, which will use the default + system encoding. If you need to use a string in some other + encoding then you should convert it to unicode using the Python + codecs first and then pass the unicode string to the wxPython + method. + +Added wxListCtrlAutoWidthMixin from Erik Westra. + +Added wxIconBundle and wxTopLevelWindow.SetIcons. + +Added wxLocale and wxEncodingConverter. + +A little black magic... When the C++ object (for a window or +whatever) is deleted there is no way to force the Python shadow object +to also be destroyed and clean up all references to it. This leads to +crashes if the shadow object tries to call a method with the old C++ +pointer. The black magic I've done is to replace the __class__ in the +Python instance object with a class that raises an exception whenever +a method call (or other attribute access) is attempted. This works +for any class that is OOR aware. + + + +2.3.2.1 ------- +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. + +Added some patches from library contributors. + + 2.3.2