X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/c127177f8dc31dbe99764852b8dbcc047d3ad826..8a35299aa9aaded752359a8b1a156baecd2b5d44:/utils/wxPython/README.txt diff --git a/utils/wxPython/README.txt b/utils/wxPython/README.txt index 1aef53e893..ee7ec93126 100644 --- a/utils/wxPython/README.txt +++ b/utils/wxPython/README.txt @@ -3,7 +3,7 @@ wxPython README 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 @@ -17,6 +17,15 @@ at the docs for wxWindows. For the most part you can use the C++ docs 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 @@ -34,6 +43,112 @@ Or you can send mail directly to the list using this address: wxpython-users@starship.python.net +---------------------------------------------------------------------- + +What's new in 2.1b3 +-------------------- + +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... + +New build system based on a Python program. Now wxPython builds are +the same on MSW or Unix systems. See distrib/build.py for details. + + + + +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 ------------------- @@ -162,7 +277,6 @@ down a nasty DECREF bug. Okay so I have to confess that it was just a 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... @@ -182,6 +296,7 @@ version segfault shortly after starting up. 3. Varioius bug fixes, enhancements, etc. +---------------------------------------------------------------------- @@ -195,83 +310,76 @@ me. You don't need SWIG to build the extension module as all the 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. - - -Win32 ------ +wxPython by setting the TARGETDIR variable for the build utility, (see +below.) -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. -2. Change into the $(WXWIN)/utils/wxPython/src directory. +1. Build wxWindows as described in its BuildCVS.txt file. For *nix + systems I run configure with these flags: -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. + --with-gtk + --with-libjpeg + --without-odbc + --enable-unicode=no + --enable-threads=yes + --enable-socket=yes + --enable-static=no + --enable-shared=yes + --disable-std_iostreams -4. Run nmake -f makefile.vc + You can use whatever flags you want, but I know these work. -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/. +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: -6. Change to the $(WXWIN)/utils/wxPython/demo directory. - -7. Try executing the demo program. For example: + python $(WXWIN)/utils/wxPython/distrib/build.py %1 %2 %3 %4 %5 %6 - 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 ----- +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. -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