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.
+
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.
+----------------------------------------------------------------------
+
Build Instructions
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
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.
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
projects / wxWidgets.git / blobdiff