----------------------------------------------------------------------
+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 wxWindow 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 in the application called
+ MSLU, (Microsoft Layer for Unicode). It simply gets out of the
+ way if the app is run on an NT box, or 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.
+
+
+
+
+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
-----
Added EVT_HELP, EVT_HELP_RANGE, EVT_DETAILED_HELP,
Added wxFindReplaceDialog.
-The second phase of OOR is implemented (for wxEvtHandler and derived
-classes at least.) This means that finctions and methods that return
-an object derived from wxEvtHandler that was originally created in
-Python, will return the original python object (if it still exists)
-instead of letting SWIG wrap a new shadow object around the original
-C++ pointer.
+The second phase of OOR is implemented for wxEvtHandler, wxSizer,
+wxShape and derived classes. This means that functions and methods
+that return an object derived from wxEvtHandler that was originally
+created in Python, will return the original Python object (if it still
+exists) instead of letting SWIG wrap a new shadow object around the
+original C++ pointer.
Added some optimization methods to wxDC: GetBoundingBox, DrawLineList,
DrawPointList.
Added wxRightTextCtrl from Josu Oyanguren to wxPython.lib for aligning
text in a wxTextCtrl to the right side.
-Added wxURLDataObject and and example showing drag and drop of URLs to
+Added wxURLDataObject and an example showing drag and drop of URLs to
and from web browsers. It's still not 100% bullet-proof for all types
of browsers, but it works for the majority of cases with the popular
browsers on Windows. On wxGTK it seems that only Netscape 4.x works,
Added wxFileHistory.
-Added wxDynamicSashWindow, whcih allows you to endlessly split widnows
+Added wxDynamicSashWindow, which allows you to endlessly split windows
by dragging a little tab next to the scrollbars. Added a demo to show
-this and also the ability of multiple wxStyledStectCtrls to share the
+this and also the ability of multiple wxStyledTextCtrls to share the
same document.
Added wxEditableListBox gizmo.
wxThinSplitterWindow, and wxSplitterScrolledWindow, some of which may
also be useful by themselves.
+Added wxDllWidget from Vaclav Slavik which allows wx widgets derived
+from wxWindow to be loaded from a C++ .dll (or .so) and be used in a
+wxPython program, without the widget having to be SWIGged first. The
+visible API of the widget is limited to wxWindow methods plus a
+SendCommand method, but it is still quite powerful. See
+wxPython/contrib/dllwidget and wxPython/demo/dllwidget for more
+details.
+
projects / wxWidgets.git / blobdiff