X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/607d79b82b20d9e958cb213017479b84adda02c1..2356708db31b737c6eae53c2316b642aa5a2e68d:/utils/wxPython/README.txt diff --git a/utils/wxPython/README.txt b/utils/wxPython/README.txt index d62970972e..93d9987273 100644 --- a/utils/wxPython/README.txt +++ b/utils/wxPython/README.txt @@ -1,45 +1,254 @@ wxPython README --------------- -Introduction +Welcome to the wonderful world of wxPython! + +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 + +There are also some other sample files there for you to play with and +learn from. + +If you selected to install the documentation then point your browser +to [install dir]\wxPython\docs\index.htm and you will then be looking +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 ------------ -The code in this subtree is a Python Extension Module that enables the -use of wxWindows from the Python language. So what is Python? Go to -http://www.python.org to learn more but in a nutshell, it's an -extremly cool object oriented language. It's easier than Perl and -nearly as powerful. It runs on more platforms than Java, and by some -reports, is even faster than Java with a JIT compiler! - -So why would you want to use wxPython over just C++ and wxWindows? -Personally I prefer using Python for everything. I only use C++ when -I absolutly have to eek more performance out of an algorithm, and even -then I ususally code it as an extension module and leave the majority -of the program in Python. Another good thing to use wxPython for is -quick prototyping of your wxWindows apps. With C++ you have to -continuously go though the edit-compile-link-run cycle, which can be -quite time comsuming. With Python it is only an edit-run cycle. You -can easily build an application in a few hours with Python that would -normally take a few days with C++. Converting a wxPython app to a -C++/wxWindows app should be a straight forward task. - -This extension module attempts to mirror the class heiarchy of -wxWindows as closely as possble. This means that there is a wxFrame -class in wxPython that looks, smells, tastes and acts almost the same -as the wxFrame class in the C++ version. Unfortunatly, I wasn't able -to match things exactly because of differences in the languages, but -the differences should be easy to absorb because they are natural to -Python. For example, some methods that return mutliple values via -argument pointers in C++ will return a tuple of values in Python. -These differences have not been documented yet so if something isn't -working the same as described in the wxWindows documents the best -thing to do is to scan through the wxPython sources, especially the .i -files, as that is where the interfaces for wxPython are defined. - -Currently this extension module is designed such that the entire -application will be written in Python. I havn't tried it yet, but I -am sure that attempting to embed wxPython in a C++ wxWindows -application will cause problems. However there is a plan to support -this in the future. + +Since wxPython is a blending of multiple technologies, help comes from +multiple sources. See the http://alldunn.com/wxPython for details on +various sources of help, but probably the best source is the +wxPython-users mail list. You can view the archive or subscribe by +going to + + http://starship.python.net/mailman/listinfo/wxpython-users + +Or you can send mail directly to the list using this address: + + wxpython-users@starship.python.net + +---------------------------------------------------------------------- + +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 +------------------- +Bug fix for ListCtrl in test4.py (Was a missing file... DSM!) + +Bug fix for occassional GPF on Win32 systems upon termination of a +wxPython application. + +Added wxListBox.GetSelections returning selections as a Tuple. + +Added a wxTreeItemData that is able to hold any Python object and be +associated with items in a wxTreeCtrl. Added test pytree.py to show +this feature off. + +Added wxSafeYield function. + +OpenGL Canvas can be optionally compiled in to wxPython. + +Awesome new Demo Framework for showing off wxPython and for learning +how it all works. + +The pre-built Win32 version is no longer distributing the wxWindows +DLL. It is statically linked with the wxWindows library instead. + +Added a couple missing items from the docs. + +Added wxImage, wxImageHandler, wxPNGHandler, wxJPEGHandler, +wxGIFHandler and wxBMPHandler. + +Added new methods to wxTextCtrl. + +Fixed some problems with how SWIG was wrapping some wxTreeCtrl +methods. + + + +What's new in 2.0b8 +------------------- +Support for using Python threads in wxPython apps. + +Several missing methods from various classes. + +Various bug fixes. + + + +What's new in 2.0b7 +------------------- +Added DLG_PNT and DLG_SZE convienience methods to wxWindow class. + +Added missing constructor and other methods for wxMenuItem. + + + +What's new in 2.0b6 +------------------- +Just a quickie update to fix the self-installer to be compatible with +Python 1.5.2b2's Registry settings. + + +What's new in 2.0b5 +------------------- +Well obviously the numbering scheme has changed. I did this to +reflect the fact that this truly is the second major revision of +wxPython, (well the third actually if you count the one I did for +wxWindows 1.68 and then threw away...) and also that it is associated +with the 2.0 version of wxWindows. + +I have finally started documenting wxPython. There are several pages +in the wxWindows documentation tree specifically about wxPython, and I +have added notes within the class references about where and how wxPython +diverges from wxWindows. + +Added wxWindow_FromHWND(hWnd) for wxMSW to construct a wxWindow from a +window handle. If you can get the window handle into the python code, +it should just work... More news on this later. + +Added wxImageList, wxToolTip. + +Re-enabled wxConfig.DeleteAll() since it is reportedly fixed for the +wxRegConfig class. + +As usual, some bug fixes, tweaks, etc. + + + +What's new in 0.5.3 +------------------- +Added wxSashWindow, wxSashEvent, wxLayoutAlgorithm, etc. + +Various cleanup, tweaks, minor additions, etc. to maintain +compatibility with the current wxWindows. + + + +What's new in 0.5.0 +------------------- +Changed the import semantics from "from wxPython import *" to "from +wxPython.wx import *" This is for people who are worried about +namespace pollution, they can use "from wxPython import wx" and then +prefix all the wxPython identifiers with "wx." + +Added wxTaskbarIcon for wxMSW. + +Made the events work for wxGrid. + +Added wxConfig. + +Added wxMiniFrame for wxGTK. + +Changed many of the args and return values that were pointers to gdi +objects to references to reflect changes in the wxWindows API. + +Other assorted fixes and additions. + @@ -53,7 +262,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... @@ -73,6 +281,8 @@ version segfault shortly after starting up. 3. Varioius bug fixes, enhancements, etc. +---------------------------------------------------------------------- + Build Instructions @@ -88,8 +298,8 @@ 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/python/#swig, and they should -also end up in the 1.2 version of SWIG. +http://starship.skyport.net/crew/robind/#swig, and they should also +end up in the 1.2 version of SWIG. wxPython is organized as a Python package. This means that the directory containing the results of the build process should be a @@ -111,32 +321,33 @@ there, make sure wxUSE_OWNER_DRAWN is also set to 1. 2. Change into the $(WXWIN)/utils/wxPython/src directory. -3. Edit makefile.nt and specify where your python installation is at. +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. -4. Run nmake -f makefile.nt +4. Run nmake -f makefile.vc 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://starship.skyport.net/crew/robind/python. +http://alldunn.com/wxPython/. -6. Change to the $(WXWIN)/utils/wxPython/tests directory. +6. Change to the $(WXWIN)/utils/wxPython/demo directory. -7. Try executing the test programs. Note that some of these print -diagnositc or test info to standard output, so they will require the -console version of python. For example: +7. Try executing the demo program. For example: - python test1.py + python demo.py -To run them without requiring a console, you can use the pythonw.exe +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. Unix ---- +0. I configure wxWindows like this, YMMV: + +./configure --with-gtk --disable-shared --enable-threads --disable-unicode 1. Change into the $(WXWIN)/utils/wxPython/src directory. @@ -155,17 +366,13 @@ module: make install -5. Change to the $(WXWIN)/utils/wxPython/tests directory. - -6. Try executing the test programs. For example: - - python test1.py - +5. Change to the $(WXWIN)/utils/wxPython/demo directory. +6. Try executing the demo program. For example: ------------------------- -8/8/1998 + python demo.py +---------------- Robin Dunn robin@alldunn.com