Welcome to the wonderful world of wxPython!
-Now that you have installed the Win32 extension module, you can try it
+Once you have installed the wxPython extension module, you can try it
out by going to the [install dir]\wxPython\demo directory and typing:
python demo.py
as most classes and methods are used identically. Where there are
differences they are documented with a "wxPython Note."
+On Win32 systems the binary self-installer creates a program group on
+the Start Menu that contains a link to running the demo and a link to
+the help file. To help you save disk space I'm now using Microsoft's
+HTML Help format. If your system doesn't know what to do with the help
+file, you can install the HTML Help Viewer as part of IE 4+, NT
+Service Pack 4+, or the HTML Workshop at
+
+http://msdn.microsoft.com/workshop/author/htmlhelp/download.asp.
+
Getting Help
wxpython-users@starship.python.net
+----------------------------------------------------------------------
+
+What's new in 2.1b4
+--------------------
+
+Much more support for event-less callbacks and add-on modules
+
+Created add-on module with wxOGL classes.
+
+
+
+What's new in 2.1b3
+--------------------
+
+This release is syncronized with release 2.1 snapshot 9 of wxWindows.
+
+Switched to using SWIG from CVS (see http://swig.cs.uchicago.edu/cvs.html)
+for some of the new features and such. Also they have encorporated my
+patches so there is really no reason to stick with the current (very
+old) release... This version of SWIG gives the following new
+features:
+
+ 1. Keyword arguments. You no longer have to specify all the
+ parameters with defaults to a method just to specify a
+ non-default value on the end. You can now do this instead:
+
+ win = wxWindow(parent, -1, style = mystyle)
+
+ 2. There is now an an equivalence between Python's None and C++'s
+ NULL. This means that any methods that might return NULL will
+ now return None and you can use none where wxWindows might be
+ expecting NULL. This makes things much more snake-ish.
+
+
+There is a new build system based on a new Python program instead of
+raw makefiles. Now wxPython builds are virtually the same on MSW or
+Unix systems. See the end of this file for new build instructions and
+see distrib/build.py for more details.
+
+wxDC.Bilt now includes the useMask parameter, and has been split into
+two different versions. wxDC.BlitXY is like what was there before and
+takes raw coordinants and sizes, and the new wxDC.Blit is for the new
+interface using wxPoints and a wxSize.
+
+
+
+
+
+What's new in 2.1b2
+--------------------
+
+Added the missing wxWindow.GetUpdateRegion() method.
+
+Made a new change in SWIG (update your patches everybody) that
+provides a fix for global shadow objects that get an exception in
+their __del__ when their extension module has already been deleted.
+It was only a 1 line change in .../SWIG/Modules/pycpp.cxx at about
+line 496 if you want to do it by hand.
+
+It is now possible to run through MainLoop more than once in any one
+process. The cleanup that used to happen as MainLoop completed (and
+prevented it from running again) has been delayed until the wxc module
+is being unloaded by Python.
+
+I fixed a bunch of stuff in the C++ version of wxGrid so it wouldn't
+make wxPython look bad.
+
+wxWindow.PopupMenu() now takes a wxPoint instead of x,y. Added
+wxWindow.PopupMenuXY to be consistent with some other methods.
+
+Added wxGrid.SetEditInPlace and wxGrid.GetEditInPlace.
+
+You can now provide your own app.MainLoop method. See
+wxPython/demo/demoMainLoop.py for an example and some explaination.
+
+Got the in-place-edit for the wxTreeCtrl fixed and added some demo
+code to show how to use it.
+
+Put the wxIcon constructor back in for GTK as it now has one that
+matches MSW's.
+
+Added wxGrid.GetCells
+
+Added wxSystemSettings static methods as functions with names like
+wxSystemSettings_GetSystemColour.
+
+Removed wxPyMenu since using menu callbacks have been depreciated in
+wxWindows. Use wxMenu and events instead.
+
+Added alternate wxBitmap constructor (for MSW only) as
+ wxBitmapFromData(data, type, width, height, depth = 1)
+
+Added a helper function named wxPyTypeCast that can convert shadow
+objects of one type into shadow objects of another type. (Like doing
+a down-cast.) See the implementation in wx.py for some docs.
+
+Fixed wxImage GetData and SetData to properly use String objects for
+data transfer.
+
+Added access methods to wxGridEvent.
+
+New Makefile/Setup files supporting multiple dynamic extension modules
+for unix systems.
+
+Fixes for the wxGLCanvas demo to work around a strange bug in gtk.
+
+SWIG support routines now compiled separately instead of being bundled
+in wx.cpp.
+
+
+
+
+
+What's new in 2.1b1
+--------------------
+Fixed wxComboBox.SetSelection so that it actually sets the selected
+item. (Actually just removed it from wxPython and let it default to
+wxChoice.SetSelection which was already doing the right thing.)
+
+Added the Printing Framework.
+
+Switched back to using the wxWindows DLL for the pre-built Win32
+version. The problem was needing to reinitialize static class info
+data after loading each extension module.
+
+Lots of little tweaks and additions to reflect changes to various
+wxWindows classes.
+
+Fixed a bug with attaching objects to tree items. Actually was a
+symptom of a larger problem with not obtaining the interpreter lock
+when doing any Py_DECREFs.
+
+wxSizer and friends. Sizers are layout tools that manage a colection
+of windows and sizers. Different types of sizers apply different
+types of layout algorithms. You saw it here first! These classes are
+not even in the wxWindows C++ library yet!
+
+
What's new in 2.0b9
-------------------
DSM (Dumb Stupid Mistake) on my part but it was nasty none the less
because the behavior was so different on different platforms.
-
The dynamicly loaded module on Solaris is still segfaulting, so it
must have been a different issue all along...
3. Varioius bug fixes, enhancements, etc.
+----------------------------------------------------------------------
generated C++ code is included under the src directory.
I added a few minor features to SWIG to control some of the code
-generation. If you want to playaround with this the patches are in
-wxPython/SWIG.patches and they should be applied to the 1.1p5 version
-of SWIG. These new patches are documented at
-http://starship.skyport.net/crew/robind/#swig, and they should also
-end up in the 1.2 version of SWIG.
+generation. If you want to play around with this you will need to get
+a recent version of SWIG from their CVS or from a daily build. See
+http://www.swig.org/ for details.
wxPython is organized as a Python package. This means that the
directory containing the results of the build process should be a
subdirectory of a directory on the PYTHONPATH. (And preferably should
be named wxPython.) You can control where the build process will dump
-wxPython by setting the TARGETDIR makefile variable. The default is
-$(WXWIN)/utils/wxPython, where this README.txt is located. If you
-leave it here then you should add $(WXWIN)/utils to your PYTHONPATH.
-However, you may prefer to use something that is already on your
-PYTHONPATH, such as the site-packages directory on Unix systems.
+wxPython by setting the TARGETDIR variable for the build utility, (see
+below.)
-Win32
------
+1. Build wxWindows as described in its BuildCVS.txt file. For *nix
+ systems I run configure with these flags:
-1. Build wxWindows with wxUSE_RESOURCE_LOADING_IN_MSW set to 1 in
-include/wx/msw/setup.h so icons can be loaded dynamically. While
-there, make sure wxUSE_OWNER_DRAWN is also set to 1.
+ --with-gtk
+ --with-libjpeg
+ --without-odbc
+ --enable-unicode=no
+ --enable-threads=yes
+ --enable-socket=yes
+ --enable-static=no
+ --enable-shared=yes
+ --disable-std_iostreams
-2. Change into the $(WXWIN)/utils/wxPython/src directory.
+ You can use whatever flags you want, but I know these work.
-3. Edit makefile.vc and specify where your python installation is at.
-You may also want to fiddle with the TARGETDIR variable as described
-above.
+ For Win32 systems I use Visual C++ 6.0, but 5.0 should work. The
+ build utility currently does not support any other win32 compilers.
-4. Run nmake -f makefile.vc
+2. At this point you may want to make an alias or symlink, script,
+ batch file, whatever on the PATH that invokes
+ $(WXWIN)/utils/wxPython/distrib/build.py to help simplify matters
+ somewhat. For example, on my win32 system I have a file named
+ build.bat in a directory on the PATH that contains:
-5. If it builds successfully, congratulations! Move on to the next
-step. If not then you can try mailing me for help. Also, I will
-always have a pre-built win32 version of this extension module at
-http://alldunn.com/wxPython/.
+ python $(WXWIN)/utils/wxPython/distrib/build.py %1 %2 %3 %4 %5 %6
-6. Change to the $(WXWIN)/utils/wxPython/demo directory.
-
-7. Try executing the demo program. For example:
-
- python demo.py
-To run it without requiring a console, you can use the pythonw.exe
-version of Python either from the command line or from a shortcut.
+3. Change into the $(WXWIN)/utils/wxPython/src directory.
+4. Type "build -b" to build wxPython and "build -i" to install it.
+ The build.py script actually generates a Makefile based on what it
+ finds on your system and information found in the build.cfg file.
+ If you have troubles building or you want it built or installed in
+ a different way, take a look at the docstring in build.py. You may
+ be able to override configuration options in a file named
+ build.local.
-Unix
-----
-0. I configure wxWindows like this, YMMV:
+5. To build and install the add-on modules, change to the appropriate
+ directory under $(WXWIN)/utils/wxPython/modules and run the build
+ utility again.
-./configure --with-gtk --without-shared --with-threads --without-unicode --with-libjpeg
-
-
-1. Change into the $(WXWIN)/utils/wxPython/src directory.
+6. Change to the $(WXWIN)/utils/wxPython/demo directory.
-2. Edit Setup.in and ensure that the flags, directories, and toolkit
-options are correct. See the above commentary about TARGETDIR. There
-are a few sample Setup.in.[platform] files provided.
+7. Try executing the demo program. For example:
-3. Run this command to generate a makefile:
+ python demo.py
- make -f Makefile.pre.in boot
+To run it without requiring a console on win32, you can use the
+pythonw.exe version of Python either from the command line or from a
+shortcut.
-4. Run these commands to build and then install the wxPython extension
-module:
- make
- make install
+----------------
+Robin Dunn
+robin@alldunn.com
-5. Change to the $(WXWIN)/utils/wxPython/demo directory.
-6. Try executing the demo program. For example:
- python demo.py
-----------------
-Robin Dunn
-robin@alldunn.com
projects / wxWidgets.git / blobdiff