X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/0812732316f715a480526cedcd481e7fc31a130c..7eb4e9cc0f3590fffda78bf02c47b25c41583eba:/utils/wxPython/README.txt diff --git a/utils/wxPython/README.txt b/utils/wxPython/README.txt index a43350f9a7..6222375387 100644 --- a/utils/wxPython/README.txt +++ b/utils/wxPython/README.txt @@ -1,204 +1,70 @@ wxPython README --------------- -Introduction ------------- -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. - - -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. - - - - -What's new in 0.4.2 -------------------- - -wxPython on wxGTK works!!! Both dynamic and static on Linux and -static on Solaris have been tested. Many thanks go to Harm - for his astute detective work on tracking -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. +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: -The dynamicly loaded module on Solaris is still segfaulting, so it -must have been a different issue all along... + 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." -What's New in 0.4 ------------------ +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 -1. Worked on wxGTK compatibility. It is partially working. On a -Solaris/Sparc box wxPython is working but only when it is statically -linked with the Python interpreter. When built as a dyamically loaded -extension module, things start acting weirdly and it soon seg-faults. -And on Linux both the statically linked and the dynamically linked -version segfault shortly after starting up. +http://msdn.microsoft.com/workshop/author/htmlhelp/download.asp. -2. Added Toolbar, StatusBar and SplitterWindow classes. -3. Varioius bug fixes, enhancements, etc. - - - -Build Instructions ------------------- -I used SWIG (http://www.swig.org) to create the source code for the -extension module. This enabled me to only have to deal with a small -amount of code and only have to bother with the exceptional issues. -SWIG takes care of the rest and generates all the repetative code for -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/python/#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 -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 ------ - -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. - -3. Edit makefile.nt 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 - -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. - -6. Change to the $(WXWIN)/utils/wxPython/tests 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: - - python test1.py - -To run them without requiring a console, you can use the pythonw.exe -version of Python either from the command line or from a shortcut. +Getting Help +------------ +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 -Unix ----- + http://starship.python.net/mailman/listinfo/wxpython-users -1. Change into the $(WXWIN)/utils/wxPython/src directory. +Or you can send mail directly to the list using this address: -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. + wxpython-users@starship.python.net -3. Run this command to generate a makefile: - make -f Makefile.pre.in boot +Other Info +---------- -4. Run these commands to build and then install the wxPython extension -module: +Please also see the following files in this directory: - make - make install + CHANGES.txt Information about new features, fixes, etc. in + each release. + BUILD.txt Instructions for building wxPython on various + platforms. -5. Change to the $(WXWIN)/utils/wxPython/tests directory. + licence.txt Text of the wxWindows license. -6. Try executing the test programs. For example: - python test1.py +---------------- +Robin Dunn +robin@alldunn.com ------------------------- -10/20/1998 -Robin Dunn -robin@alldunn.com