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 on
+ win9x with the stock python.exe and pythonw.exe executables.
+ Instead I've had to rebuild the Python loaders linked with this
+ MSLU library from Microsoft. I'd like to find a way to build
+ wxWindows/wxPython such that this is not needed...
+
+ 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.
+
+
+Bad news: The API for adding tools to toolbars has changed again.
+Good news: Toolbar tools can now have labels!
+