--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>Building wxPython 2.5 for Development and Testing</title>
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="building-wxpython-2-5-for-development-and-testing">
+<h1 class="title">Building wxPython 2.5 for Development and Testing</h1>
+<p>This file describes how I build wxWindows and wxPython while doing
+development and testing, and is meant to help other people that want
+to do the same thing. I'll assume that you are using either a CVS
+snapshot from <a class="reference" href="http://wxwindows.org/snapshots/">http://wxwindows.org/snapshots/</a>, a checkout from CVS, or
+one of the released wxPythonSrc-2.5.* tarballs. I'll also assume that
+you know your way around your system, the compiler, etc. and that you
+know what you are doing! ;-)</p>
+<p>If you want to also install the version of wxPython you build to be in
+your site-packages dir and be your default version of wxPython, then a
+few additional steps are needed, and you may want to use slightly
+different options. See INSTALL.txt for more details. If you only use
+the instructions in this BUILD.txt file then you will end up with a
+separate installation of wxPython and you can switch back and forth
+between this and the release version that you may already have
+installed.</p>
+<p>If you want to make changes to any of the <tt class="literal"><span class="pre">*.i</span></tt> files, (SWIG interface
+definition files,) or to regenerate the extension sources or renamer
+modules, then you will need an up to date version of SWIG. Either get
+and build the current CVS version, or version 1.3.20, and then apply
+the patches in wxPython/SWIG. See the README.txt in that dir for
+details about each patch and also info about those that may already
+have been applied to the SWIG sources. If you install this build of
+SWIG to a location that is not on the PATH (so it doesn't interfere
+with an existing SWIG install for example) then you can set a setup.py
+command-line variable named SWIG to be the full path name of the
+executable and the wxPython build will use it. See below for an
+example.</p>
+<div class="section" id="building-on-unix-like-systems-e-g-linux-and-os-x">
+<h1><a name="building-on-unix-like-systems-e-g-linux-and-os-x">Building on Unix-like Systems (e.g. Linux and OS X)</a></h1>
+<p>These platforms are built almost the same way while in development
+so I'll combine the descriptions about their build process here.
+First we will build wxWindows and install it to an out of the way
+place, then do the same for wxPython.</p>
+<ol class="arabic">
+<li><p class="first">Create a build directory in the main wxWindows dir, and configure
+wxWindows. If you want to have multiple builds with different
+configure options, just use different subdirectories. I normally
+put the configure command in a script named ".configure" in each
+build dir so I can easily blow away everything in the build dir and
+rerun the script without having to remember the options I used
+before:</p>
+<pre class="literal-block">
+mkdir bld
+cd bld
+../configure --prefix=/opt/wx/2.5 \
+ --with-gtk \
+ --with-opengl \
+ --disable-monolithic \
+ --enable-debug \
+ --enable-geometry \
+</pre>
+<p>On OS X of course you'll want to use --with-mac instead of
+--with-gtk. For GTK2 and unicode add:</p>
+<blockquote>
+<p>--enable-gtk2 --enable-unicode </p>
+</blockquote>
+<p>Notice that I used a prefix of /opt/wx/2.5. You can use whatever
+path you want, such as a path in your HOME dir or even one of the
+standard prefix paths such as /usr or /usr/local if you like, but
+using /opt this way lets me easily have multiple versions and ports
+of wxWindows "installed" and makes it easy to switch between them,
+without impacting any versions of wxWindows that may have been
+installed via an RPM or whatever. For the rest of the steps below
+be sure to also substitute "/opt/wx/2.5" with whatever prefix you
+choose for your build.</p>
+<p>If you want to use the image and zlib libraries included with
+wxWindows instead of those already installed on your system, (for
+example, to reduce dependencies on 3rd party libraries) then you
+can add these flags to the configure command:</p>
+<pre class="literal-block">
+--with-libjpeg=builtin \
+--with-libpng=builtin \
+--with-libtiff=builtin \
+--with-zlib=builtin \
+</pre>
+</li>
+<li><p class="first">To build and install wxWindows you could just use the "make"
+command but there are other libraries besides the main wxWindows
+libs that also need to be built so again I make a script to do it
+all for me so I don't forget anything. This time it is called
+".make" (I use the leading ". so when I do <tt class="literal"><span class="pre">rm</span> <span class="pre">-r</span> <span class="pre">*</span></tt> in my build
+dir I don't lose my scripts too.) This is what it looks like:</p>
+<pre class="literal-block">
+make $* \
+ && make -C contrib/src/gizmos $* \
+ && make -C contrib/src/ogl CXXFLAGS="-DwxUSE_DEPRECATED=0" $* \
+ && make -C contrib/src/stc $* \
+ && make -C contrib/src/xrc $*
+</pre>
+<p>So you just use .make as if it where make, but don't forget to set
+the execute bit on .make first!:</p>
+<pre class="literal-block">
+.make
+.make install
+</pre>
+<p>When it's done you should have an installed set of files under
+/opt/wx/2.5 containing just wxWindows. Now to use this version of
+wxWindows you just need to add /opt/wx/2.5/bin to the PATH and set
+LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.5/lib.</p>
+</li>
+<li><p class="first">I also have a script to help me build wxPython and it is checked in
+to the CVS as wxWindows/wxPython/b, but probably don't want to use
+it as it's very cryptic and expects that you want to run SWIG, so
+if you don't have the latest patched up version of SWIG then you'll
+probably get stuck. So I'll just give the raw commands instead.</p>
+<p>We're not going to install the development version of wxPython with
+these commands, so it won't impact your already installed version
+of the latest release. You'll be able test with this version when
+you want to, and use the installed release version the rest of the
+time. If do want to install the development verison please read
+INSTALL.txt.</p>
+<p>If you have more than one version of Python on your system then be
+sure to use the version of Python that you want to use when running
+wxPython programs to run the setup.py commands below. I'll be
+using python2.3.</p>
+<p>Make sure that the first wx-config found on the PATH is the one you
+installed above, and then change to the wxWindows/wxPython dir and
+run the this command:</p>
+<pre class="literal-block">
+cd wxPython
+python2.3 setup.py build_ext --inplace --debug
+</pre>
+<p>If your new wx-config script is not on the PATH, or there is some
+other version of it found first, then you can add this to the
+command line to ensure your new one is used instead:</p>
+<pre class="literal-block">
+WX_CONFIG=/opt/wx/2.5/bin/wx-config
+</pre>
+<p>If you are building with GTK2 then add the following flags to the
+command line:</p>
+<pre class="literal-block">
+WXPORT=gtk2 UNICODE=1
+</pre>
+<p>If you are wanting to have the source files regenerated with swig,
+then you need to turn on the USE_SWIG flag and optionally tell it
+where to find the new swig executable, so add these flags:</p>
+<pre class="literal-block">
+USE_SWIG=1 SWIG=/opt/swig/bin/swig
+</pre>
+<p>If you get errors about wxGLCanvas or being unable to find libGLU
+or something like that then you can add BUILD_GLCANVAS=0 to the
+setup.py command line to disable the building of the glcanvas
+module.</p>
+<p>When the setup.py command is done you should have fully populated
+wxPython and wx packages locally in wxWindows/wxPython/wxPython and
+.../wx, with all the extension modules (<tt class="literal"><span class="pre">*.so</span></tt> files) located in the
+wx package.</p>
+</li>
+<li><p class="first">To run code with the development verison of wxPython, just set the
+PYTHONPATH to the wxPython dir in the CVS tree. For example:</p>
+<pre class="literal-block">
+export LD_LIBRARY=/opt/wx/2.5/lib
+export PYTHONPATH=/myprojects/wxWindows/wxPython
+cd /myprojects/wxWindows/wxPython/demo
+python2.3 demo.py
+</pre>
+<p>OS X NOTE: You need to use "pythonw" on the command line to run
+wxPython applications. This version of the Python executable is
+part of the Python Framework and is allowed to interact with the
+display. You can also Double Click on a .py or a .pyw file from
+the finder (assuming that PythonLauncher is still associated with
+these file extensions) and it will launch the Framework version of
+Python for you. For information about creating Applicaiton Bundles
+of your wxPython apps please see the wiki and the mail lists.</p>
+<p>SOLARIS NOTE: If you get unresolved symbol errors when importing
+wxPython and you are running on Solaris and building with gcc, then
+you may be able to work around the problem by uncommenting a bit of
+code in setup.py and building again. Look for 'SunOS' in setup.py
+and uncomment the block containing it. The problem is that Sun's ld
+does not automatically add libgcc to the link step.</p>
+</li>
+</ol>
+</div>
+<div class="section" id="building-on-windows">
+<h1><a name="building-on-windows">Building on Windows</a></h1>
+<p>The Windows builds currently require the use of Microsoft Visual C++.
+Theoretically, other compilers (such as mingw32 or the Borland
+compilers) can also be used but I've never done the work to make that
+happen. If you want to try that then first you'll want to find out if
+there are any tricks that have to be done to make Python extension
+modules using that compiler, and then make a few changes to setup.py
+to accomodate that. (And send the patches to me.) If you plan on
+using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also
+have to build Python and any other extension modules that you use with
+that compiler because a different version of the C runtime likbrary is
+used. The Python executable that comes from PythonLabs and the
+wxPython extensions that I distribute are built with MSVC 6 with all
+the Service Packs applied.</p>
+<p>If you want to build a debugable version of wxWindows and wxPython you
+will need to have also built a debug version of Python and any other
+extension modules you need to use. You can tell if you have them
+already if there is a _d in the file names, for example python_d.exe
+or python23_d.dll. If you don't need to trace through the C/C++ parts
+of the code with the debugger then building the normal (or hybrid)
+version is fine, and you can use the regular python executables with
+it.</p>
+<p>Just like the unix versions I also use some scripts to help me build
+wxWindows, but I use some non-standard stuff to do it. So if you want
+to use them too you'll need to get a copy or 4DOS or 4NT from
+<a class="reference" href="http://www.jpsoft.com/">http://www.jpsoft.com/</a> and also a copy of unix-like cat and sed
+programs. You can also do by hand what my scripts are doing, but
+there are a lof steps involved and I won't be going into details
+here. There is a copy of my build scripts in wxWindowswxPythondistribmsw</p>
+<ol class="arabic">
+<li><p class="first">Set an environment variable to the root of the wxWindows source
+tree:</p>
+<pre class="literal-block">
+set WXWIN=e:\projects\wxWindows
+</pre>
+</li>
+<li><p class="first">Copy setup0.h to setup.h</p>
+<blockquote>
+<p>cd %WXWIN%includewxmsw
+copy setup0.h setup.h</p>
+</blockquote>
+</li>
+<li><p class="first">Edit %WXWIN%includewxmswsetup.h and change a few settings.
+Some of them are changed by my build scripts depending on the type
+of build (debug/hybrid, unicode/ansi). I change a few of the other
+defaults to have these values:</p>
+<pre class="literal-block">
+wxDIALOG_UNIT_COMPATIBILITY 0
+wxUSE_DEBUG_CONTEXT 1
+wxUSE_MEMORY_TRACING 1
+wxUSE_DIALUP_MANAGER 0
+wxUSE_GLCANVAS 1
+wxUSE_POSTSCRIPT 1
+wxUSE_AFM_FOR_POSTSCRIPT 0
+</pre>
+</li>
+<li><p class="first">Make a %WXWIN%BIN directory and add it to the PATH. My build
+scripts will copy the wxWindows DLLs there.</p>
+</li>
+<li><p class="first">Change to the %WXWIN%buildmsw directory and copy my build scripts
+there.</p>
+</li>
+<li><p class="first">Use the .make.btm command to build wxWindows. It needs one
+command-line parameter which controls what kind of build(s) to do.
+Use one of the following:</p>
+<pre class="literal-block">
+debug Build debug version
+hybrid Build hybrid version
+both Both debug and hybrid
+debug-uni Build a debug unicode library
+hybrid-uni Hybrid unicode (see the pattern yet? ;-)
+both-uni and finally both unicode libraries
+</pre>
+<p>For example:</p>
+<pre class="literal-block">
+ .make hybrid
+
+You can also pass additional command line parameters as needed and
+they will all be passed on to the nmake commands, for example to
+clean up the build::
+
+ .make hybrid clean
+</pre>
+</li>
+<li><p class="first">When that is done it will have built the main wxWindows DLLs and
+also some of the contribs DLLs. There should be a ton of DLLs in
+%WXDIR%bin and lots of lib files and other stuff in
+%WXDIR%libvc_dll.</p>
+</li>
+<li><p class="first">Building wxPython on Windows is very similar to doing it for the
+unix systems. We're not going to install the development version
+of wxPython with these commands, so it won't impact your already
+installed version of the latest release. You'll be able to test
+with this version when you want to, and use the installed release
+version the rest of the time. If you ever do want to install the
+development verison please refer to INSTALL.txt.</p>
+<p>Change to the wxWindowswxPython dir and run the this command,
+makeing sure that you use the version of python that you want to
+build for (if you have more than one on your system):</p>
+<pre class="literal-block">
+cd %WXWIN%\wxPython
+python setup.py build_ext --inplace
+</pre>
+<p>If you are wanting to have the source files regenerated with swig,
+then you need to turn on the USE_SWIG flag and optionally tell it
+where to find the new swig executable, so add these flags:</p>
+<pre class="literal-block">
+USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe
+</pre>
+<p>If you built a Unicode version of wxWindows and want to also build
+the Unicode version of wxPython then add this flag:</p>
+<pre class="literal-block">
+UNICODE=1
+</pre>
+<p>If you have a debug version of Python and wxWindows and want to
+build a debug version of wxPython too, add the --debug flag to the
+command line. You should then end up with a set of <tt class="literal"><span class="pre">*_d.pyd</span></tt>
+files in the wx package and you'll have to run <tt class="literal"><span class="pre">python_d.exe</span></tt> to
+use them. The debug and hybrid(release) versions can coexist.</p>
+<p>When the setup.py command is done you should have fully populated
+wxPython and wx packages locally in wxWindows/wxPython/wxPython and
+wxWindows/wxPython/wx, with all the extension modules (<tt class="literal"><span class="pre">*.pyd</span></tt>
+files) located in the wx package.</p>
+</li>
+<li><p class="first">To run code with the development verison of wxPython, just set the
+PYTHONPATH to the wxPython dir in the CVS tree. For example:</p>
+<pre class="literal-block">
+set PYTHONPATH=e:\projects\wxWindows\wxPython
+cd e:\projects\wxWindows\wxPython
+python demo.py
+</pre>
+</li>
+</ol>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
between this and the release version that you may already have
installed.
-If you want to make changes to any of the *.i files, (SWIG interface
+If you want to make changes to any of the ``*.i`` files, (SWIG interface
definition files,) or to regenerate the extension sources or renamer
modules, then you will need an up to date version of SWIG. Either get
and build the current CVS version, or version 1.3.20, and then apply
command but there are other libraries besides the main wxWindows
libs that also need to be built so again I make a script to do it
all for me so I don't forget anything. This time it is called
- ".make" (I use the leading ". so when I do "rm -r *" in my build
+ ".make" (I use the leading ". so when I do ``rm -r *`` in my build
dir I don't lose my scripts too.) This is what it looks like::
make $* \
When the setup.py command is done you should have fully populated
wxPython and wx packages locally in wxWindows/wxPython/wxPython and
- .../wx, with all the extension modules (*.so files) located in the
+ .../wx, with all the extension modules (``*.so`` files) located in the
wx package.
If you have a debug version of Python and wxWindows and want to
build a debug version of wxPython too, add the --debug flag to the
- command line. You should then end up with a set of *_d.pyd files
- in the wx package and you'll have to run python_d.exe to use them.
- The debug and hybrid(release) versions can coexist.
+ command line. You should then end up with a set of ``*_d.pyd``
+ files in the wx package and you'll have to run ``python_d.exe`` to
+ use them. The debug and hybrid(release) versions can coexist.
When the setup.py command is done you should have fully populated
wxPython and wx packages locally in wxWindows/wxPython/wxPython and
- wxWindows/wxPython/wx, with all the extension modules (*.pyd files)
- located in the wx package.
+ wxWindows/wxPython/wx, with all the extension modules (``*.pyd``
+ files) located in the wx package.
9. To run code with the development verison of wxPython, just set the
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>CHANGES.txt for wxPython</title>
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="changes-txt-for-wxpython">
+<h1 class="title">CHANGES.txt for wxPython</h1>
+<div class="section" id="x">
+<h1><a name="x">2.5.1.x</a></h1>
+<p>(See also the MigrationGuide.txt file for details about some of the
+big changes that have happened in this release and how you should
+adapt your code.)</p>
+<p>Many, many little fixes, changes and additions done as part of the move
+to wxWindows 2.5 that I have forgotten about.</p>
+<p>Added wxMirrorDC.</p>
+<p>Added wxIconLocation</p>
+<p>Added Python wrappers for the new wxVScrolledWindow, wxVListBox, and
+wxHtmlListBox classes.</p>
+<p>Added wrappers for wxBookCtrl and wxListbook. wxNotebook now derives
+from wxBookCtrl.</p>
+<p>Added Gordon Williams' PyPlot module to the library, available as the
+wx.lib.plot module.</p>
+<p>I made a small but important change in the code that aquires the
+Python Global Interpreter Lock to try and prevent deadlocks that can
+happen when there are nested attempts to aquire the GIL.</p>
+<p>The RPMs will now install menu items on Mandrake in
+Applications/Development/Tools for PyCrust, XRCed, etc. They are also
+installing icons and <tt class="literal"><span class="pre">*.desktop</span></tt> items in the generic KDE and GNOME
+locations, but I don't know yet if they are resulting in menu items on
+non-Mandrake systems. (It didn't automatically do it on my RH-9 build
+box but I didn't chase it very far...) If you have ideas for how to
+improve the .spec file to work better and/or on more distros please
+send me a patch.</p>
+<p>The RPMs are now built on a RH-9 box, and I have tested installing
+them also on my main Mandrake 9.2 box.</p>
+<p>There are some big changes in the OS X disk image. The actual
+Installer package now <em>only</em> installs the wxMac dynlibs, wxPython
+extension modules and pacakges, and also the command-line tool
+scripts. The remaining items (demo, samples, and application bundles
+for the Demo, PyCrust and XRCed) are now top-level items in the disk
+image (.dmg file) that users can just drag and drop to wherever they
+want to put them.</p>
+<p>The wxWave class has been renamed to wxSound, and now has a slightly
+different API.</p>
+</div>
+<div class="section" id="id1">
+<h1><a name="id1">2.4.2.4</a></h1>
+<p>Use wxSTC in the demo for displaying the soucre code of the samples.</p>
+<p>Lots of bug fixes and such from the wxWindows folks.</p>
+<p>Added wxPython.lib.newevent from Miki Tebeka. Its usage is
+demonstrated in the Threads sample in the demo.</p>
+<p>Updates to wxMaskedEditCtrl.</p>
+<p>Added wxMaskedNumCtrl.</p>
+<p>Added Chris Barker's FloatCanvas.</p>
+</div>
+<div class="section" id="id2">
+<h1><a name="id2">2.4.1.2</a></h1>
+<p>Added wxScrolledPanel from Will Sadkin</p>
+<p>Added SetShape method to top level windows (e.g. wxFrame.)</p>
+<p>Changed wxSWIG to not generate Python code using apply, (since it will
+be deprecated in the future) wxSWIG will use <tt class="literal"><span class="pre">spam(*args,</span> <span class="pre">**kw)</span></tt> syntax
+instead. Also changed the generated __repr__ methods to be a bit more
+informative.</p>
+<p>Made the version number information more robust and uh, informative.
+Also added asserts to check that the major.minor versions of wxPython
+and wxWindows match.</p>
+<p>Added the new wx "renamer" package that will dynamically import from
+the wxPython package and rename wxFooBar --> FooBar. That means that
+people can do imports without <tt class="literal"><span class="pre">"import</span> <span class="pre">*"</span></tt> and can use names like
+wx.Frame instead of wx.wxFrame. This is phase 1 of a full transition
+to the new namespace.</p>
+<p>Updated Scintilla to 1.52. I also changed it to use wxListCtrl
+instead of wxListBox for the AutoComplete window, added the ability to
+use custom bitmaps in the margin and in the AutoComplete windows, and
+worked out how to do proper clipping of child windows on wxGTK.</p>
+<p>Patrick O'Brien's PyCrust package has been renamed to Py and now
+includes several new tools. As part of the change the location of the
+pacakge has changed as well, it is now accessible as "from wxPython
+import py" (or "from wx import py" using the new namespace.) There
+are still some transition modules in the wxPython.lib.PyCrust package
+that will issue a warning and then import what is needed from the new
+package. These will be removed in a future release.</p>
+<p>Added __nonzero__ method to wxTreeItemId, wxBitmap, wxImage, wxFont,
+and most other classes that have an Ok or IsOK method. This allows
+code like "if obj: ..." to be the same as "if obj.IsOk(): ..."</p>
+<p>Toolbars on wxMac can now have controls on them.</p>
+<p>Added wxPython.lib.analogclock module based on samples that were
+passed back and forth on wxPython-users a while back.</p>
+<p>Added masked edit controls (wxPython.lib.maskededit) by Jeff Childers
+and Will Sadkin. Updated wxTimeCtrl to use MaskedEdit.</p>
+<p>When the __class__ of a dead object is replaced with _wxPyDeadObject
+the __del__ of the original class is now called first.</p>
+<p>Added wxTreeListCtrl. (Looks like a wxTreeCtrl embedded in a
+wxListCtrl, but actually is just giving multiple columns to a
+wxTreeCtrl.)</p>
+<p>Added wxFutureCall, a subclass of wxTimer that makes it easy to delay
+a call to any Python callable object.</p>
+<p>Added wxPy versions of wxPrintPreview, wxPreviewFrame, and
+wxPreviewControlBar so they can be derived from in Python and be able
+to override the C++ virtual methods.</p>
+<p>Simplified how the wxSizer methods are wrapped, changed the name of
+the "option" parameter to "proportion" to match the docs ("option" is
+still accepted for compatibility, but this will go away in a future
+release,) SetItemMinSize can now take a wxSize (or 2-tuple) parameter,
+and Spacers can be specified with a wxSize (or 2-tuple) parameter</p>
+<p>Added wxCursorFromBits.</p>
+</div>
+<div class="section" id="id3">
+<h1><a name="id3">2.4.0.7</a></h1>
+<p>Gave up on generating a warning upon the use of the old true/false or
+TRUE/FALSE values.</p>
+<p>Fixed wxGenericTreeCtrl (used on wxGTK and wxMac for wxTreeCtrl) so
+that it can successfully handle lots of nodes instead of overflowing
+when the virtual height of the widget overflowed a 16-bit value.</p>
+<p>Fixed the typemap that converts strings to wxColours to also accept
+unicode.</p>
+<p>Fixed problem where the wrong class name could sometimes be used for
+OOR.</p>
+<p>Fixed an interpreter lock problem in the __eq__ and __ne__ methods in
+wxSize and etc.</p>
+<p>Updated PyCrust to version 0.9</p>
+<p>Instead of always logging C++ assertions, added wxPYAPP_ASSERT_LOG
+flag to turn it on. In most cases turning it into an exception (the
+default behavior) is enough. See below in the 2.3.4.1 notes for more
+details.</p>
+</div>
+<div class="section" id="a-k-a-the-i-m-so-stupid-release">
+<h1><a name="a-k-a-the-i-m-so-stupid-release">2.4.0.6 (a.k.a. the I'm so stupid release)</a></h1>
+<p>The new deprecation class for the old true/false symbols can now be
+returned from OnInit. And I promise to be sure I am testing what I
+think I am testing in the future...</p>
+</div>
+<div class="section" id="a-k-a-the-blame-it-on-kevin-release">
+<h1><a name="a-k-a-the-blame-it-on-kevin-release">2.4.0.5 (a.k.a. the blame it on Kevin release)</a></h1>
+<p>A few little but annoying bug fixes.</p>
+<p>Updated pycolourchooser.</p>
+<p>Updated to 0.9b of PyCrust.</p>
+</div>
+<div class="section" id="id4">
+<h1><a name="id4">2.4.0.4</a></h1>
+<p>Added missing wxRect methods</p>
+<p>Add OOR support for wxApp objects too.</p>
+<p>Added wxCursorFromImage, which works on wxMSW and wxGTK so far.</p>
+<p>All platforms now send EVT_DESTROY_WINDOW. Be warned that at the time
+the event is sent the window is in the process of being deconstructed,
+and so calling some (most?) methods of the window itself may cause
+problems.</p>
+<p>Fixed SF Bug #689481, a method in the OGL wrappers was using the wrong
+return type.</p>
+<p>Fixed SF Bug #689958, an endless loop in printout.py.</p>
+<p>Added EVT_WINDOW_CREATE_ID and EVT_WINDOW_DESTROY_ID so these events
+can be associated with a specific window ID and more easily caught by
+the parent window.</p>
+<p>Fixed copy-paste error in wxListCtrl.GetFirstSelected.</p>
+<p>Added missing Init method (and an overloading wrapper) to wxLocale
+wrapper.</p>
+<p>Added a wxBitmap.SetMaskColour convenience method.</p>
+<p>Changed how the dynamic event tables (used for all Python wx classes,
+C++ wx classes typically use static event tables) are searched such
+that they behave from a Python perspective more like the static tables
+in C++. Namely that if there are identical event bindings in a base
+Python class and a derived Python class that the one in the derived
+class will be found first and that if Skip is called that the one in
+the base class will still be found instead of skipping directly to the
+static stable in the C++ class.</p>
+<p>Switched to using True/False in the wxPython lib and demo instead of
+true/false or TRUE/FALSE to prepare for the new boolean type and
+constants being added to Python. Added code to wx.py to test for the
+existence of the new constants and to create suitable values if not
+present.</p>
+<p>Added some static wxApp functions that help with integration with the
+Mac UI. They are no-ops on other platforms so it doesn't hurt to
+always call them. The functions are:</p>
+<blockquote>
+wxApp_GetMacDefaultEncodingIsPC
+wxApp_GetMacSupportPCMenuShortcuts
+wxApp_GetMacAboutMenuItemId
+wxApp_GetMacPreferencesMenuItemId
+wxApp_GetMacExitMenuItemId
+wxApp_GetMacHelpMenuTitleName
+wxApp_SetMacDefaultEncodingIsPC
+wxApp_SetMacSupportPCMenuShortcuts
+wxApp_SetMacAboutMenuItemId
+wxApp_SetMacPreferencesMenuItemId
+wxApp_SetMacExitMenuItemId
+wxApp_SetMacHelpMenuTitleName</blockquote>
+<p>Refactored, enhanced and added capabilities for the DrawXXXList
+functions, inspired by code from Chris Barker.</p>
+<p>The wxWindows .mo language catalog files are now installed in a
+subdirectory of the wxPython package dir on MSW since that platform
+doesn't have a standard place for them.</p>
+<p>Added missing deselect methods for wxGrid.</p>
+<p>Fixed typemaps for wxGridCellCoordsArray.</p>
+<p>Updated to the 0.9a version of PyCrust</p>
+</div>
+<div class="section" id="id5">
+<h1><a name="id5">2.4.0.2</a></h1>
+<p>Several bug fixes.</p>
+<p>Added wxIntCtrl from Will Sadkin.</p>
+<p>Added wxPyColourChooser by Michael Gilfix.</p>
+</div>
+<div class="section" id="id6">
+<h1><a name="id6">2.4.0.1</a></h1>
+<p>No major new features since 2.3.4.2, mostly bug fixes and minor
+enhancements.</p>
+<p>Added function wrappers for the common dialogs from Kevin Altis. See
+wxPython/lib/dialogs.py for more details.</p>
+</div>
+<div class="section" id="id7">
+<h1><a name="id7">2.3.4.2</a></h1>
+<p>Various bug fixes.</p>
+</div>
+<div class="section" id="id8">
+<h1><a name="id8">2.3.4.1</a></h1>
+<p>Updated XRCed and wxTimeCtrl contribs.</p>
+<p>Show a couple new wxGrid features in the demo.</p>
+<p>Several bug fixes in wxWindows.</p>
+<p>Added wxHtmlFilter.</p>
+<p>wxASSERT and related C++ runtime diagnostics are now converted to
+Python exceptions. When an assert happens a wxPyAssertionError
+(which derives from AssertionError) exception is created and when
+control returns back to the Python code that invoked the C++ API it
+will be raised. The same exception restrictions are in place as
+before, namely that exceptions can't cross from one Python layer
+through C++ to another Python layer. That simply means that if you
+want to catch wxPyAssertionError or any other exception that you need
+to do it before control returns to C++ at the end of your event
+handler or callback code. There is some test code in demo/wxButton.py
+you can use to play with this new feature.</p>
+<p>Added some methods to wxApp (SetAssertMode and GetAssertMode) that let
+you control how C++ assertions are processed. Valid modes are:
+wxPYAPP_ASSERT_SUPPRESS, wxPYAPP_ASSERT_EXCEPTION, and
+wxPYAPP_ASSERT_DIALOG. Using _SUPPRESS will give you behavior like
+the old "final" builds and the assert will be ignored, _EXCEPTION is
+the new default described above, and _DIALOG is like the default in
+2.3.3.1 and prior "hybrid" builds. You can also combine _EXCEPTION
+and _DIALOG if you wish, although I don't know why you would.</p>
+<p>You can now overload OnInitGui, OnExit and OnAssert in your classes
+derived from wxApp.</p>
+<p>Added GetSelectedCells, GetSelectionBlockTopLeft,
+GetSelectionBlockBottomRight, GetSelectedRows, GetSelectedCols nethods
+to wxGrid.</p>
+<p>Added Python == and != operators for some basic classes</p>
+<p>Fixed the Python wrappers for wxInputStream so they no longer block
+when reading from a wxProcess on wxGTK. They now work more or less as
+they did before 2.3.3.1 but the dual meaning of eof() has been
+removed. There is now a CanRead() method that lets you know if there
+is data waiting to be read from the pipe.</p>
+<p>Fixed method name clash in wxIEHtmlWin, renamed Refresh to RefreshPage.</p>
+<p>Added Throbber from Cliff Wells to the library and the demo.</p>
+<p>Windows installer prompts to uninstall old version first.</p>
+<p>Added wxPython.lib.evtmgr by Robb Shecter, which is an easier, more
+"Pythonic" and more OO method of registering handlers for wxWindows
+events using the Publish/Subscribe pattern.</p>
+<p>Added wxPython.lib.popupctl by Gerrit van Dyk which is a combobox-like
+gizmo for poping up arbitrary controls. It is currently using
+wxDialog because of some issues with wxPopupWindow...</p>
+<p>Added wxPython.lib.gridmovers by Gerrit van Dyk which facilitates the
+dragging of columns and/or rows in a wxGrid.</p>
+<p>Added wxPython.lib.multisash by Gerrit van Dyk which is a nice
+implementation of allowing the user to split a window any number of
+times either horizontally or vertically, and to close the split off
+windows when desired.</p>
+<p>Added helpviewer tool that displays HTML books similarly to how MS
+HTMLHelp viewer does. Changed how the wxPythonDocs tarball is built
+and added a script to launch the doc viewer.</p>
+</div>
+<div class="section" id="id9">
+<h1><a name="id9">2.3.3.1</a></h1>
+<p>Added wxSplashScreen.</p>
+<p>Added wxGenericDirCtrl.</p>
+<p>Added wxMultiChoiceDialog.</p>
+<p>The calltip window and autocomplete window in wxSTC will now use a
+wxPopupWindow if available on the platform (and functioning correctly)
+so they can extend beyond the client area of the STC if needed.</p>
+<p>Finished wrapping and providing typemaps for wxInputStream and also
+added the stream ctor and other methods for wxImage so images can now
+be loaded from any Python "file-like" object.</p>
+<p>Changed the img2py tool to use PNG instead of XPM for embedding image
+data in Python source code, and the generated code now uses streams to
+convert the image data to wxImage, wxBitmap, or wxIcon.</p>
+<p>Added the wxPython.lib.rcsizer module which contains RowColSizer.
+This sizer is based on code from Niki Spahiev and lets you specify a
+row and column for each item, as well as optional column or row
+spanning. Cells with no item assigned to it are just left blank.
+Stretchable rows or columns are specified and work the same as in
+wxFlexGridSizer.</p>
+<p>Updated XRCed from Roman Rolinsky</p>
+<p>Added wxBufferedDC.</p>
+<p>Upgraded wxSTC from Scintilla 1.40 to Scintilla 1.45, and then again
+to version 1.47, and one more time to 1.48! <wink></p>
+<dl>
+<dt>UNICODE!</dt>
+<dd><p class="first">wxWindows/wxPython can be compiled with unicode support enabled or
+disabled. Previous to wxPython 2.3.3 non-unicode mode was always
+used. Starting with 2.3.3 either mode is supported, but only if
+it is also available in wxWindows on the platform. Currently
+wxWindows only supports unicode on MS Windows platforms, but with
+the recent release of GTK+ 2.0 it is only a matter of time until
+it can be done on wxGTK (Linux and other unixes) as well.</p>
+<p>Unicode works best on platforms in the NT branch of the Windows
+family tree (NT, win2k, XP) but it is now also possible to use the
+same unicode binaries on win95/98/ME platforms as well! This is
+done by using a special library and DLL with the application
+called MSLU, (Microsoft Layer for Unicode). It simply gets out of
+the way if the app is run on an NT box, otherwise if run on a
+win9x box it loads a special DLL that provides the unicode
+versions of the windows API. So far I have not been able to get
+this to work perfectly on win9x. Most things work fine but
+wxTaskBarIcon for example will cause a crash if used with the
+unicode build on win95.</p>
+<p class="last">So how do you use it? It's very simple. When unicode is enabled,
+then all functions and methods in wxPython that return a wxString
+from the C++ function will return a Python unicode object, and
+parameters to C++ functions/methods that expect a wxString can
+accept either a Python string or unicode object. If a string
+object is passed then it will be decoded into unicode using the
+converter pointed to by wxConvCurrent, which will use the default
+system encoding. If you need to use a string in some other
+encoding then you should convert it to unicode using the Python
+codecs first and then pass the unicode string to the wxPython
+method.</p>
+</dd>
+</dl>
+<p>Added wxListCtrlAutoWidthMixin from Erik Westra.</p>
+<p>Added wxIconBundle and wxTopLevelWindow.SetIcons.</p>
+<p>Added wxLocale and wxEncodingConverter.</p>
+<p>A little black magic... When the C++ object (for a window or
+whatever) is deleted there is no way to force the Python shadow object
+to also be destroyed and clean up all references to it. This leads to
+crashes if the shadow object tries to call a method with the old C++
+pointer. The black magic I've done is to replace the __class__ in the
+Python instance object with a class that raises an exception whenever
+a method call (or other attribute access) is attempted. This works
+for any class that is OOR aware.</p>
+<p>Added OOR support for wxGridCellRenderer, wxGridCellEditor,
+wxGridCellAttr, wxGridCellAttrProvider, wxGridTableBase and their
+derived classes.</p>
+<p>Added wxImage.GetDataBuffer which returns an in-place edit buffer of
+the image data. (Patch #546009)</p>
+<p>Added a sample that shows how to embed wxPython in a wxWindows C++
+application.</p>
+<p>Added wxPyWindow, wxPyPanel and wxPyControl which are just like their
+wx counterparts except they allow some of the more common C++ virtual
+methods to be overridden in Python derived classes. The methods
+supported are:</p>
+<blockquote>
+<p>DoMoveWindow
+DoSetSize
+DoSetClientSize
+DoSetVirtualSize
+DoGetSize
+DoGetClientSize
+DoGetPosition
+DoGetVirtualSize
+DoGetBestSize
+InitDialog
+TransferDataFromWindow
+TransferDataToWindow
+Validate
+AcceptsFocus
+AcceptsFocusFromKeyboard
+GetMaxSize
+AddChild
+RemoveChild</p>
+<p>If there are other methods that you think should be supported
+please let me know.</p>
+</blockquote>
+<p>Changed wxGenButton to derive from wxPyControl and overload
+DoGetBestSize and AcceptsFocus.</p>
+<p>Added wxArtProvider.</p>
+<p>Added wxCallAfter which is a helper function that registers a function
+(or any callable Python object) to be called once the next time there
+are no pending events. This is useful for when you need to do
+something but it can't be done during the current event handler. The
+implementation is very simple, see wxPython/wx.py.</p>
+<p>Fixed a boatload of reference leaks.</p>
+<p>Added a demo of using a sizer in a wxScrolledWindow, in effect
+creating a ScrolledPanel.</p>
+<p>Added a sample to the demo that shows how to use radio menu items, and
+other menu stuff.</p>
+<p>Added wxIEHtmlWin. This is essentially the same as using IE with the
+ActiveXWrapper already in the library, but it is implemented all in
+C++ and therefore does not need any of the modules from win32all and
+so it is less fragile in the face of changes.</p>
+<p>Fixed the ActiveXWrapper problem. Looks like when the win32com
+modules make a "callback" that they (incorrectly, IMHO) allocate a
+transient thread state structure. Since wxPython is now saving
+tstates for it's own callbacks it ended up using garbage after
+win32com got rid of the temporary tstate...</p>
+<p>Added a generic static text control to wxPython.lib.stattext. This is
+so things like Boa and PythonCard can have a static text that can
+respond to mouse events and etc.</p>
+<p>Changed the wxDateTime.Parse* methods to return an int that will be -1
+on failure, and the index where parsing stopped otherwise.</p>
+<p>Moved tools to be a Python package in wxPython.tools, added scripts to
+import and launch each tool. This will let you import and use the
+tools in your own scripts or apps as needed. On Linux and OS X the
+tool scripts are installed to {prefix}/bin so you should be able to
+easily launch them from the command line. For example, PyCrust can be
+started with just the "pycrust" command.</p>
+<p>Added a sample to the demo that catches various key events and
+displays the details of the event.</p>
+<p>Added wxWizard, wxWizardPage, wxWizardPageSimple and wxPyWizardPage.</p>
+<p>Added wxXmlResourceHandler which allows you to create custom handlers
+for nonstandard class types in XRC resources. See the demo for an
+example.</p>
+<p>Added wxPython.lib.mixins.rubberband module from Robb Shecter.</p>
+<p>Added wxTimeCtrl from Will Sadkin.</p>
+</div>
+<div class="section" id="id10">
+<h1><a name="id10">2.3.2.1</a></h1>
+<p>Changed (again) how the Python global interpreter lock is handled as
+well as the Python thread state. This time it works on SMP machines
+without barfing and is also still compatible with Python debuggers.</p>
+<p>Added some patches from library contributors.</p>
+</div>
+<div class="section" id="id11">
+<h1><a name="id11">2.3.2</a></h1>
+<p>Added EVT_HELP, EVT_HELP_RANGE, EVT_DETAILED_HELP,
+EVT_DETAILED_HELP_RANGE, EVT_CONTEXT_MENU, wxHelpEvent,
+wxContextMenuEvent, wxContextHelp, wxContextHelpButton, wxTipWindow,
+and a demo to show them in action.</p>
+<p>Deprecated PyShell and PyShellWindow, added a snapshot of PyCrust (see
+<a class="reference" href="http://sourceforge.net/projects/pycrust/">http://sourceforge.net/projects/pycrust/</a>. )</p>
+<p>Added the new virtual list capabilities to wxListCtrl.</p>
+<p>Added a wxSTC style editor from Riaan Booysen to the sample apps.</p>
+<p>Added XRCed to the wxPython Tools directory, contributed by Roman
+Rolinsky.</p>
+<p>Added a new "constructor" to most of the window classes that calls the
+default C++ constructor, (the one with no parameters) and also added the
+corresponding Create(...) method. This allows you to do a 2-step
+creation of windows which is sometimes required for doing things such
+as setting extended style flags before the window is created, or for
+passing the object to the XRC resource system to be created from the
+resource. The name of the new "constructor" is the original name of
+the class with a "Pre" in it. For example, wxPreWindow, wxPreFrame,
+etc.</p>
+<p>Updated to version 1.40 of Scintilla and updated wxStyledTextCtrl
+accordingly. While doing this update I dropped the wxLB_SORT style
+from the wxListBox created for the AutoComplete functionality. This
+means that you will have to sort the keyword lists yourself, but you
+are free to do case sensitive or case insensitive sorts and set the
+wxSTC flag accordingly.</p>
+<p>Updated wxColumnSorterMixin to also be able to place sort icons on the
+column headers, and updated the wxListCtrl demo to show it off by
+using wxColumnSorterMixin.</p>
+<p>Added wxGenBitmapTextButton, TablePrint, etc. contribs from Lorne White.</p>
+<p>Added wxNativeFontInfo and wxFontMapper.</p>
+<p>Added pySketch to the samples.</p>
+<p>Significantly changed how the Python interpreter lock and thread state
+are managed, which should fix the problem of running on a
+multi-processor machine.</p>
+<p>Added wxPyLog so log targets can be created in Python to handle log
+messages however is wished. See demo/Main.py for an example.</p>
+<p>Added wxFindReplaceDialog.</p>
+<p>The second phase of OOR is implemented for wxEvtHandler, wxSizer,
+wxShape and derived classes. This means that functions and methods
+that return an object derived from wxEvtHandler that was originally
+created in Python, will return the original Python object (if it still
+exists) instead of letting SWIG wrap a new shadow object around the
+original C++ pointer.</p>
+<p>Added some optimization methods to wxDC: GetBoundingBox, DrawLineList,
+DrawPointList.</p>
+<p>Added a set of sophisticated Error Dialogs from Chris Fama.</p>
+<p>Added wxRightTextCtrl from Josu Oyanguren to wxPython.lib for aligning
+text in a wxTextCtrl to the right side.</p>
+<p>Added wxURLDataObject and an example showing drag and drop of URLs to
+and from web browsers. It's still not 100% bullet-proof for all types
+of browsers, but it works for the majority of cases with the popular
+browsers on Windows. On wxGTK it seems that only Netscape 4.x works,
+if anybody has any suggestions about this please bring it up on the
+wx-dev list.</p>
+<p>Added wxStopWatch.</p>
+<p>Added wxMimeTypesManager and wxFileType.</p>
+<p>Passing None for the handler parameter to one of the EVT_** functions
+will now Disconnect the event.</p>
+<p>Added wxPopupWindow and wxPopupTransientWindow.</p>
+<p>Added wxFileHistory.</p>
+<p>Added wxDynamicSashWindow, which allows you to endlessly split windows
+by dragging a little tab next to the scrollbars. Added a demo to show
+this and also the ability of multiple wxStyledTextCtrls to share the
+same document.</p>
+<p>Added wxEditableListBox gizmo.</p>
+<p>Updated wxEditor with lots of enhancements from Steve Howell and Adam
+Feuer.</p>
+<p>Added the "SplitTree gizmos" which are a collection of classes that
+were designed to operate together and provide a tree control with
+additional columns for each item. The classes are
+wxRemotelyScrolledTreeCtrl, wxTreeCompanionWindow,
+wxThinSplitterWindow, and wxSplitterScrolledWindow, some of which may
+also be useful by themselves.</p>
+<p>Added wxDllWidget from Vaclav Slavik which allows wx widgets derived
+from wxWindow to be loaded from a C++ .dll (or .so) and be used in a
+wxPython program, without the widget having to be SWIGged first. The
+visible API of the widget is limited to wxWindow methods plus a
+SendCommand method, but it is still quite powerful. See
+wxPython/contrib/dllwidget and wxPython/demo/dllwidget for more
+details.</p>
+</div>
+<div class="section" id="id12">
+<h1><a name="id12">2.3.1</a></h1>
+<p>Added EVT_GRID_EDITOR_CREATED and wxGridEditorCreatedEvent so the user
+code can get access to the edit control when it is created, (to push
+on a custom event handler for example.)</p>
+<p>Added wxTextAttr class and SetStyle, SetDefaultStyle and
+GetDefaultStyle methods to wxTextCtrl.</p>
+<p>Added ability to use xml resource files. Still need to add ability to
+subclass wxXmlResourceHandler, etc...</p>
+<p>Added wxGridAutoEditMixin to the mixins library package.</p>
+<p>Made ColourSelect be derived from wxButton.</p>
+<p>Fixed img2py to work correctly with Python 2.1.</p>
+<p>Added enhanced wxVTKRenderWindow by Prabhu Ramachandran</p>
+</div>
+<div class="section" id="id13">
+<h1><a name="id13">2.3.0</a></h1>
+<p>Removed initial startup dependency on the OpenGL DLLs so only the
+glcanvasc.pyd depends on them, (on wxMSW.)</p>
+<p>Changed wxFont, wxPen, wxBrush to not implicitly use the
+wxThe[Font|Pen|Brush]List objects behind the scenes, but to use normal
+ctor and dtors.</p>
+<p>Exposed the wxThe[Font|Pen|Brush]List to wxPython.</p>
+<p>Also added wxTheColourDatabase and added a library module (in the
+wxPython.lib.colourdb module) to load LOTS more colour names into the
+colour database.</p>
+<p>Added wxWakeUpMainThread, wxMutexGuiEnter, wxMutexGuiLeave,
+wxMutexGuiLocker and wxThread_IsMain to assist with dealing with GUI
+access from non-GUI threads.</p>
+<p>wxPyOnDemandOutputWindow is now (more) thread safe if non-GUI threads
+use print, sys.stdout.write, etc.</p>
+<p>Added CreateTextSizer and CreateButtonSizer to wxDialog</p>
+<p>Added wxPython/lib/infoframe.py from Chris Fama. It contains a class
+that can be used in place of wxPyOnDemandOutputWindow.</p>
+<p>Added colourselect.py, imagebrowser.py and an updated calendar.py to
+wxPython/lib from Lorne White.</p>
+<p>Added patch to wxPoint_LIST_helper from Tim Hochberg that should make
+it gobs faster in certain situations.</p>
+<p>Added tools that will take an image file in a wx supported format and
+convert it to data embedded in a Python source file. The image is
+converted to XPM format which is essentially a list of strings
+containing info about each pixel. The image's transparency mask is
+included, if there is one, or a mask can be added if a mask colour is
+specified on the command line. It is then pickled and optionally
+compressed and written to a Python source file along with functions to
+convert it to either a wxBitmap or a wxImage. See
+wxPython/demo/images.py for examples, and wxPython/Tools/img2py.py for
+the implementation.</p>
+<p>Fixed wxStyledTextCtrl to be much faster on wxGTK. There was some
+experimental code that got left in place that ended up causing way too
+many refreshes.</p>
+<p>A couple more hacks in my_distutils.py so wxPython can be built with
+the distutils that comes with Python 2.1.</p>
+<p>Added a ton of missing methods for wxPrintData.</p>
+<p>Switched to InnoSetup for MSW distributions.</p>
+<p>Added wxToggleButton.</p>
+<p>Fixed bug that prevented wxTreeCtrl.OnCompareItems from being called.</p>
+<dl>
+<dt>Added some methods to wxGrid:</dt>
+<dd>GetCellHighlightPenWidth
+GetCellHighlightROPenWidth
+SetCellHighlightPenWidth
+SetCellHighlightROPenWidth
+GetGridWindow
+GetGridRowLabelWindow
+GetGridColLabelWindow
+GetGridCornerLabelWindow</dd>
+</dl>
+<p>Added wxGetClientDisplayRect which on wxMSW returns a wxRect
+representing the area on screen not occupied by the taskbar and such.
+On other platforms it is equivallent to wxGetDisplaySize.</p>
+<dl>
+<dt>OOR:</dt>
+<dd><p class="first">Implemented the first phase of OOR (Original Object Return). See
+the text in the demo for more details of what this means, but in a
+nutshell methods such as wxWindow.GetParent or FindWindowById will
+now return a shadow object of the proper type if it can. By
+"proper type" I mean that if the wxWindow pointer returned from
+FindWindowById really points to a wxButton then the Python object
+constructed will be of a wxButtonPtr class instead of wxWindowPtr
+as before. This should reduce or eliminiate the need for
+wxPyTypeCast. (Woo Hoo!) The objects returned are still not the
+original Python object, but that is the next step. (Although it
+will probably only work on Python 2.1 and beyond because it will
+use weak references.)</p>
+<p class="last">This first phase of the OOR plan is fairly significant and has
+required a lot of changes all over wxPython, most of which should
+be transparent to you, however I'm not 100% sure that it didn't
+introduce any new bugs that are hiding somewhere and didn't get
+stomped on during my testing. So please be sure to test everything
+thoroughly when you install this version and be sure to report any
+object-type related oddities to me.</p>
+</dd>
+</dl>
+<p>There is now a wxObject class that most other classes derive from like
+in C++, but the methods provided don't really match but are wxPython
+specific. It could have been added long ago but OOR required it so it
+finally got done.</p>
+<p>Finally added wxPyLineShape.GetLineControlPoints, which has been on my
+list for a while. The above OOR modification made this easier.</p>
+<p>Fixed the __cmp__ methods for wxPoint and others.</p>
+<p>Added wxWave.</p>
+<p>Added the wxPython.lib.mixins package to the library, it is where
+useful mix-in classes can be placed. Currently there is one to help
+make the columns in a wxListCtrl sortable, and the MagicIMageList from
+Mike Fletcher. If you have any custom code that can be factored out
+of existing classes into a mix-in that would be useful to others
+please send it to me for inclusion in this package.</p>
+<p>Added a few little sample applications to help newbies to get started
+by having smaller functional apps to play with. They can be found in
+wxPython/samples.</p>
+</div>
+<div class="section" id="id14">
+<h1><a name="id14">2.2.6</a></h1>
+<p>No changes happened in the Python wrappers for this release, only
+changes and fixes in the wxWindows library.</p>
+</div>
+<div class="section" id="id15">
+<h1><a name="id15">2.2.5</a></h1>
+<p>New typemaps for wxString when compiling for Python 2.0 and beyond
+that allow Unicode objects to be passed as well as String objects. If
+a Unicode object is passed PyString_AsStringAndSize is used to convert
+it to a wxString using the default encoding.</p>
+<p>Fixed the generic buttons so tool tips work for them.</p>
+<p>Fixed a bug in the demo's tree control.</p>
+<p>Added a listbox to the listbox demo that shows how to find items with
+a matching prefix as keys are typed.</p>
+<p>Added code to the wxListCtrl demo to show how to get text from a
+column in report mode.</p>
+<p>Added code to the toolbar demo to clear the long help from the status
+bar after 2 seconds.</p>
+<p>Added wxJoystick.</p>
+<p>Fixed wxTimer so it can be used as described in the docs, either with
+a Notify method in a subclass, or sending an event to a wxEvtHandler
+object, (usually a window.)</p>
+<p>Added wxNotifyEvent.Allow()</p>
+<p>Fixed GOBS of reference leaks.</p>
+<p>Massive code changes and cleanup to allow wxPython to be split into
+multiple extension modules again. A Python CObject is used to allow
+the "export" of SWIG functions and other common helper functions from
+the wxc module to other modules, even if they are in separate shared
+libraries. Should also be usable from 3rd party code, just include
+wxPython/src/export.h</p>
+<p>Changed the default setup so the following are built as separate
+extension modules: calendar, glcanvas, grid, html, ogl, stc, and
+utils. Will probably add more later.</p>
+<p>Changed the wxPrinterDC to use the new constructor taking a
+wxPrintData object. The old ctor is still there using the
+wxPrinterDC2 name.</p>
+<p>Added wxPython.lib.anchors.py from Riaan Booysen. It contains a class
+that implements Delphi's Anchors with wxLayoutConstraints.</p>
+<p>Added wxPython.lib.fancytext from Timothy Hochberg.</p>
+<p>Changed the GenericButtons to send their event in idle time, so the
+mouse won't be captured when the event handler is called.</p>
+<p>Added wxPython.lib.rpcMixin from Greg Landrum, although it's not
+integrated with the demo yet. It allows a wxPython GUI to be an
+XML-RPC server.</p>
+</div>
+<div class="section" id="new-in-2-2-2">
+<h1><a name="new-in-2-2-2">New in 2.2.2</a></h1>
+<p>Significantly changed how the wxStyledtextCtrl code that wraps
+Scintilla is implemented. Most of it is now automatically generated
+from an interface definition file provided by Scintilla. This means
+that it will be much easier to stay in sync with new Scintilla
+releases, but also means that some of the method and identifier names
+have changed. See wxPython/demo/data/stc.h for a copy of the C++
+interface from which the Python interface is generated. There is now
+some inline documentation in that file that should really help explain
+how things work.</p>
+<p>I am now using the Python Distutils to build wxPython and to make some
+of the distribution files. (See <a class="reference" href="http://www.python.org/sigs/distutils-sig/">http://www.python.org/sigs/distutils-sig/</a>)
+This means no more messing with my kludgy build.py/Makefile hack,
+builds will be more consistent with other Python extensions that also
+use Distutils, and will hopefully make wxPython easier to build for
+platforms where there have been troubles before. If you are building
+wxPython for Python 1.5.2 or for 1.6, then you will need to get and
+install version 1.0 of Distutils from the website above. If you are
+using Python 2.0 then you already have it.</p>
+<p>Added wxInputStream and the wxFileSystem family of classes,
+contributed by Joerg Baumann.</p>
+<p>Added wxProcess and support for it to wxExecute. wxProcess lets you
+get notified when an asyncronous child process terminates, and also to
+get input/output streams for the child process's stdout, stderr and
+stdin.</p>
+<p>Removed the old python sizers.</p>
+<p>Added __add__, __sub__ and __cmp__ (equality check only) for wxPoint
+and wxRealPoint.</p>
+<p>Changed the build to make one big extension module instead of one for
+the core and each contrib. This allowed me to do away with the
+libwxPyHelpers.so on unix systems.</p>
+<p>Lots of little fixes here and there.</p>
+<p>Some hacks on wxGTK to try and make the AutoComplete listbox in the
+wxStyledTextCtrl to behave better. It's still not as nice as on
+wxMSW, but at least it's a bit more usable now.</p>
+</div>
+<div class="section" id="new-in-2-2-1">
+<h1><a name="new-in-2-2-1">New in 2.2.1</a></h1>
+<p>Various tweaks, fixes, missing methods, etc.</p>
+<p>Added example use of wxTaskBarIcon to the demo.</p>
+</div>
+<div class="section" id="new-in-2-2-0">
+<h1><a name="new-in-2-2-0">New in 2.2.0</a></h1>
+<p>Added wxLog and friends.</p>
+<p>Added wxFrame.ShowFullScreen for MSW.</p>
+<p>Added PyShellWindow to the wxPython.lib package.</p>
+</div>
+<div class="section" id="new-in-2-1-16">
+<h1><a name="new-in-2-1-16">New in 2.1.16</a></h1>
+<p>Added an attribute named labelDelta to the generic buttons that
+specifies how far to offset the label when the button is in the
+depressed state.</p>
+<p>Added wxTipProvider and friends. See the demo for an example.</p>
+<p>wxGrid can now change the cell highlight colour.</p>
+<p>Added wxDragImage.</p>
+<p>Fixed printing on wxGTK.</p>
+<p>Added wxDateTime, wxTimeSpan, and wxDateSpan to wxPython.utils.</p>
+<p>Added wxCalendarCtrl.</p>
+<p>WARNING: A while back I asked what should be done about the Magic
+Method Names. (Methods that are automatically turned into event
+handlers by virtue of their name.) The consensus was that it is more
+confusing to have them than to try and expand them to have greater
+coverage. I am finally getting around to removing the code that
+generates the event binding. This means that if you are using any of
+the following method names without a EVT_* call that you need to
+modify your code to add the EVT_* to hook the event to the method.</p>
+<blockquote>
+OnChar
+OnSize
+OnEraseBackground
+OnSysColourChanged
+OnInitDialog
+OnPaint
+OnIdle
+OnActivate
+OnMenuHighlight
+OnCloseWindow
+OnScroll</blockquote>
+<p>Added wxSpinCtrl.</p>
+</div>
+<div class="section" id="new-in-2-1-15">
+<h1><a name="new-in-2-1-15">New in 2.1.15</a></h1>
+<p>Fixed wxTreeCtrl.HitTest to return both the tree item as well as the
+flags that clairify where the click was in relation to the item.</p>
+<p>Fixed thread state problem in wxTreeCtrl.GetBoundingBox and
+GetSelections.</p>
+<p>Fixed some problems in OGL. Also wxShape.SetClientData and
+.GetClientData can now deal with Python objects.</p>
+<p>Added wxListCtrl.SortItems and changed the demo to show how to use it.</p>
+<p>Plugged a memory leak.</p>
+<p>Wrapped the new wxGrid and friends. The old wxGrid class is no longer
+available. There are some incompatibilities, and unfortunately the
+new classes are not documented yet, (however the methods are more
+consistent with each other now so you may be able to guess pretty
+good...)</p>
+<p>Updated filebrowsebutton.py and calendar.py with changes from their
+authors. There is now a FileBrowseButtonWithHistory class (what a
+mouthful!) and wxCalendar has printing support.</p>
+<p>Added ActiveXWrapper to the library, and some good demos of it too.
+It works great for embedding a COM (a.k.a OCX, a.k.a ActiveX) control
+in a window and calling its methods. It actually creates a new class
+on the fly that derives from wxWindow, the COM CoClass and others
+needed to make it all work. The resulting class can be instantiated
+just like wxWindow, used in sizers, etc. It also responds to all COM
+method calls, properties, etc., and if the class or a mix-in has
+matching method names, then the COM events will be propogated back to
+them.</p>
+<p>Created a typemap that allows a string to be used for parameters
+expecting a wxColour type. The string is either a colour name as
+defined in the wxColourDatabase, or a colour spec of the form
+"#RRGGBB". See the wxStyledTextCtrl demo for an example.</p>
+<p>I almost forgot to mention the wxStyledTextCtrl! Yes, the
+wxStyledTextCtrl is finally in wxPython!! (And the crowd goes
+wild...) There's no documentaTion yet (the crowd boos and hisses...)
+but I've included a very readable source file in the
+wxPython/demo/data directory, a couple fairly good examples, and you
+can also refer to the Scintilla documentaion at
+<a class="reference" href="http://www.scintilla.org/ScintillaDoc.html">http://www.scintilla.org/ScintillaDoc.html</a> to help fill in the gaps
+until the docs are done. (The croud murmers contentedly as the tool
+provider smiles convincingly and removes his flame-proof suit.)</p>
+</div>
+<div class="section" id="what-s-new-in-2-1-13">
+<h1><a name="what-s-new-in-2-1-13">What's new in 2.1.13</a></h1>
+<p>Skipped a version number to match what has been released for wxGTK.</p>
+<p>Updated wxMVCTree and added a demo for it, also fixed layout on GTK
+and some flicker problems.</p>
+<p>Added a wrapper class for the Visualization ToolKit (or VTK) in the
+wxPython.lib.vtk module. (<a class="reference" href="http://www.kitware.com/">http://www.kitware.com/</a>)</p>
+<p>Fixed wxTreeCtrl.SetItemImage and GetItemImage to recognise the new
+"which" parameter.</p>
+<p>Added wxPython.lib.spashscreen from Mike Fletcher.</p>
+<p>Added wxPython.lib.filebrowsebutton also from Mike Fletcher.</p>
+<p>Renamed wxTreeCtrl.GetParent to GetItemParent to avoid a name clash
+with wxWindow.GetParent.</p>
+<p>Added wxIntersectRect to compute the intersection of two wxRect's.
+It is used like this:</p>
+<blockquote>
+intersect = wxIntersectRect(rect1, rect2)</blockquote>
+<p>If r1 and r2 don't intersect then None is returned, otherwise the
+rectangle representing the intersection is returned.</p>
+<p>Some bug fixes for Clipboard and Drag-n-Drop.</p>
+<p>Rotated text!!! WooHoo! (See wxDC.DrawRotatedText())</p>
+<p>Added a set of Generic Buttons to the library. These are simple
+window classes that look and act like native buttons, but you can have
+a bit more control over them. The bezel width can be set in addition
+to colours, fonts, etc. There is a ToggleButton as well as Bitmap
+versions too. They should also serve as a good example of how to
+create your own classes derived from wxControl.</p>
+<p>The C++ wxToolBar classes have been redone, and so have the wxPython
+wrappers. There have been slight modifications to some of the methods
+but shouldn't impact anybody too much. I took the opportunity to add
+support for setting user data on each toolbar tool. The new AddTool
+methods look like this:</p>
+<blockquote>
+<dl>
+<dt>def AddTool(ID,</dt>
+<dd>bitmap,
+pushedBitmap = wxNullBitmap,
+toggle = FALSE,
+clientData = NULL,
+shortHelpString = "",
+longHelpString = "")</dd>
+<dt>def AddSimpleTool(ID,</dt>
+<dd>bitmap,
+shortHelpString = "",
+longHelpString = "",
+toggle=FALSE)</dd>
+</dl>
+</blockquote>
+<p>There are also corresponding InsertTool and InsertSimpleTool methods
+that additionally take an integer position as the first parameter.</p>
+<p>Added a wrapper for the new PCX and TIFF ImageHandlers.</p>
+<p>wxRect now simulates attributes named left, right, top and bottom.</p>
+<p>Removed all non wx stuff from the glcanvas module since DA's PyOpenGL
+is better and compatible with the wxGLCanvas. You can get it at
+<a class="reference" href="http://starship.python.net:9673/crew/da/Code/PyOpenGL">http://starship.python.net:9673/crew/da/Code/PyOpenGL</a>.</p>
+<p>Added some missing EVT functions.</p>
+<p>Added Dirk Holtwic's editor classes to the wxPython.lib.editor
+package.</p>
+<p>Changed all the "LIST" parameter names to "choices" to match the docs.</p>
+<p>More fixes for the wxFloatBar, and it now works on wxGTK even better
+than wxMSW! (The feat is accomplished by using the wxTB_DOCKABLE
+style flag instead of trying to float it ourselves.)</p>
+</div>
+<div class="section" id="what-s-new-in-2-1-11">
+<h1><a name="what-s-new-in-2-1-11">What's new in 2.1.11</a></h1>
+<p>Skipped a few version numbers so wxMSW, wxGTK and wxPython are all
+syncronized.</p>
+<p>wxImage.SetData now makes a copy of the image data before giving it to
+wxImage. I mistakenly thought that wxImage would copy the data
+itself.</p>
+<p>Fixed wxMSW's notebook so the pages get their size set as they are
+being added. This should remove the need for our
+wxNotebook.ResizeChildren hack.</p>
+<p>wxPanels now support AutoLayout, and wxNotebooks and wxSplitterWindows
+no longer tell their children to Layout() themselves. This will
+probably only effect you if you have a wxWindow with AutoLayout inside
+a notebook or splitter. If so, either change it to a wxPanel or add
+an EVT_SIZE handler that calls Layout().</p>
+<p>Fixed deadlock problem that happened when using threads.</p>
+<p>Added new HTML printing classes.</p>
+<p>Added wxWindow.GetHandle</p>
+<p>Apparently wxMouseEvent.Position has been depreciated in wxWindows as
+it is no longer available by default. You can use GetPositionTuple
+(returning a tuple with x,y) instead, or GetPosition (returning a
+wxPoint.)</p>
+<p>Added wxPostEvent function that allows events to be posted and then
+processed later. This is a thread-safe way to interact with the GUI
+thread from other threads.</p>
+<p>Added Clipboard and Drag-and-Drop classes.</p>
+<p>Added wxFontEnumerator.</p>
+<p>Many updates to wxMenu, wxMenuBar.</p>
+<p>wxPyEvent and wxPyCommandEvent derived classes now give you the actual
+Python object in the event handler instead of a new shadow.</p>
+<p>Added a Calendar widget from Lorne White to the library.</p>
+<p>Made some fixes to the wxFloatbar. It still has some troubles on
+wxGTK...</p>
+<p>Added an MVC tree control from Bryn Keller to the library.</p>
+</div>
+<div class="section" id="what-s-new-in-2-1-5">
+<h1><a name="what-s-new-in-2-1-5">What's new in 2.1.5</a></h1>
+<p>This is a quick bug-fix release to take care of a few nasties that
+crept in at the last minute before 2.1.4 was called done. No new
+major features.</p>
+</div>
+<div class="section" id="what-s-new-in-2-1-4">
+<h1><a name="what-s-new-in-2-1-4">What's new in 2.1.4</a></h1>
+<p>This release is NOT syncronized with a snapshot release of wxGTK or
+wxMSW. For MSW this isn't much of a problem since you can get the
+binaries from the web site. For other platforms you'll have to build
+wxGTK from CVS. (See <a class="reference" href="http://web.ukonline.co.uk/julian.smart/wxwin/cvs.htm">http://web.ukonline.co.uk/julian.smart/wxwin/cvs.htm</a>)
+To get the same set of sources from CVS that I used, checkout using
+the wxPy-2-1-4 tag.</p>
+<p>Now back to what's new...</p>
+<p>Much more support for event-less callbacks and add-on modules.</p>
+<p>Created add-on module with wxOGL classes.</p>
+<p>Added wxWindow.GetChildren(). Be careful of this. It returns a <em>copy</em>
+of the list of the window's children. While you are using the list if
+anything changes in the real list (a child is deleted, etc.) then the
+list you are holding will suddenly have window references to garbage
+memory and your app will likely crash. But if you are careful it works
+great!</p>
+<p>Added a bunch of new and missing methods to wxTreeCrtl. The
+SortChildren method is now supported, but currently only for the
+default sort order.</p>
+<p>Added typemaps for wxSize, wxPoint, wxRealPoint, and wxRect that allow
+either the actual objects or Python sequence values to be used. For
+example, the following are equivallent:</p>
+<blockquote>
+win = wxWindow(parent, size = wxSize(100, 100))
+win = wxWindow(parent, size = (100, 100))</blockquote>
+<p>Super-charged the wxHtml module. You can now create your own tag
+handlers and also have access to the parser and cell classes. There
+is a tag handler in the library at wxPython.lib.wxpTag that
+understands the WXP tag and is able to place wxPython windows on HTML
+pages. See the demo for an example.</p>
+<p>A bunch of the methods of wxMenuBar were previously ifdef'd out for
+wxGTK. Added them back in since the methods exist now.</p>
+<p>Wrapped the wxHtmlHelpController and related classes.</p>
+<p>Wrapped the C++ versions of wxSizer and friends. The Python-only
+versions are still in the library, but depreciated. (You will get a
+warning message if you try to use them, but the warning can be
+disabled.) The usage of the C++ versions is slightly different, and
+the functionality of wxBorderSizer is now part of wxBoxSizer. I have
+added a few methods to wxSizer to try and make the transition as
+smooth as possible, I combined all Add methods into a single method
+that handles all cases, added an AddMany method, etc. One step I did
+not take was to make the default value of flag in the Add method be
+wxGROW. This would have made it more backward compatible, but less
+portable to and from wxWin C++ code. Please see the docs and demo for
+further details.</p>
+<p>Added wxPyEvent and wxPyCommandEvent classes, derived from wxEvent and
+wxCommandEvent. Each of them has SetPyData and GetPyData methods that
+accept or return a single Python object. You can use these classes
+directly or derive from them to create your own types of event objects
+that can pass through the wxWindows event system without loosing their
+Python parts (as long as they are stored with SetPyData.) Stay tuned
+for more info and examples in future releases.</p>
+<p>Added wxPython.lib.grids as an example of how to derive a new sizer
+from the C++ sizers. In this module you will find wxGridSizer and
+wxFlexGridSizer. wxGridSizer arrainges its items in a grid in which
+all the widths and heights are the same. wxFlexgridSizer allows
+different widths and heights, and you can also specify rows and/or
+columns that are growable. See the demo for a couple examples for how
+to use them.</p>
+<p>Added the wxValidator class, and created a class named wxPyValidator
+that should be used for the base class of any Python validators. See
+the demo for an example. Please note that you MUST implement a Clone
+method in your validator classes because of the way some things work
+in the underlying C++ library. I did not add wxTextValidator because
+of some issues of how it transfers data to and from a wxString, which
+in wxPython is automatically translated to and from Python strings, so
+there would never be a concrete wxString that would hang around long
+enough for the validator to do its job. On the other hand, it should
+be real easy to duplicate the functionality of wxTextValidator in a
+pure Python class derived from wxPyValidator.</p>
+<p>I've finally added a feature that has been on my list for close to two
+years! Ever wondered what that zero is for when you create your app
+object? Well now you can leave it out or explicitly set it to a true
+value. This value now controls what is to be done with sys.stdout and
+sys.stderr. A false value leaves them alone, and a true value sets
+them to an instance of wxPyOnDemandOutputWindow. (On windows the
+default is true, on unix platforms the default is false.) This class
+creates a frame containing a wxTextCtrl as soon as anything is written
+to sys.stdout or sys.stderr. If you close the window it will come
+back again the next time something is written. (You can call
+app.RestoreStdio to turn this off.) If you would rather that the stdio be
+redirected to a file, you can provide a second parameter to your app
+object's constructor that is a filename. If you want to use your own
+class instead of wxPyOnDemandOutputWindow you can either implement
+RedirectStdio() in you app class or change the value of
+wxApp.outputWindowClass like this:</p>
+<blockquote>
+<dl>
+<dt>class MyApp(wxApp):</dt>
+<dd><p class="first">outputWindowClass = MyClass</p>
+<dl class="last">
+<dt>def OnInit(self):</dt>
+<dd>frame = MyFrame()
+self.SetTopWindow(frame)
+return true</dd>
+</dl>
+</dd>
+</dl>
+</blockquote>
+<p>Please see the implementation of wxPyOnDemandOutputWindow and wxApp in
+wx.py for more details. A few words of caution: if you are running
+your app in a debugger, changing sys.stdout and sys.stderr is likely
+to really screw things up.</p>
+<p>Added wxCaret. Unfortunately it's author has still not documented it
+in the wxWindows docs...</p>
+<p>Some new 3rd party contributions in wxPython.lib. PyShell, in
+shell.py is an interesting implementaion of an interactive Python
+shell in wxWindows. floatbar.py has a class derived from wxToolBar
+that can sense mouse drags and then reparent itself into another
+frame. Moving the new frame close to where it came from puts the tool
+bar back into the original parent. (Unfortunately there is currently
+a bug in wxGTK's wxFrame.SetToolBar so the FloatBar has some
+problems...)</p>
+</div>
+<div class="section" id="what-s-new-in-2-1b3">
+<h1><a name="what-s-new-in-2-1b3">What's new in 2.1b3</a></h1>
+<p>This release is syncronized with release 2.1 snapshot 9 of wxWindows.</p>
+<p>Switched to using SWIG from CVS (see <a class="reference" href="http://swig.cs.uchicago.edu/cvs.html">http://swig.cs.uchicago.edu/cvs.html</a>)
+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:</p>
+<blockquote>
+<ol class="arabic">
+<li><p class="first">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:</p>
+<blockquote>
+<p>win = wxWindow(parent, -1, style = mystyle)</p>
+</blockquote>
+</li>
+<li><p class="first">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.</p>
+</li>
+</ol>
+</blockquote>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="what-s-new-in-2-1b2">
+<h1><a name="what-s-new-in-2-1b2">What's new in 2.1b2</a></h1>
+<p>Added the missing wxWindow.GetUpdateRegion() method.</p>
+<p>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.</p>
+<p>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.</p>
+<p>I fixed a bunch of stuff in the C++ version of wxGrid so it wouldn't
+make wxPython look bad.</p>
+<p>wxWindow.PopupMenu() now takes a wxPoint instead of x,y. Added
+wxWindow.PopupMenuXY to be consistent with some other methods.</p>
+<p>Added wxGrid.SetEditInPlace and wxGrid.GetEditInPlace.</p>
+<p>You can now provide your own app.MainLoop method. See
+wxPython/demo/demoMainLoop.py for an example and some explaination.</p>
+<p>Got the in-place-edit for the wxTreeCtrl fixed and added some demo
+code to show how to use it.</p>
+<p>Put the wxIcon constructor back in for GTK as it now has one that
+matches MSW's.</p>
+<p>Added wxGrid.GetCells</p>
+<p>Added wxSystemSettings static methods as functions with names like
+wxSystemSettings_GetSystemColour.</p>
+<p>Removed wxPyMenu since using menu callbacks have been depreciated in
+wxWindows. Use wxMenu and events instead.</p>
+<dl>
+<dt>Added alternate wxBitmap constructor (for MSW only) as</dt>
+<dd>wxBitmapFromData(data, type, width, height, depth = 1)</dd>
+</dl>
+<p>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.</p>
+<p>Fixed wxImage GetData and SetData to properly use String objects for
+data transfer.</p>
+<p>Added access methods to wxGridEvent.</p>
+<p>New Makefile/Setup files supporting multiple dynamic extension modules
+for unix systems.</p>
+<p>Fixes for the wxGLCanvas demo to work around a strange bug in gtk.</p>
+<p>SWIG support routines now compiled separately instead of being bundled
+in wx.cpp.</p>
+</div>
+<div class="section" id="what-s-new-in-2-1b1">
+<h1><a name="what-s-new-in-2-1b1">What's new in 2.1b1</a></h1>
+<p>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.)</p>
+<p>Added the Printing Framework.</p>
+<p>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.</p>
+<p>Lots of little tweaks and additions to reflect changes to various
+wxWindows classes.</p>
+<p>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.</p>
+<p>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!</p>
+</div>
+<div class="section" id="what-s-new-in-2-0b9">
+<h1><a name="what-s-new-in-2-0b9">What's new in 2.0b9</a></h1>
+<p>Bug fix for ListCtrl in test4.py (Was a missing file... DSM!)</p>
+<p>Bug fix for occassional GPF on Win32 systems upon termination of a
+wxPython application.</p>
+<p>Added wxListBox.GetSelections returning selections as a Tuple.</p>
+<p>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.</p>
+<p>Added wxSafeYield function.</p>
+<p>OpenGL Canvas can be optionally compiled in to wxPython.</p>
+<p>Awesome new Demo Framework for showing off wxPython and for learning
+how it all works.</p>
+<p>The pre-built Win32 version is no longer distributing the wxWindows
+DLL. It is statically linked with the wxWindows library instead.</p>
+<p>Added a couple missing items from the docs.</p>
+<p>Added wxImage, wxImageHandler, wxPNGHandler, wxJPEGHandler,
+wxGIFHandler and wxBMPHandler.</p>
+<p>Added new methods to wxTextCtrl.</p>
+<p>Fixed some problems with how SWIG was wrapping some wxTreeCtrl
+methods.</p>
+</div>
+<div class="section" id="what-s-new-in-2-0b8">
+<h1><a name="what-s-new-in-2-0b8">What's new in 2.0b8</a></h1>
+<p>Support for using Python threads in wxPython apps.</p>
+<p>Several missing methods from various classes.</p>
+<p>Various bug fixes.</p>
+</div>
+<div class="section" id="what-s-new-in-2-0b7">
+<h1><a name="what-s-new-in-2-0b7">What's new in 2.0b7</a></h1>
+<p>Added DLG_PNT and DLG_SZE convienience methods to wxWindow class.</p>
+<p>Added missing constructor and other methods for wxMenuItem.</p>
+</div>
+<div class="section" id="what-s-new-in-2-0b6">
+<h1><a name="what-s-new-in-2-0b6">What's new in 2.0b6</a></h1>
+<p>Just a quickie update to fix the self-installer to be compatible with
+Python 1.5.2b2's Registry settings.</p>
+</div>
+<div class="section" id="what-s-new-in-2-0b5">
+<h1><a name="what-s-new-in-2-0b5">What's new in 2.0b5</a></h1>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>Added wxImageList, wxToolTip.</p>
+<p>Re-enabled wxConfig.DeleteAll() since it is reportedly fixed for the
+wxRegConfig class.</p>
+<p>As usual, some bug fixes, tweaks, etc.</p>
+</div>
+<div class="section" id="what-s-new-in-0-5-3">
+<h1><a name="what-s-new-in-0-5-3">What's new in 0.5.3</a></h1>
+<p>Added wxSashWindow, wxSashEvent, wxLayoutAlgorithm, etc.</p>
+<p>Various cleanup, tweaks, minor additions, etc. to maintain
+compatibility with the current wxWindows.</p>
+</div>
+<div class="section" id="what-s-new-in-0-5-0">
+<h1><a name="what-s-new-in-0-5-0">What's new in 0.5.0</a></h1>
+<p>Changed the import semantics from <tt class="literal"><span class="pre">"from</span> <span class="pre">wxPython</span> <span class="pre">import</span> <span class="pre">*"</span></tt> to
+<tt class="literal"><span class="pre">"from</span> <span class="pre">wxPython.wx</span> <span class="pre">import</span> <span class="pre">*"</span></tt> 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."</p>
+<p>Added wxTaskbarIcon for wxMSW.</p>
+<p>Made the events work for wxGrid.</p>
+<p>Added wxConfig.</p>
+<p>Added wxMiniFrame for wxGTK.</p>
+<p>Changed many of the args and return values that were pointers to gdi
+objects to references to reflect changes in the wxWindows API.</p>
+<p>Other assorted fixes and additions.</p>
+</div>
+<div class="section" id="what-s-new-in-0-4-2">
+<h1><a name="what-s-new-in-0-4-2">What's new in 0.4.2</a></h1>
+<p>wxPython on wxGTK works!!! Both dynamic and static on Linux and
+static on Solaris have been tested. Many thanks go to Harm
+<<a class="reference" href="mailto:H.v.d.Heijden@phys.tue.nl">H.v.d.Heijden@phys.tue.nl</a>> 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.</p>
+<p>The dynamicly loaded module on Solaris is still segfaulting, so it
+must have been a different issue all along...</p>
+</div>
+<div class="section" id="what-s-new-in-0-4">
+<h1><a name="what-s-new-in-0-4">What's New in 0.4</a></h1>
+<p>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.</p>
+<ol class="arabic simple" start="2">
+<li>Added Toolbar, StatusBar and SplitterWindow classes.</li>
+<li>Varioius bug fixes, enhancements, etc.</li>
+</ol>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
CHANGES.txt for wxPython
-
-----------------------------------------------------------------------
+=====================================================================
2.5.1.x
-------
The RPMs will now install menu items on Mandrake in
Applications/Development/Tools for PyCrust, XRCed, etc. They are also
-installing icons and *.desktop items in the generic KDE and GNOME
+installing icons and ``*.desktop`` items in the generic KDE and GNOME
locations, but I don't know yet if they are resulting in menu items on
non-Mandrake systems. (It didn't automatically do it on my RH-9 build
box but I didn't chase it very far...) If you have ideas for how to
Added SetShape method to top level windows (e.g. wxFrame.)
Changed wxSWIG to not generate Python code using apply, (since it will
-be deprecated in the future) wxSWIG will use spam(*args, **kw) syntax
+be deprecated in the future) wxSWIG will use ``spam(*args, **kw)`` syntax
instead. Also changed the generated __repr__ methods to be a bit more
informative.
Added the new wx "renamer" package that will dynamically import from
the wxPython package and rename wxFooBar --> FooBar. That means that
-people can do imports without "import *" and can use names like
+people can do imports without ``"import *"`` and can use names like
wx.Frame instead of wx.wxFrame. This is phase 1 of a full transition
to the new namespace.
2.4.0.7
-------
+
Gave up on generating a warning upon the use of the old true/false or
TRUE/FALSE values.
2.4.0.6 (a.k.a. the I'm so stupid release)
--------
+------------------------------------------
+
The new deprecation class for the old true/false symbols can now be
returned from OnInit. And I promise to be sure I am testing what I
think I am testing in the future...
2.4.0.5 (a.k.a. the blame it on Kevin release)
--------
+----------------------------------------------
+
A few little but annoying bug fixes.
Updated pycolourchooser.
representing the area on screen not occupied by the taskbar and such.
On other platforms it is equivallent to wxGetDisplaySize.
-
-***---***---***---***---***---***---***---***---***---***---***---
+OOR:
Implemented the first phase of OOR (Original Object Return). See
the text in the demo for more details of what this means, but in a
nutshell methods such as wxWindow.GetParent or FindWindowById will
stomped on during my testing. So please be sure to test everything
thoroughly when you install this version and be sure to report any
object-type related oddities to me.
-***---***---***---***---***---***---***---***---***---***---***---
+
There is now a wxObject class that most other classes derive from like
in C++, but the methods provided don't really match but are wxPython
is better and compatible with the wxGLCanvas. You can get it at
http://starship.python.net:9673/crew/da/Code/PyOpenGL.
-Added some missing EVT_ functions.
+Added some missing EVT functions.
Added Dirk Holtwic's editor classes to the wxPython.lib.editor
package.
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
+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."
3. Varioius bug fixes, enhancements, etc.
-----------------------------------------------------------------------
+
+
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>Installing wxPython 2.5 from Source</title>
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="installing-wxpython-2-5-from-source">
+<h1 class="title">Installing wxPython 2.5 from Source</h1>
+<p>This document will describe the few differences and additions to the
+content in BUILD.txt for installing wxPython built from source.
+Please follow the intstructions both in this file and in BUILD.txt to
+perform this task. Where there is overlap the items described here
+will take precedence.</p>
+<div class="section" id="installing-on-unix-like-systems-not-os-x">
+<h1><a name="installing-on-unix-like-systems-not-os-x">Installing on Unix-like Systems (not OS X)</a></h1>
+<ol class="arabic">
+<li><p class="first">When building wxWindows you need to decide if you want it to be a
+private copy only accessed by wxPython, or if you would like it to
+be installed in a stanard location such as /usr. Or perhaps you
+already have a version of wxWindows installed on your system (such
+as from an RPM) and you want wxPython to use that version too. If
+so then you'll want to ensure that the flags and options used to
+build the installed version are compatible with wxPython.</p>
+</li>
+<li><p class="first">If you do decide to build and install your own wxWindows then there
+are a few tweaks to the configure flags described in BUILD.txt that
+you will probably want to make. Instead of --enable-debug use
+this configure flag:</p>
+<pre class="literal-block">
+--enable-optimize \
+</pre>
+<p>Normally I also use the following flag in order to have wxWindows
+runtime assertions turned into Python exceptions where possible.
+It does add extra code to the build but probably not enough to
+worry about it. However if you want to get as lean a build as
+possible you can leave it out, but if your code does something bad
+then instead of exceptions you'll likely get a crash.</p>
+<blockquote>
+<p>--enable-debug_flag </p>
+</blockquote>
+<p>If you are building a private copy of wxWindows (IOW, not installed
+in a standard library location) then it can be kind of a hassle to
+always have to set the LD_LIBRARY_PATH variable so wxPython can
+find the wxWindows shared libraries. You can hard code the library
+path into the binaries by using the rpath option when configuring
+wxWindows. For example:</p>
+<pre class="literal-block">
+--enable-rpath=/opt/wx/2.5/lib \
+</pre>
+<p>SOLARIS NOTE: The --enable-rpath option may cause problems when
+using wxGTK on Solaris when compiling wxPython as described below.
+The woraround is to not use --enable-rpath flag for configure, but
+in that case all wxPython applications <em>must</em> have the
+LD_LIBRARY_PATH set to include $WXPREF/lib, or you can use the
+'crle' program to modify the runtime linking environment. If this
+is the only installation of wxGTK on the system then you can use a
+system library path for prefix and not have to worry about it at
+all.</p>
+</li>
+<li><p class="first">Build and install wxGTK as described in BUILD.txt.</p>
+</li>
+<li><p class="first">In addition to building wxPython as described in BUILD.txt, you can
+install it to Python's site-packages dir, as well as some scripts
+into the same bin dir used by Python by using this command:</p>
+<pre class="literal-block">
+python2.3 setup.py install
+</pre>
+<p>If you would like to install to some place besides the prefix where
+Python is installed, (such as to your home directory) then you can
+add "--root=<path>" after the "install" command. This will use
+<path> as the prefix and will install scripts to a bin subdir and
+the wxPython packages to a lib subdir. To use wxPython like this
+you'll need to ensure that the directory containing wxPython is
+contained in the PYTHONPATH environment variable.</p>
+</li>
+</ol>
+</div>
+<div class="section" id="installing-on-os-x">
+<h1><a name="installing-on-os-x">Installing on OS X</a></h1>
+<p>Installing wxPython on OS X is nearly the same as the Unix
+instructions above, except for a few small, but important details:</p>
+<ol class="arabic simple">
+<li>The --enable-rpath configure option is not needed since the path to
+the wxWindows dylibs will automatically be encoded into the
+extension modules when they are built. If you end up moving the
+wxWindows dynlibs to some other location (such as inside the .app
+bundle of your applicaiton for distribution to other users,) then
+you will need to set DYLD_LIBRARY_PATH to this location so the
+dylibs can be found at runtime.</li>
+<li>Depending on the version of OS X Python may be installed in
+different locations. On 10.2 (Jaguar) you need to download and
+install MacPython-OSX-2.3 from <a class="reference" href="http://www.python.org/">http://www.python.org/</a> and the
+Python Framework will then be installed in /Library/Frameworks. On
+10.3 (Panther) Apple supplies the Python Framework as part of the
+OS install, but it will be located in /System/Library/Frameworks
+instead. However, on Panther the site-pacakges dir is sym-linked
+to /Library/Python/2.3 so the wxPython pacakges will end up there,
+although they will still be visible from site-packages. If you are
+building distributions of wxPython to be installed on other
+machines be careful to install to /Library/Python/2.3. To
+complicate things further, the Jaguar version, or a custom build
+you do yourself will end up in /Library/Frameworks even on
+Panther...</li>
+<li>You need to use pythonw at the command line or PythonLauncher app
+to run wxPython apps, otherwise the app will not be able to fully
+use the GUI display.</li>
+</ol>
+</div>
+<div class="section" id="installing-on-windows">
+<h1><a name="installing-on-windows">Installing on Windows</a></h1>
+<ol class="arabic">
+<li><p class="first">Build wxWindows and wxPython as described in BUILD.txt. If you
+would rather have a version without the code that turns runtime
+assertions into Python exceptions, then use "release" instead of
+"hybrid" when building wxWindows and add "FINAL=1" to the setup.py
+command line.</p>
+</li>
+<li><p class="first">Install wxPython like this:</p>
+<pre class="literal-block">
+python setup.py install
+</pre>
+</li>
+<li><p class="first">Copy the wxWindows DLLs to the wx package directory so they can be
+found at runtime by the extension modules without requiring that
+they be installed on the PATH:</p>
+<pre class="literal-block">
+copy %WXWIN%\BIN\wx*h_*.dll c:\Python23\Lib\site-pacakges\wx
+</pre>
+</li>
+</ol>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
<pre class="literal-block">
self.Bind(wx.EVT_SIZE, self.OnSize)
self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton)
-self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT)
+self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT)
+</pre>
+<p>The wx.Menu methods that add items to a wx.Menu have been modified
+such that they return a reference to the wx.MenuItem that was created.
+Additionally menu items and toolbar items have been modified to
+automatically generate a new ID if -1 is given, similar to using -1
+with window classess. This means that you can create menu or toolbar
+items and event bindings without having to predefine a unique menu ID,
+although you still can use IDs just like before if you want. For
+example, these are all equivallent other than ID values:</p>
+<pre class="literal-block">
+1.
+ item = menu.Append(-1, "E&xit", "Terminate the App")
+ self.Bind(wx.EVT_MENU, self.OnExit, item)
+
+2.
+ item = menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App")
+ self.Bind(wx.EVT_MENU, self.OnExit, item)
+
+3.
+ menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App")
+ self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT)
</pre>
-<p>I hope to be able to remove the need for using IDs even for menu
-events too...</p>
<p>If you create your own custom event types and EVT_* functions, and you
want to be able to use them with the Bind method above then you should
change your EVT_* to be an instance of wxPyEventBinder instead of a
</div>
<div class="section" id="sizers">
<h1><a name="sizers">Sizers</a></h1>
-<p>The hack allowing the old "option" keyword parameter has been
-removed. If you use keyworkd args with wxSizer Add, Insert, or
-Prepend then you will need to use the "proportion" name instead of
-"option".</p>
+<p>The hack allowing the old "option" keyword parameter has been removed.
+If you use keyworkd args with wxSizer Add, Insert, or Prepend methods
+then you will need to use the "proportion" name instead of "option".</p>
<p>When adding a spacer to a sizer you now need to use a wxSize or a
2-integer sequence instead of separate width and height parameters.</p>
<p>The wxGridBagSizer class (very similar to the RowColSizer in the
into a single extension module, the "core" module is now just a few
extensions that are linked independently, and then merged together
later into the main namespace via Python code.</p>
-<p>Because of the above, the "internal" module names have changed, but
-you shouldn't have been using them anyway so it shouldn't bother
-you. ;-)</p>
-<p>The wxPython.help module no longer exists and the classes therein are
-now part of the core module imported with wxPython.wx or the wx
-package.</p>
+<p>Because of the above and also because of the way the new SWIG works,
+the "internal" module names have changed, but you shouldn't have been
+using them anyway so it shouldn't bother you. ;-)</p>
+<p>The help module no longer exists and the classes therein are now part
+of the core module imported with wxPython.wx or the wx package.</p>
<p>wxPyDefaultPosition and wxPyDefaultSize are gone. Use the
wxDefaultPosition and wxDefaultSize objects instead.</p>
<p>Similarly, the wxSystemSettings backwards compatibiility aliases for
<p>wxPyTypeCast has been removed. Since we've had the OOR (Original
Object Return) for a couple years now there should be no need to use
wxPyTypeCast at all.</p>
+<p>If you use the old wxPython package and wxPython.wx namespace then
+there are compatibility aliases for much of the above items.</p>
+<p>The wxWave class has been renamed to wxSound, and now has a slightly
+different API.</p>
</div>
</div>
<hr class="footer" />
<div class="footer">
-<a class="reference" href="MigrationGuide.txt">View document source</a>.
-Generated on: 2004-01-13 20:47 UTC.
-Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+Generated on: 2004-02-04 23:31 UTC.
</div>
</body>
</html>
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>The Py Manual</title>
+<meta name="author" content="Patrick K. O'Brien" />
+<meta name="organization" content="Orbtech" />
+<meta name="date" content="2003-07-02" />
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="the-py-manual">
+<h1 class="title">The Py Manual</h1>
+<h2 class="subtitle" id="py-served-fresh-daily">Py - Served Fresh Daily</h2>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr><th class="docinfo-name">Author:</th>
+<td>Patrick K. O'Brien</td></tr>
+<tr><th class="docinfo-name">Contact:</th>
+<td><a class="first last reference" href="mailto:pobrien@orbtech.com">pobrien@orbtech.com</a></td></tr>
+<tr><th class="docinfo-name">Organization:</th>
+<td><a class="first last reference" href="http://www.orbtech.com/">Orbtech</a></td></tr>
+<tr><th class="docinfo-name">Date:</th>
+<td>2003-07-02</td></tr>
+<tr><th class="docinfo-name">Revision:</th>
+<td>1.2</td></tr>
+</tbody>
+</table>
+<div class="contents topic" id="contents">
+<p class="topic-title"><a name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#introduction" id="id3" name="id3">Introduction</a></li>
+<li><a class="reference" href="#developer-reference" id="id4" name="id4">Developer Reference</a></li>
+<li><a class="reference" href="#what-is-py" id="id5" name="id5">What is Py?</a></li>
+<li><a class="reference" href="#pycrust-is-dead-long-live-py" id="id6" name="id6">PyCrust is dead! Long live Py!</a></li>
+<li><a class="reference" href="#py-standalone-programs" id="id7" name="id7">Py standalone programs</a></li>
+<li><a class="reference" href="#pyalacarte" id="id8" name="id8">PyAlaCarte</a></li>
+<li><a class="reference" href="#pyalamode" id="id9" name="id9">PyAlaMode</a></li>
+<li><a class="reference" href="#pycrust" id="id10" name="id10">PyCrust</a></li>
+<li><a class="reference" href="#pyfilling" id="id11" name="id11">PyFilling</a></li>
+<li><a class="reference" href="#pyshell" id="id12" name="id12">PyShell</a></li>
+<li><a class="reference" href="#pywrap" id="id13" name="id13">PyWrap</a></li>
+<li><a class="reference" href="#py-modules" id="id14" name="id14">Py modules</a></li>
+<li><a class="reference" href="#decorator-classes" id="id15" name="id15">Decorator classes</a></li>
+<li><a class="reference" href="#projects-using-py" id="id16" name="id16">Projects using Py</a></li>
+<li><a class="reference" href="#history-of-changes" id="id17" name="id17">History of changes</a><ul>
+<li><a class="reference" href="#to-2004" id="id18" name="id18">0.9.4 (1/25/2004 to //2004)</a></li>
+<li><a class="reference" href="#to-1-24-2004" id="id19" name="id19">0.9.3 (9/25/2003 to 1/24/2004)</a></li>
+<li><a class="reference" href="#to-9-25-2003" id="id20" name="id20">0.9.2 (5/3/2003 to 9/25/2003)</a></li>
+<li><a class="reference" href="#to-5-2-2003" id="id21" name="id21">0.9.1 (3/21/2003 to 5/2/2003)</a></li>
+<li><a class="reference" href="#to-3-20-2003" id="id22" name="id22">0.9 (2/27/2003 to 3/20/2003)</a></li>
+<li><a class="reference" href="#to-2-26-2003" id="id23" name="id23">0.8.2 (1/5/2003 to 2/26/2003)</a></li>
+<li><a class="reference" href="#to-12-25-2002" id="id24" name="id24">0.8.1 (12/20/2002 to 12/25/2002)</a></li>
+<li><a class="reference" href="#to-12-16-2002" id="id25" name="id25">0.8 (10/29/2002 to 12/16/2002)</a></li>
+<li><a class="reference" href="#to-8-27-2002" id="id26" name="id26">0.7.2 (2/22/2002 to 8/27/2002)</a></li>
+<li><a class="reference" href="#to-2-21-2002" id="id27" name="id27">0.7.1 (12/12/2001 to 2/21/2002)</a></li>
+<li><a class="reference" href="#to-12-11-2001" id="id28" name="id28">0.7 (10/15/2001 to 12/11/2001)</a></li>
+<li><a class="reference" href="#to-10-12-2001" id="id29" name="id29">0.6.1 (9/19/2001 to 10/12/2001)</a></li>
+<li><a class="reference" href="#to-9-12-2001" id="id30" name="id30">0.6 (8/21/2001 to 9/12/2001)</a></li>
+<li><a class="reference" href="#to-8-20-2001" id="id31" name="id31">0.5.4 (8/17/2001 to 8/20/2001)</a></li>
+<li><a class="reference" href="#id1" id="id32" name="id32">0.5.3 (8/16/2001)</a></li>
+<li><a class="reference" href="#to-8-15-2001" id="id33" name="id33">0.5.2 (8/14/2001 to 8/15/2001)</a></li>
+<li><a class="reference" href="#to-8-14-2001" id="id34" name="id34">0.5.1 (8/10/2001 to 8/14/2001)</a></li>
+<li><a class="reference" href="#id2" id="id35" name="id35">0.5 (8/8/2001)</a></li>
+<li><a class="reference" href="#to-8-7-2001" id="id36" name="id36">0.4 (8/4/2001 to 8/7/2001)</a></li>
+<li><a class="reference" href="#to-8-3-2001" id="id37" name="id37">0.3 (8/2/2001 to 8/3/2001)</a></li>
+<li><a class="reference" href="#to-8-2-2001" id="id38" name="id38">0.2 (7/30/2001 to 8/2/2001)</a></li>
+<li><a class="reference" href="#to-7-19-2001" id="id39" name="id39">0.1 (7/1/2001 to 7/19/2001)</a></li>
+<li><a class="reference" href="#in-the-beginning-there-was-pie-7-1-2001" id="id40" name="id40">In the beginning, there was pie... (7/1/2001)</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h1><a class="toc-backref" href="#id3" name="introduction">Introduction</a></h1>
+<p>This document will show you how to use the Py programs and the Py
+library of Python source code modules. Py is the new name for the
+project that began as PyCrust. Py is officially part of <a class="reference" href="http://www.wxpython.org/">wxPython</a>,
+and includes PyCrust, so PyCrust is no longer distributed separately.</p>
+</div>
+<div class="section" id="developer-reference">
+<h1><a class="toc-backref" href="#id4" name="developer-reference">Developer Reference</a></h1>
+<p>Source code documentation for developers is available at:</p>
+<p><a class="reference" href="http://www.orbtech.com/www/wx/epydoc/public/wx.py-module.html">http://www.orbtech.com/www/wx/epydoc/public/wx.py-module.html</a></p>
+</div>
+<div class="section" id="what-is-py">
+<h1><a class="toc-backref" href="#id5" name="what-is-py">What is Py?</a></h1>
+<p>Besides being <a class="reference" href="http://www.wikipedia.org/wiki/Pie">a delicious dessert</a>, Py is the name for a collection
+of whimsically-named Python programs and modules that began as the
+PyCrust project. So Py is really several things: a set of standalone
+programs, including the original PyCrust program, a library of Python
+source code modules that can be used in your own programs, a set of
+decorator classes that enhance the wxPython class library, and as many
+examples of bad "pie" puns as I can come up with. (If you're going to
+do something, you might as well do it all the way, right?) Py uses
+Python and wxPython, so it works equally well on Windows, Linux and
+Mac OS X.</p>
+</div>
+<div class="section" id="pycrust-is-dead-long-live-py">
+<h1><a class="toc-backref" href="#id6" name="pycrust-is-dead-long-live-py">PyCrust is dead! Long live Py!</a></h1>
+<p>This project began with a program I created called PyCrust - an
+interactive, graphical Python shell, developed using the wxPython GUI
+toolkit. For about two years, PyCrust was hosted on <a class="reference" href="http://www.sf.net/projects/pycrust/">SourceForge</a>.
+Shortly after I created PyCrust, the wxPython folks started including
+it in their distribution. As the PyCrust project grew, it reached a
+point where I thought the original PyCrust name was too confining. I
+was using the PyCrust code base to develop programs that weren't just
+Python shells any more.</p>
+<p>Around that same time, the wxPython folks asked me if I'd be willing
+to move all my wxPython-related projects into the <a class="reference" href="http://cvs.wxwindows.org">wxPython CVS
+repository</a>, and become part of the <a class="reference" href="http://www.wxpython.org/">wxPython</a>/<a class="reference" href="http://www.wxwindows.org/">wxWindows</a> developer team.
+I decided the time was right to restructure the PyCrust project.
+During the move, the PyCrust package was renamed to "py" (lowercase
+"p") and the collection of programs and modules as a whole became
+known as "Py" (with a capital "P").</p>
+<p>The original goal of PyCrust was to be the best interactive, graphical
+Python shell (of course, I claimed it was the "flakiest" Python
+shell). And that was all I wanted it to be. But little by little I
+found myself developing a wider variety of tools for wxPython
+applications. Eventually I'll create a debugger (PySlice, perhaps)
+and whatever else is needed to one day become a complete wxPython
+application development environment (PyFactory?). In the mean time,
+PyCrust is still the flakiest Python shell, and the other Py programs
+are equally tasty.</p>
+<p>At this point, Py has standalone programs that include Python code
+editors (PyAlaCarte and PyAlaMode), interactive Python shells (PyCrust
+and PyShell), and a runtime wrapper (PyWrap). The runtime wrapper
+utility provides you with runtime introspection capabilities for your
+wxPython programs without having to include PyCrust or PyShell in your
+program, and without having to alter one line of your source code.</p>
+<p>Py also contains a collection of modules that you can use in your own
+wxPython applications to provide similar services, either for your own
+use during development, or as an interface for users of your programs.
+These modules are the same ones used by all the Py programs. In
+addition, Py contains a set of decorator classes that enhance the
+wxPython class library, by dynamically attaching docstrings and call
+signatures at runtime.</p>
+</div>
+<div class="section" id="py-standalone-programs">
+<h1><a class="toc-backref" href="#id7" name="py-standalone-programs">Py standalone programs</a></h1>
+<p>These are the standalone applications in the Py collection:</p>
+<ul class="simple">
+<li>PyAlaCarte</li>
+<li>PyAlaMode</li>
+<li>PyCrust</li>
+<li>PyFilling</li>
+<li>PyShell</li>
+<li>PyWrap</li>
+</ul>
+</div>
+<div class="section" id="pyalacarte">
+<h1><a class="toc-backref" href="#id8" name="pyalacarte">PyAlaCarte</a></h1>
+<p>PyAlaCarte is a Python source code editor. It is designed to have a
+simple, single-file interface. As a standalone application, it is
+good for simple, short editing tasks. But it is really meant to be
+more of an example of how to embed the Py editor into a wxPython
+application.</p>
+</div>
+<div class="section" id="pyalamode">
+<h1><a class="toc-backref" href="#id9" name="pyalamode">PyAlaMode</a></h1>
+<p>PyAlaMode is a Python source code editor.</p>
+</div>
+<div class="section" id="pycrust">
+<h1><a class="toc-backref" href="#id10" name="pycrust">PyCrust</a></h1>
+<p>PyCrust is an interactive, Python shell. But it's more than just a
+shell. It includes a tabbed notebook containing a namespace tree
+(PyFilling), and several other things.</p>
+</div>
+<div class="section" id="pyfilling">
+<h1><a class="toc-backref" href="#id11" name="pyfilling">PyFilling</a></h1>
+<p>PyFilling is a namespace viewer. It isn't really useful as a
+standalone program, but it does illustrate how to make use of the
+underlying <tt class="literal"><span class="pre">filling</span></tt> module.</p>
+</div>
+<div class="section" id="pyshell">
+<h1><a class="toc-backref" href="#id12" name="pyshell">PyShell</a></h1>
+<p>PyShell is an interactive, Python shell. It shares the same base code
+as PyCrust, but doesn't have any of the extra features that appear in
+the PyCrust notebook interface.</p>
+<div class="figure">
+<p><img alt="/screenshots/PyShell.png" src="/screenshots/PyShell.png" /></p>
+<p class="caption">PyShell running on Mandrake Linux 9.1.</p>
+</div>
+</div>
+<div class="section" id="pywrap">
+<h1><a class="toc-backref" href="#id13" name="pywrap">PyWrap</a></h1>
+<p>PyWrap is a runtime utility that lets you run an existing wxPython
+program with a PyCrust frame at the same time. Inside the PyCrust
+shell namespace, the local variable <tt class="literal"><span class="pre">app</span></tt> is assigned to your
+application instance. In this way you can introspect your entire
+application within the PyCrust shell, as well as the PyFilling
+namespace viewer. And through the use of the Py decorator classes,
+PyCrust can display wxPython function and method signatures as well as
+docstrings for the entire wxPython library.</p>
+</div>
+<div class="section" id="py-modules">
+<h1><a class="toc-backref" href="#id14" name="py-modules">Py modules</a></h1>
+<p>Py was designed to be modular. That means graphical code is kept
+separate from non-graphical code, and many of the Py modules can be
+used by other programs. Likewise, other programs can supply some of
+the modules needed by Py. For example, you could supply a customized
+interpreter module and plug it in to the PyCrust standalone
+application. As long as it supports the minimum functionality
+required, PyCrust will work just as well with your interpreter as with
+its default interpreter.</p>
+</div>
+<div class="section" id="decorator-classes">
+<h1><a class="toc-backref" href="#id15" name="decorator-classes">Decorator classes</a></h1>
+<p>Py contains a set of decorator classes that enhance the wxPython class
+library, by dynamically attaching docstrings and call signatures at
+runtime.</p>
+</div>
+<div class="section" id="projects-using-py">
+<h1><a class="toc-backref" href="#id16" name="projects-using-py">Projects using Py</a></h1>
+<ul class="simple">
+<li><a class="reference" href="http://conflictsolver.sourceforge.net/">Conflict Solver</a></li>
+<li><a class="reference" href="http://www.gnumed.org/">Gnumed</a></li>
+<li>PyGist</li>
+<li><a class="reference" href="http://www.pythoncard.org/">PythonCard</a></li>
+<li><a class="reference" href="http://rpy.sourceforge.net/">RPy</a></li>
+<li><a class="reference" href="http://www.scipy.org/">SciPy</a></li>
+<li><a class="reference" href="http://www.sim42.org/">Sim42</a></li>
+<li><a class="reference" href="http://linus.yorktown.arlington.k12.va.us/CS/APCSC/student_sites/David_Mayo/wxGasp">wxGasp</a></li>
+</ul>
+</div>
+<div class="section" id="history-of-changes">
+<h1><a class="toc-backref" href="#id17" name="history-of-changes">History of changes</a></h1>
+<p>This section lists all the changes that have been made to the Py
+programs and modules, since the beginning.</p>
+<div class="section" id="to-2004">
+<h2><a class="toc-backref" href="#id18" name="to-2004">0.9.4 (1/25/2004 to //2004)</a></h2>
+<p>Removed wxd decorators in favor of new SWIG-generated docstrings.</p>
+<p>Removed docs tabs from crust interface:
+* wxPython Docs
+* wxSTC Docs</p>
+</div>
+<div class="section" id="to-1-24-2004">
+<h2><a class="toc-backref" href="#id19" name="to-1-24-2004">0.9.3 (9/25/2003 to 1/24/2004)</a></h2>
+<p>Fun and games with dynamic renaming. Details of any other changes
+were lost in the confusion. I'll try to do better in the future.</p>
+</div>
+<div class="section" id="to-9-25-2003">
+<h2><a class="toc-backref" href="#id20" name="to-9-25-2003">0.9.2 (5/3/2003 to 9/25/2003)</a></h2>
+<p>Changed to the new prefix-less "wx" package:</p>
+<pre class="literal-block">
+import wx
+</pre>
+<p>instead of:</p>
+<pre class="literal-block">
+from wxPython import wx
+</pre>
+<p>Fixed typo in <tt class="literal"><span class="pre">PyWrap.py</span></tt>:</p>
+<pre class="literal-block">
+if __name__ == '__main__':
+ main(sys.argv)
+</pre>
+<p>should have been:</p>
+<pre class="literal-block">
+if __name__ == '__main__':
+ main()
+</pre>
+<p>Added pretty-print Display tab to Crust, based on suggestion from
+Jason Whitlark.</p>
+<p>Improved <tt class="literal"><span class="pre">Can*</span></tt> checks in <tt class="literal"><span class="pre">EditWindow</span></tt>, since STC is too lenient,
+particularly when it is set to read-only but returns True for
+CanPaste() (seems like an STC bug to me):</p>
+<pre class="literal-block">
+def CanCopy(self):
+ """Return True if text is selected and can be copied."""
+ return self.GetSelectionStart() != self.GetSelectionEnd()
+
+def CanCut(self):
+ """Return True if text is selected and can be cut."""
+ return self.CanCopy() and self.CanEdit()
+
+def CanEdit(self):
+ """Return True if editing should succeed."""
+ return not self.GetReadOnly()
+
+def CanPaste(self):
+ """Return True if pasting should succeed."""
+ return stc.StyledTextCtrl.CanPaste(self) and self.CanEdit()
+</pre>
+</div>
+<div class="section" id="to-5-2-2003">
+<h2><a class="toc-backref" href="#id21" name="to-5-2-2003">0.9.1 (3/21/2003 to 5/2/2003)</a></h2>
+<p>PyCrust is dead! Long live Py!</p>
+<ul class="simple">
+<li>Renamed <tt class="literal"><span class="pre">PyCrust</span></tt> package to <tt class="literal"><span class="pre">py</span></tt>.</li>
+<li>Moved code to wxPython's CVS repository.</li>
+</ul>
+<p>Fixed bug in <tt class="literal"><span class="pre">introspect.py</span></tt> on introspecting objects occurring
+immediately after a secondary prompt, like this:</p>
+<pre class="literal-block">
+>>> l = [1, 2, 3]
+>>> for n in range(3):
+... l. <-- failed to popup autocomplete list
+</pre>
+<p>Added documentation files:</p>
+<ul class="simple">
+<li>PyManual.txt</li>
+<li>wxPythonManual.txt</li>
+<li>wxPythonPackage.txt</li>
+<li>wxPythonExamples.txt</li>
+</ul>
+<p>Added PyAlaMode and PyAlaCarte code editors.</p>
+<p>Major refactoring to support <tt class="literal"><span class="pre">editor</span></tt> and <tt class="literal"><span class="pre">shell</span></tt> from the same
+base.</p>
+<p>Renamed program files:</p>
+<ul class="simple">
+<li><tt class="literal"><span class="pre">PyCrustApp.py</span></tt> to <tt class="literal"><span class="pre">PyCrust.py</span></tt></li>
+<li><tt class="literal"><span class="pre">PyFillingApp.py</span></tt> to <tt class="literal"><span class="pre">PyFilling.py</span></tt></li>
+<li><tt class="literal"><span class="pre">PyShellApp.py</span></tt> to <tt class="literal"><span class="pre">PyShell.py</span></tt></li>
+<li><tt class="literal"><span class="pre">wrap.py</span></tt> to <tt class="literal"><span class="pre">PyWrap.py</span></tt></li>
+</ul>
+<p>Removed disabling of autocomplete for lists of 2000 items or more.
+The current implementation of wxSTC can now handle lists this big.</p>
+<p>Improved handling of <tt class="literal"><span class="pre">sys.path</span></tt> to mimic the standard Python shell.</p>
+</div>
+<div class="section" id="to-3-20-2003">
+<h2><a class="toc-backref" href="#id22" name="to-3-20-2003">0.9 (2/27/2003 to 3/20/2003)</a></h2>
+<p>Added fontIncrease, fontDecrease, fontDefault signals, receivers and
+keybindings:</p>
+<pre class="literal-block">
+Ctrl+] Increase font size.
+Ctrl+[ Decrease font size.
+Ctrl+= Default font size.
+</pre>
+<p>Continued enhancement of the decorator capability to provide better
+documentation and docstrings for wxPython classes and functions.</p>
+<p>Introduced new tabbed interface:</p>
+<ul class="simple">
+<li>Namespace</li>
+<li>Calltip</li>
+<li>Session</li>
+<li>Dispatcher</li>
+<li>wxPython Docs</li>
+<li>wxSTC Docs</li>
+</ul>
+<p><tt class="literal"><span class="pre">Filling.tree</span></tt> now expands tuples as well as lists. (It should have
+done this all along, I just never noticed this omission before.)</p>
+<p>Added this True/False test to all modules:</p>
+<pre class="literal-block">
+try:
+ True
+except NameError:
+ True = 1==1
+ False = 1==0
+</pre>
+<p>Added <tt class="literal"><span class="pre">wxd</span></tt> directory with decoration classes.</p>
+</div>
+<div class="section" id="to-2-26-2003">
+<h2><a class="toc-backref" href="#id23" name="to-2-26-2003">0.8.2 (1/5/2003 to 2/26/2003)</a></h2>
+<p>Wrapped <tt class="literal"><span class="pre">sys.ps1</span></tt>, <tt class="literal"><span class="pre">sys.ps2</span></tt>, and <tt class="literal"><span class="pre">sys.ps3</span></tt> in <tt class="literal"><span class="pre">str()</span></tt>.
+(Thanks, Kieran Holland.)</p>
+<p>Fixed minor things found by PyChecker.</p>
+<p>Changed locals to use <tt class="literal"><span class="pre">__main__.__dict__</span></tt> and added code to clean up
+the namespace, making it as close to the regular Python environment as
+possible. This solves the problem of pickling and unpickling
+instances of classes defined in the shell.</p>
+<p>Made <tt class="literal"><span class="pre">shell.PasteAndRun()</span></tt> a little more forgiving when it finds a
+ps2 prompt line with no trailing space, such when you copy code from a
+web page.</p>
+<p>Improved autocomplete behavior by adding these to shell:</p>
+<pre class="literal-block">
+self.AutoCompSetAutoHide(False)
+self.AutoCompStops(' .,;:([)]}\'"\\<>%^&+-=*/|`')
+</pre>
+<p>Added <tt class="literal"><span class="pre">decor</span></tt> directory, <tt class="literal"><span class="pre">decorator.py</span></tt>, <tt class="literal"><span class="pre">stcDecor.py</span></tt>, and
+<tt class="literal"><span class="pre">stcConstants.py</span></tt>. These all serve the purpose of adding docstrings
+to existing wxPython classes, in particular the <tt class="literal"><span class="pre">wxStyledTextCtrl</span></tt>.</p>
+<p>Added <tt class="literal"><span class="pre">wrap.py</span></tt>, a command line utility for running a wxPython app
+with additional runtime-tools loaded, such as PyCrust (the only tool
+at this point).</p>
+<p>Flushed the clipboard Cut/Copy operations so that selections will
+exist in the clipboard even after PyCrust has been closed.</p>
+<p>Improved the suppression of docstrings for simple data types appearing
+in the namespace viewer.</p>
+<p>Better handling of autocompletion with numeric types; no
+autocompletion when typing a dot after an integer. If the
+autocompletion is desired, type a space before the dot:</p>
+<pre class="literal-block">
+func = 3 .
+</pre>
+<p>More Filling!!! The namespace tree is now dynamically updated.</p>
+</div>
+<div class="section" id="to-12-25-2002">
+<h2><a class="toc-backref" href="#id24" name="to-12-25-2002">0.8.1 (12/20/2002 to 12/25/2002)</a></h2>
+<p>Improved keyboard handling with Autocomplete active. You can now use
+Enter as well as Tab to select an item from the list.</p>
+<p>Disabled autocomplete for lists of 2000 items or more. The current
+implementation of wxSTC can't handle lists this big.</p>
+<p>Changed <tt class="literal"><span class="pre">filling</span></tt> to always display docstrings for objects. This is
+useful for objects whose docstrings have been decorated, rather than
+coming directly from the source code. (Hmmm. Sounds like someone is
+doing some decorating. I wonder where that would be helpful? <wink>)</p>
+<p>Fixed handling of icon. Added <tt class="literal"><span class="pre">images.py</span></tt> file.</p>
+</div>
+<div class="section" id="to-12-16-2002">
+<h2><a class="toc-backref" href="#id25" name="to-12-16-2002">0.8 (10/29/2002 to 12/16/2002)</a></h2>
+<p>Added "help" to startup banner info.</p>
+<p>Made all <tt class="literal"><span class="pre">wx</span></tt> and <tt class="literal"><span class="pre">stc</span></tt> imports explicit. No more <tt class="literal"><span class="pre">import</span> <span class="pre">*</span></tt>.</p>
+<p>Replaced use of the <tt class="literal"><span class="pre">wx</span></tt> module's <tt class="literal"><span class="pre">true</span></tt> and <tt class="literal"><span class="pre">false</span></tt> with
+Python's <tt class="literal"><span class="pre">True</span></tt> and <tt class="literal"><span class="pre">False</span></tt>.</p>
+<p>Changed <tt class="literal"><span class="pre">introspect.getRoot()</span></tt> to use <tt class="literal"><span class="pre">tokenize</span></tt> module. This
+does a slightly better job than the previous parsing routine and the
+code is clearer.</p>
+<p>Improved handling of whitespace and empty types during introspection.</p>
+<p>Fixed cut/copy clipboard problem under Linux. (Robin Dunn rocks!!!)</p>
+<p>Added shell.about() which works like this:</p>
+<pre class="literal-block">
+>>> shell.about()
+PyCrust Version: 0.8
+Shell Revision: 1.80
+Interpreter Revision: 1.15
+Python Version: 2.2.2
+wxPython Version: 2.3.3.1
+Platform: linux2
+</pre>
+<p>Added copy plus and paste plus to shell menu.</p>
+<p>Moved shell menu from <tt class="literal"><span class="pre">shell.py</span></tt> to <tt class="literal"><span class="pre">shellmenu.py</span></tt>.</p>
+<p>Added <tt class="literal"><span class="pre">sys.stdin.readlines()</span></tt> support.</p>
+<p>Added <tt class="literal"><span class="pre">time.sleep()</span></tt> in <tt class="literal"><span class="pre">readline()</span></tt> and <tt class="literal"><span class="pre">OnIdle()</span></tt> event
+handler to free up the CPU.</p>
+</div>
+<div class="section" id="to-8-27-2002">
+<h2><a class="toc-backref" href="#id26" name="to-8-27-2002">0.7.2 (2/22/2002 to 8/27/2002)</a></h2>
+<p>Tweaked <tt class="literal"><span class="pre">getAttributeNames()</span></tt> to pick up a few more attributes:</p>
+<pre class="literal-block">
+'__bases__', '__class__', '__dict__', '__name__', 'func_closure',
+'func_code', 'func_defaults', 'func_dict', 'func_doc',
+'func_globals', 'func_name'
+</pre>
+<p>Added a tests directory and unit tests.</p>
+<p>Improved support for empty types in the shell: <tt class="literal"><span class="pre">[]</span></tt>, <tt class="literal"><span class="pre">()</span></tt> and
+<tt class="literal"><span class="pre">{}</span></tt> as far as when call tips and autocompletion are available.</p>
+<p>Added support for the other triple string - <tt class="literal"><span class="pre">''''''</span></tt>.</p>
+<p>Refactored <tt class="literal"><span class="pre">introspect.py</span></tt> to improve testability.</p>
+<p>Improved call tips for unbound methods by leaving the "self"
+parameter, since unbound methods require an instance be passed.</p>
+<p>Fixed call tip bug where a tip was displayed when a "(" was typed
+after an object that wasn't callable.</p>
+<p>Fixed <tt class="literal"><span class="pre">getAllAttributeNames</span></tt> when <tt class="literal"><span class="pre">str(object)</span></tt> fails.</p>
+<p>Added brace highlighting. (Thank you, Kevin Altis.)</p>
+<p>Fixed problem displaying unicode objects in <tt class="literal"><span class="pre">PyFilling</span></tt>.</p>
+<p>Changed how <tt class="literal"><span class="pre">filling.py</span></tt> checks for expandable objects. Lists are
+now expandable objects.</p>
+<p>Made the key handling more robust when there is an active text
+selection that includes text prior to the last primary prompt. Thanks
+to Raul Cota for pointing this out.</p>
+<p>Fixed wxSTC problem with brace highlighting and non-us keyboards.
+(Thank you for the patch, Jean-Michel Fauth.)</p>
+<p>Added <tt class="literal"><span class="pre">busy</span> <span class="pre">=</span> <span class="pre">wxBusyCursor()</span></tt> to key points in <tt class="literal"><span class="pre">shell</span></tt> and
+<tt class="literal"><span class="pre">filling</span></tt>.</p>
+<p>Added <tt class="literal"><span class="pre">OnCloseWindow</span></tt> handler to <tt class="literal"><span class="pre">ShellFrame</span></tt> and <tt class="literal"><span class="pre">CrustFrame</span></tt>.</p>
+<p>Default to <tt class="literal"><span class="pre">SetWrapMode(1)</span></tt> for shell and namespace viewer.</p>
+<p>Added <tt class="literal"><span class="pre">shell.wrap()</span></tt> and <tt class="literal"><span class="pre">shell.zoom()</span></tt>.</p>
+<p>Added autoCompleteKeys hooks for Raul Cota.</p>
+<p>Cleaned up various little key handling bugs.</p>
+<p>Changed input methods to get values from shell, rather than dialog
+boxes. Renamed <tt class="literal"><span class="pre">readIn</span></tt> to <tt class="literal"><span class="pre">readline</span></tt> and <tt class="literal"><span class="pre">readRaw</span></tt> to
+<tt class="literal"><span class="pre">raw_input</span></tt>.</p>
+</div>
+<div class="section" id="to-2-21-2002">
+<h2><a class="toc-backref" href="#id27" name="to-2-21-2002">0.7.1 (12/12/2001 to 2/21/2002)</a></h2>
+<p>Fixed <tt class="literal"><span class="pre">OnChar()</span></tt> issues effecting European keyboards, as reported by
+Jean-Michel Fauth.</p>
+<p>Fixed <tt class="literal"><span class="pre">introspect.py</span></tt> issue with xmlrpc objects reported by Kevin
+Altis.</p>
+<p>Fixed some introspect/PyFilling issues with regard to Python 2.2.</p>
+<p>Fixed font background color as reported by Keith J. Farmer. (Thanks)</p>
+<p>Fixed problem with call tips and autocompletion inside multiline
+commands as report by Kevin Altis.</p>
+<p>Improved <tt class="literal"><span class="pre">OnKeyDown</span></tt> handling of cut/copy/paste operations based on
+feedback from Syver Enstad. (Thanks)</p>
+<p>Added a <tt class="literal"><span class="pre">shell.help()</span></tt> method to display some help info.</p>
+<p>Changed sort of items in the namespace viewer to case insensitive.</p>
+<p>Changed <tt class="literal"><span class="pre">attributes.sort(lambda</span> <span class="pre">x,</span> <span class="pre">y:</span> <span class="pre">cmp(x.upper(),</span> <span class="pre">y.upper()))</span></tt> in
+advance of an upcoming fix to an autocompletion matching bug in wxSTC.</p>
+<p>Improved support for ZODB by allowing namespace drilldown into BTrees.</p>
+<p>Added <tt class="literal"><span class="pre">shell.PasteAndRun()</span></tt> to support pasting multiple commands into
+the shell from the clipboard. Ctrl+Shift+V or v.</p>
+<p>Enter now always processes a command (or copies down a previous one.)
+To insert a line break, press Ctrl+Enter.</p>
+<p>Escape key clears the current, unexecuted command.</p>
+<p>History retrieval changed to replace current command. Added new keys
+to insert from history - Shift+Up and Shift+Down.</p>
+<p>Better call tips on objects with <tt class="literal"><span class="pre">__call__</span></tt> methods.</p>
+<p>Improved call tip positioning calculation.</p>
+</div>
+<div class="section" id="to-12-11-2001">
+<h2><a class="toc-backref" href="#id28" name="to-12-11-2001">0.7 (10/15/2001 to 12/11/2001)</a></h2>
+<p>Changed how command history retrieval functions work. Added Alt-P,
+Alt-N as keybindings for Retrieve-Previous, Retrieve-Next.</p>
+<p>Added full support for multi-line commands, similar to IDLE.</p>
+<p>Changed <tt class="literal"><span class="pre">introspect.getAttributeNames()</span></tt> to do a case insensitive
+sort.</p>
+<p>Changed Cut/Copy/Paste to deal with prompts intelligently. Cut and
+Copy remove all prompts. Paste can handle prompted or not-prompted
+text.</p>
+<p>Added <tt class="literal"><span class="pre">CopyWithPrompts()</span></tt> method attached to Ctrl-Shift-C for those
+times when you really do want all the prompts left intact.</p>
+<p>Improved handling of the shell's read-only zone.</p>
+<p>Changed <tt class="literal"><span class="pre">CrustFrame.__init__</span></tt> parameter spec to include all
+parameters allowed by a <tt class="literal"><span class="pre">wxFrame</span></tt>.</p>
+<p>Changed <tt class="literal"><span class="pre">FillingText</span></tt> to be read-only.</p>
+<p>Renamed <tt class="literal"><span class="pre">PyCrust.py</span></tt> to <tt class="literal"><span class="pre">PyCrustApp.py</span></tt> to eliminate
+package/module name conflicts that kept you from doing <tt class="literal"><span class="pre">from</span> <span class="pre">PyCrust</span>
+<span class="pre">import</span> <span class="pre">shell</span></tt> inside files located in the <tt class="literal"><span class="pre">PyCrust</span></tt> directory.</p>
+<p>Renamed <tt class="literal"><span class="pre">PyFilling.py</span></tt> to <tt class="literal"><span class="pre">PyFillingApp.py</span></tt> and <tt class="literal"><span class="pre">PyShell.py</span></tt> to
+<tt class="literal"><span class="pre">PyShellApp.py</span></tt> to maintain consistency.</p>
+<p>Removed the <tt class="literal"><span class="pre">__date__</span></tt> property from all modules.</p>
+<p>Fixed bug in <tt class="literal"><span class="pre">introspect.getCallTip()</span></tt>, reported by Kevin Altis.</p>
+</div>
+<div class="section" id="to-10-12-2001">
+<h2><a class="toc-backref" href="#id29" name="to-10-12-2001">0.6.1 (9/19/2001 to 10/12/2001)</a></h2>
+<p>Changed <tt class="literal"><span class="pre">Shell.run()</span></tt> to always position to the end of existing
+text, as suggested by Raul Cota.</p>
+<p>Changed <tt class="literal"><span class="pre">introspect.getAllAttributeNames()</span></tt> to break circular
+references in <tt class="literal"><span class="pre">object.__class__</span></tt>, which occurs in Zope/ZODB
+extension classes.</p>
+<p>Changed <tt class="literal"><span class="pre">filling.FillingTree.getChildren()</span></tt> to introspect extension
+classes.</p>
+<p>Fixed minor bugs in <tt class="literal"><span class="pre">introspect.getCallTip()</span></tt> that were interfering
+with call tips for Zope/ZODB extension class methods.</p>
+<p>In preparation for wxPython 2.3.2, added code to fix a font sizing
+problem. Versions of wxPython prior to 2.3.2 had a sizing bug on Win
+platform where the font was 2 points larger than what was specified.</p>
+<p>Added a hack to <tt class="literal"><span class="pre">introspect.getAllAttributeNames()</span></tt> to "wake up"
+ZODB objects that are asleep - in a "ghost" state. Otherwise it
+returns incomplete info.</p>
+</div>
+<div class="section" id="to-9-12-2001">
+<h2><a class="toc-backref" href="#id30" name="to-9-12-2001">0.6 (8/21/2001 to 9/12/2001)</a></h2>
+<p>Added <tt class="literal"><span class="pre">PyFilling.py</span></tt> and <tt class="literal"><span class="pre">filling.py</span></tt>.</p>
+<p><tt class="literal"><span class="pre">PyShell.py</span></tt> and <tt class="literal"><span class="pre">PyFilling.py</span></tt> can now be run standalone, as well
+as <tt class="literal"><span class="pre">PyCrust.py</span></tt>.</p>
+<p>Added <tt class="literal"><span class="pre">crust.py</span></tt> and moved some code from <tt class="literal"><span class="pre">PyCrust.py</span></tt> to it.</p>
+<p>Added command history retrieval features submitted by Richie Hindle.</p>
+<p>Changed <tt class="literal"><span class="pre">shell.write()</span></tt> to replace line endings with OS-specific
+endings. Changed <tt class="literal"><span class="pre">shell.py</span></tt> and <tt class="literal"><span class="pre">interpreter.py</span></tt> to use
+<tt class="literal"><span class="pre">os.linesep</span></tt> in strings having hardcoded line endings.</p>
+<p>Added <tt class="literal"><span class="pre">shell.redirectStdin()</span></tt>, <tt class="literal"><span class="pre">shell.redirectStdout()</span></tt> and
+<tt class="literal"><span class="pre">shell.redirectStderr()</span></tt> to allow the surrounding app to toggle
+requests that the specified <tt class="literal"><span class="pre">sys.std*</span></tt> be redirected to the shell.
+These can also be run from within the shell itself, of course.</p>
+<p>The shell now adds the current working directory "." to the search
+path:</p>
+<pre class="literal-block">
+sys.path.insert(0, os.curdir)
+</pre>
+<p>Added support for distutils installations.</p>
+</div>
+<div class="section" id="to-8-20-2001">
+<h2><a class="toc-backref" href="#id31" name="to-8-20-2001">0.5.4 (8/17/2001 to 8/20/2001)</a></h2>
+<p>Changed default font size under Linux to:</p>
+<pre class="literal-block">
+'size' : 12,
+'lnsize' : 10,
+</pre>
+<p>Changed <tt class="literal"><span class="pre">Shell</span></tt> to expect a parameter referencing an Interpreter
+class, rather than an intepreter instance, to facilitate subclassing
+of Interpreter, which effectively broke when the Editor class was
+eliminated.</p>
+<p>Fixed <tt class="literal"><span class="pre">PyCrustAlaCarte.py</span></tt>, which had been broken by previous
+changes.</p>
+<p>Created <tt class="literal"><span class="pre">InterpreterAlaCarte</span></tt> class as an example for use in the
+demo.</p>
+<p>Split <tt class="literal"><span class="pre">PyCrust.py</span></tt> into <tt class="literal"><span class="pre">PyCrust.py</span></tt> and <tt class="literal"><span class="pre">PyShell.py</span></tt> in
+anticipation of <tt class="literal"><span class="pre">PyFilling.py</span></tt>.</p>
+</div>
+<div class="section" id="id1">
+<h2><a class="toc-backref" href="#id32" name="id1">0.5.3 (8/16/2001)</a></h2>
+<p>Added patch to <tt class="literal"><span class="pre">PyCrust.py</span></tt> to fix wxPython bug:</p>
+<pre class="literal-block">
+wxID_SELECTALL = NewId() # This *should* be defined by wxPython.
+</pre>
+</div>
+<div class="section" id="to-8-15-2001">
+<h2><a class="toc-backref" href="#id33" name="to-8-15-2001">0.5.2 (8/14/2001 to 8/15/2001)</a></h2>
+<p>Shortened module names by dropping "PyCrust" as a prefix.</p>
+<p>Changed <tt class="literal"><span class="pre">version</span></tt> to <tt class="literal"><span class="pre">VERSION</span></tt> in <tt class="literal"><span class="pre">version</span></tt> module.</p>
+<p>Added Options menu to PyCrust application.</p>
+<p>Eliminated the Editor class (and editor module) by merging with Shell.
+This means that Shell "is a" wxStyledTextCtrl rather than "has a".
+There just wasn't enough non-gui code to justify the separation.
+Plus, Shell will be much easier for gui toolkits/designers to deal
+with now.</p>
+</div>
+<div class="section" id="to-8-14-2001">
+<h2><a class="toc-backref" href="#id34" name="to-8-14-2001">0.5.1 (8/10/2001 to 8/14/2001)</a></h2>
+<p>Added <tt class="literal"><span class="pre">introspect</span></tt> module.</p>
+<p>Moved some functionality from <tt class="literal"><span class="pre">PyCrustInterp</span></tt> to <tt class="literal"><span class="pre">introspect</span></tt>.</p>
+<p>Changed <tt class="literal"><span class="pre">introspect.getRoot()</span></tt> to no longer remove whitespace from
+the command. This was a remnant of a previous approach that, when
+left as part of the current approach, turned out to be a really bad
+thing.</p>
+<p>Changed <tt class="literal"><span class="pre">introspect.getRoot()</span></tt> to allow commands of <tt class="literal"><span class="pre">''</span></tt>, <tt class="literal"><span class="pre">""</span></tt>,
+<tt class="literal"><span class="pre">""""""</span></tt>, <tt class="literal"><span class="pre">[]</span></tt>, <tt class="literal"><span class="pre">()</span></tt>, and <tt class="literal"><span class="pre">{}</span></tt> to pass through. This allows
+you to type them, followed by a dot, and get autocomplete options on
+them.</p>
+<p>Changed <tt class="literal"><span class="pre">introspect.getRoot()</span></tt> to identify some situations where
+strings shouldn't be considered roots. For example:</p>
+<pre class="literal-block">
+>>> import PyCrust # To illustrate the potential problem.
+>>> len('PyCrust.py')
+</pre>
+<p>Typing the dot at the end of "PyCrust" in the second line above should
+NOT result in an autocompletion list because "PyCrust" is part of a
+string in this context, not a reference to the PyCrust module object.
+Similar reasoning applies to call tips. For example:</p>
+<pre class="literal-block">
+>>> len('dir(')
+</pre>
+<p>Typing the left paren at the end of "dir" should NOT result in a call
+tip.</p>
+<p>Both features now behave properly in the examples given. However,
+there is still the case where whitespace precedes the potential root
+and that is NOT handled properly. For example:</p>
+<pre class="literal-block">
+>>> len('this is a dir(')
+</pre>
+<p>and:</p>
+<pre class="literal-block">
+>>> len('This is PyCrust.py')
+</pre>
+<p>More code needs to be written to handle more complex situations.</p>
+<p>Added <tt class="literal"><span class="pre">locals=None</span></tt> parameter to <tt class="literal"><span class="pre">Shell.__init__()</span></tt>.</p>
+<p>Added support for magic attribute retrieval. Users can change this
+with:</p>
+<pre class="literal-block">
+>>> shell.editor.autoCompleteIncludeMagic = 0
+</pre>
+<p>Added the ability to set filters on auto completion to exclude
+attributes prefixed with a single or double underscore. Users can
+exclude one or the other or both with:</p>
+<pre class="literal-block">
+>>> shell.editor.autoCompleteExcludeSingle = 1
+>>> shell.editor.autoCompleteExcludeDouble = 1
+</pre>
+</div>
+<div class="section" id="id2">
+<h2><a class="toc-backref" href="#id35" name="id2">0.5 (8/8/2001)</a></h2>
+<p>Mostly just a final version change before creating a release.</p>
+</div>
+<div class="section" id="to-8-7-2001">
+<h2><a class="toc-backref" href="#id36" name="to-8-7-2001">0.4 (8/4/2001 to 8/7/2001)</a></h2>
+<p>Changed version/revision handling.</p>
+<p>Fixed bugs.</p>
+</div>
+<div class="section" id="to-8-3-2001">
+<h2><a class="toc-backref" href="#id37" name="to-8-3-2001">0.3 (8/2/2001 to 8/3/2001)</a></h2>
+<p>Removed lots of cruft.</p>
+<p>Added lots of docstrings.</p>
+<p>Imported to CVS repository at SourceForge.</p>
+<p>Added call tips.</p>
+</div>
+<div class="section" id="to-8-2-2001">
+<h2><a class="toc-backref" href="#id38" name="to-8-2-2001">0.2 (7/30/2001 to 8/2/2001)</a></h2>
+<p>Renamed several files.</p>
+<p>Added command autocompletion.</p>
+<p>Added menus to PyCrust.py: File, Edit and Help.</p>
+<p>Added sample applications: <tt class="literal"><span class="pre">PyCrustAlaCarte.py</span></tt>,
+<tt class="literal"><span class="pre">PyCrustAlaMode.py</span></tt>, and <tt class="literal"><span class="pre">PyCrustMinimus.py</span></tt>.</p>
+</div>
+<div class="section" id="to-7-19-2001">
+<h2><a class="toc-backref" href="#id39" name="to-7-19-2001">0.1 (7/1/2001 to 7/19/2001)</a></h2>
+<p>Added basic syntax coloring much like Boa.</p>
+<p>Added read-only logging much like IDLE.</p>
+<p>Can retrieve a previous command by putting the cursor back on that
+line and hitting enter.</p>
+<p>Stdin and raw_input operate properly so you can now do <tt class="literal"><span class="pre">help()</span></tt> and
+<tt class="literal"><span class="pre">license()</span></tt> without hanging.</p>
+<p>Redefined "quit", "exit", and "close" to display a better-than-nothing
+response.</p>
+<p>Home key honors the prompt.</p>
+<p>Created SourceForge account, but nothing was posted.</p>
+</div>
+<div class="section" id="in-the-beginning-there-was-pie-7-1-2001">
+<h2><a class="toc-backref" href="#id40" name="in-the-beginning-there-was-pie-7-1-2001">In the beginning, there was pie... (7/1/2001)</a></h2>
+<p>Blame it all on IDLE, Boa and PythonWin. I was using all three, got
+frustrated with their dissimilarities, and began to let everyone know
+how I felt. At the same time, Scintilla looked like an interesting
+tool to build a shell around. And while I didn't receive much in the
+way of positive feedback, let alone encouragement, I just couldn't let
+go of the idea of a Scintilla-based Python shell. Then the PythonCard
+project got to the point where they were talking about including a
+shell in their development environment. That was all the incentive I
+needed. PyCrust had to happen...</p>
+</div>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
This section lists all the changes that have been made to the Py
programs and modules, since the beginning.
-.. include:: ../wxPython/py/CHANGES.txt
+.. include:: ../wx/py/CHANGES.txt
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document">
+<div class="section" id="wxpython-readme">
+<h1><a name="wxpython-readme">wxPython README</a></h1>
+<p>Welcome to the wonderful world of wxPython!</p>
+<p>So where do you go from here? The best thing to do is to run the demo
+and use its source code to help you learn how to use wxPython. Most
+of the classes available are demonstrated there, and you can view the
+sources directly in the demo so it is designed to help you learn. If
+you are on Windows or OS X then you can run the demo just by double
+clicking it's icon. If you are on Linux/Unix then change to the
+directory containing the demo and type:</p>
+<blockquote>
+python demo.py</blockquote>
+<p>There are also some sample mini applications available for you to run
+and to play with as a learning exercise.</p>
+<p>The next thing you should do is join the wxPython-users maillist where
+you can interact with a community of other users and developers who
+are willing to help you learn, answer questions and solve problems.
+To join the mail list just go to this web page and follow the
+instructions there:</p>
+<blockquote>
+<a class="reference" href="http://wxpython.org/maillist.php">http://wxpython.org/maillist.php</a></blockquote>
+<p>There is also a good set of class reference documentation available
+for wxPython, but currently it is geared for the C++ user. This may
+be a little daunting at first, but with a little practice you'll
+easily be able to "mentally translate" from the C++ shown into Python.
+(See <a class="reference" href="http://wiki.wxpython.org/index.cgi/C_2b_2bGuideForwxPythoneers">http://wiki.wxpython.org/index.cgi/C_2b_2bGuideForwxPythoneers</a>
+for a little help on this process.) Not all classes documented are
+available in Python, but most of the GUI related classes are.</p>
+</div>
+<div class="section" id="other-info">
+<h1><a name="other-info">Other Info</a></h1>
+<p>Please also see the following files:</p>
+<blockquote>
+<dl>
+<dt>docs/CHANGES.txt Information about new features, fixes,</dt>
+<dd>etc. in each release.</dd>
+<dt>docs/BUILD.txt Instructions for building wxPython on</dt>
+<dd>various Unix-like platforms, OS X or
+Windows.</dd>
+<dt>docs/MigrationGuide.txt Information about some big changes from 2.4</dt>
+<dd>to 2.5 that require changes to your
+applications</dd>
+</dl>
+<p>licence/* Text of the wxWindows license.</p>
+</blockquote>
+<p>--
+Robin Dunn
+<a class="reference" href="mailto:robin@alldunn.com">robin@alldunn.com</a></p>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
------------------
+--
Robin Dunn
robin@alldunn.com
-[options]
-
+[general]
output_encoding: iso-8859-1
-source-link: 1
+source_link: 0
datestamp: %Y-%m-%d %H:%M UTC
-generator: 1
+generator: 0
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>The wxPython wx Package</title>
+<meta name="author" content="Patrick K. O'Brien" />
+<meta name="author" content="Robin Dunn" />
+<meta name="organization" content="Orbtech" />
+<meta name="date" content="2003-07-02" />
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="the-wxpython-wx-package">
+<h1 class="title">The wxPython wx Package</h1>
+<h2 class="subtitle" id="or-how-to-survive-the-new-wx-namespace-changes">Or, how to survive the new wx namespace changes.</h2>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr><th class="docinfo-name">Author:</th>
+<td>Patrick K. O'Brien</td></tr>
+<tr><th class="docinfo-name">Author:</th>
+<td>Robin Dunn</td></tr>
+<tr><th class="docinfo-name">Contact:</th>
+<td><a class="first last reference" href="mailto:pobrien@orbtech.com">pobrien@orbtech.com</a></td></tr>
+<tr><th class="docinfo-name">Organization:</th>
+<td><a class="first last reference" href="http://www.orbtech.com/">Orbtech</a></td></tr>
+<tr><th class="docinfo-name">Date:</th>
+<td>2003-07-02</td></tr>
+<tr><th class="docinfo-name">Revision:</th>
+<td>1.2</td></tr>
+</tbody>
+</table>
+<div class="contents topic" id="contents">
+<p class="topic-title"><a name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#introduction" id="id2" name="id2">Introduction</a></li>
+<li><a class="reference" href="#why-change-anything" id="id3" name="id3">Why change anything?</a></li>
+<li><a class="reference" href="#what-does-the-new-wx-package-do" id="id4" name="id4">What does the new wx package do?</a></li>
+<li><a class="reference" href="#will-any-of-this-effect-my-existing-code" id="id5" name="id5">Will any of this effect my existing code?</a></li>
+<li><a class="reference" href="#what-about-all-the-other-modules-like-grid-html-and-stc" id="id6" name="id6">What about all the other modules, like grid, html, and stc?</a></li>
+<li><a class="reference" href="#how-do-i-use-this-new-wx-package" id="id7" name="id7">How do I use this new wx package?</a></li>
+<li><a class="reference" href="#what-are-the-issues-with-converting-old-code-to-use-the-new-wx-package" id="id8" name="id8">What are the issues with converting old code to use the new wx package?</a></li>
+<li><a class="reference" href="#where-can-i-find-example-programs-using-the-new-wx-syntax" id="id9" name="id9">Where can I find example programs using the new wx syntax?</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h1><a class="toc-backref" href="#id2" name="introduction">Introduction</a></h1>
+<p>In the begining there was Python, and Python had modules, and Python
+was good. But after a time Guido looked on Python and saw that Python
+needed organizational assistance, and so Guido took code from Python's
+side and created Packages and then Python was very good. About this
+time wxPython was reborn, and wxPython used Packages, but being young
+and trying to use a new technology wxPython did not know how to use
+Packages effectivly. wxPython was good, but dreamed of being much
+better...</p>
+<p>Now many years later, after tons of code reorganization and build
+hacking wxPython has reached that goal. In version 2.4.1 a prototype
+of this new structure was introduced that dynamically built at import
+time a new toplevel package named simply "wx" that contained all the
+items from wxPython.wx but with the names edited to remove the wx
+prefix. Now in 2.5 the final phase of that switcheroo has been
+completed and the <em>real</em> classes, functions and constants are now
+located in the wx package, leaving some compatibility modules in
+wxPython.wx. This document should answer all the questions you might
+have concerning the new wx package. Please also take a look at the
+<a class="reference" href="MigrationGuide.html">2.5 Migration Guide</a> to see notes about other big differences in
+this release.</p>
+</div>
+<div class="section" id="why-change-anything">
+<h1><a class="toc-backref" href="#id3" name="why-change-anything">Why change anything?</a></h1>
+<p>This change is being made for a couple of reasons. The first reason
+is to discourage the use of <tt class="literal"><span class="pre">import</span> <span class="pre">*</span></tt>, which is a dangerous
+technique that can create name conflicts and bloated namespaces.</p>
+<p>The second reason is to remove what some perceive to be a "wart." For
+example, the following code is rather ugly in that the "wx" prefix on
+the wxFrame class name is no longer useful when you're using the wx
+module prefix:</p>
+<pre class="literal-block">
+from wxPython import wx
+
+class Frame(wx.wxFrame)
+</pre>
+<p>The new wx package allows you to write code like this, instead:</p>
+<pre class="literal-block">
+import wx
+
+class Frame(wx.Frame)
+</pre>
+<p>The third reason is that the wxWindows project has considered doing
+the same thing (implement a new wx namespace and drop the "wx" prefix)
+and we want wxPython to lead the way.</p>
+</div>
+<div class="section" id="what-does-the-new-wx-package-do">
+<h1><a class="toc-backref" href="#id4" name="what-does-the-new-wx-package-do">What does the new wx package do?</a></h1>
+<p>As mentioned in the Introduction, wxPython 2.4.1 introduced a way of
+getting to this new syntax as quickly as possible. It would import
+the old names (like "wxFrame") from the old package and then create new
+names in the wx package without the wx prefix, (like "Frame".)
+Starting with wxPython 2.5 the renaming is moved up to the wxPython
+build step, so the real classes and etc. are actually named with the
+new name (like "Frame") and are located in the new wx package.</p>
+<p>For compatibility the old wxPython package still exists, but now it is
+populated with modules that simply import the new names and then
+"reverse-renames" them to the old names. It probably sounds a bit
+complicated, but it is mostly automated and so it doesn't cause
+problems in most cases.</p>
+</div>
+<div class="section" id="will-any-of-this-effect-my-existing-code">
+<h1><a class="toc-backref" href="#id5" name="will-any-of-this-effect-my-existing-code">Will any of this effect my existing code?</a></h1>
+<p>No. Your existing code will continue to work and be supported for
+some time. It will be up to you to decide when to switch to the new
+syntax. But all new documentation and code examples will use the new
+syntax. So don't wait too long. You wouldn't want anyone calling you
+old-fashioned, would you?</p>
+<p>When you import from wxPython.wx and use a class with the old name,
+such as wxButton, you are actually using the wx.Button class. I
+expect that the vast majority of the existing code should work fine
+using this scheme. The only things that may cause problems is if your
+old code is depending on some of the implemtation details, or if you
+are using other things that have changed in the API. See the
+<a class="reference" href="MigrationGuide.html">Migration Guide</a> for more details.</p>
+</div>
+<div class="section" id="what-about-all-the-other-modules-like-grid-html-and-stc">
+<h1><a class="toc-backref" href="#id6" name="what-about-all-the-other-modules-like-grid-html-and-stc">What about all the other modules, like grid, html, and stc?</a></h1>
+<p>There's more to the old wxPython than just the wxPython.wx module.
+And we've got those extra modules covered as well. Each of those
+modules (as well as the lib subpackage) has been moved to the new wx
+package and reverse-renamers have been placed in the wxPython package
+as needed.</p>
+</div>
+<div class="section" id="how-do-i-use-this-new-wx-package">
+<h1><a class="toc-backref" href="#id7" name="how-do-i-use-this-new-wx-package">How do I use this new wx package?</a></h1>
+<p>The wx package is automatically created when you install wxPython
+version 2.4.1 or higher. So all you have to do is:</p>
+<pre class="literal-block">
+import wx
+</pre>
+</div>
+<div class="section" id="what-are-the-issues-with-converting-old-code-to-use-the-new-wx-package">
+<h1><a class="toc-backref" href="#id8" name="what-are-the-issues-with-converting-old-code-to-use-the-new-wx-package">What are the issues with converting old code to use the new wx package?</a></h1>
+<p>Obviously, you need to change your import statements from:</p>
+<pre class="literal-block">
+from wxPython import wx
+</pre>
+<p>or:</p>
+<pre class="literal-block">
+from wxPython.wx import *
+</pre>
+<p>to:</p>
+<pre class="literal-block">
+import wx
+</pre>
+<p>Then you need to refer to wx attributes without a "wx" prefix, such
+as:</p>
+<pre class="literal-block">
+class MyFrame(wx.Frame):
+</pre>
+<p>In most cases, existing code can be modified with a simple search and
+replace.</p>
+</div>
+<div class="section" id="where-can-i-find-example-programs-using-the-new-wx-syntax">
+<h1><a class="toc-backref" href="#id9" name="where-can-i-find-example-programs-using-the-new-wx-syntax">Where can I find example programs using the new wx syntax?</a></h1>
+<p>Example programs are included in the wxPython/samples/wx_examples
+directory, and are documented in the <a class="reference" href="wxPythonExamples.html">wxPythonExamples</a> documentation
+file. Also, all the code in the py package uses the new wx syntax.
+You can learn more about these in the <a class="reference" href="PyManual.html">PyManual</a>.</p>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
--------------------------------------------------
:Author: Patrick K. O'Brien
+:Author: Robin Dunn
:Contact: pobrien@orbtech.com
:Organization: Orbtech_
:Date: $Date$
Introduction
============
-Big things sometimes come in small packages. This is certainly true
-of the new wx package, which is being introduced in wxPython 2.4.1 as
-a way to allow the "wx" prefix to be dropped from the names of all
-wxPython classes, functions, and constants. This document should
-answer all the questions you might have concerning the new wx package.
-If not, feel free to contact the author. I hope you like the new wx
-package as much as I do.
-
+In the begining there was Python, and Python had modules, and Python
+was good. But after a time Guido looked on Python and saw that Python
+needed organizational assistance, and so Guido took code from Python's
+side and created Packages and then Python was very good. About this
+time wxPython was reborn, and wxPython used Packages, but being young
+and trying to use a new technology wxPython did not know how to use
+Packages effectivly. wxPython was good, but dreamed of being much
+better...
+
+Now many years later, after tons of code reorganization and build
+hacking wxPython has reached that goal. In version 2.4.1 a prototype
+of this new structure was introduced that dynamically built at import
+time a new toplevel package named simply "wx" that contained all the
+items from wxPython.wx but with the names edited to remove the wx
+prefix. Now in 2.5 the final phase of that switcheroo has been
+completed and the *real* classes, functions and constants are now
+located in the wx package, leaving some compatibility modules in
+wxPython.wx. This document should answer all the questions you might
+have concerning the new wx package. Please also take a look at the
+`2.5 Migration Guide`_ to see notes about other big differences in
+this release.
+
+.. _2.5 Migration Guide: MigrationGuide.html
Why change anything?
====================
class Frame(wx.Frame)
-The third reason is that the wxWindows project intends to do the same
-thing (implement a new wx namespace and drop the "wx" prefix) and we
-want wxPython to lead the way.
+The third reason is that the wxWindows project has considered doing
+the same thing (implement a new wx namespace and drop the "wx" prefix)
+and we want wxPython to lead the way.
What does the new wx package do?
================================
-As a way of getting to this new syntax as quickly as possible, the
-code in this new wx package was created. What it does is alter the
-existing wx namespace dynamically. By making the changes on-the-fly
-at runtime, we can try out the new syntax before any permanent changes
-are made to the underlying class library. The downside of making
-these changes at runtime is that there is a slight delay when you
-``import wx``; the upside is that you can start using the new syntax
-now.
+As mentioned in the Introduction, wxPython 2.4.1 introduced a way of
+getting to this new syntax as quickly as possible. It would import
+the old names (like "wxFrame") from the old package and then create new
+names in the wx package without the wx prefix, (like "Frame".)
+Starting with wxPython 2.5 the renaming is moved up to the wxPython
+build step, so the real classes and etc. are actually named with the
+new name (like "Frame") and are located in the new wx package.
+
+For compatibility the old wxPython package still exists, but now it is
+populated with modules that simply import the new names and then
+"reverse-renames" them to the old names. It probably sounds a bit
+complicated, but it is mostly automated and so it doesn't cause
+problems in most cases.
Will any of this effect my existing code?
syntax. So don't wait too long. You wouldn't want anyone calling you
old-fashioned, would you?
+When you import from wxPython.wx and use a class with the old name,
+such as wxButton, you are actually using the wx.Button class. I
+expect that the vast majority of the existing code should work fine
+using this scheme. The only things that may cause problems is if your
+old code is depending on some of the implemtation details, or if you
+are using other things that have changed in the API. See the
+`Migration Guide`_ for more details.
-How does the new wx package work?
-=================================
-
-It's pretty simple, and pretty clever. The wx directory contains an
-``__init__.py`` file, making it a Python package. (In contrast, the
-old wxPython.wx module is a module, not a package.) When you ``import
-wx`` the code in the ``__init__.py`` file is executed, and that's
-where all the magic takes place. Let's take a look at the code inside
-the ``__init__.py`` file:
-
-.. include:: ../wx/__init__.py
- :literal:
-
-Namespaces in Python are implemented as dictionaries. The dictionary
-used to create the wx package's namespace is accessible using the
-``globals()`` function. The dictionary used to create the old
-wxPython.wx module's namespace is ``wx.__dict__``. Once we have these
-two dictionaries, it's a simple matter of iterating through one,
-changing the names, adding the renamed object to the other dictionary,
-and cleaning up a few local variables and imported modules. Voila!
+.. _Migration Guide: MigrationGuide.html
What about all the other modules, like grid, html, and stc?
===========================================================
-There's more to wxPython than just the wx namespace. And we've got
-those extra modules covered as well. For each of those modules (as
-well as the lib package) we've got matching modules in the new wx
-package. Let's take a look at a few of them.
-
-Here is ``html.py``:
-
-.. include:: ../wx/html.py
- :literal:
-
-And here is ``lib/dialogs.py``:
-
-.. include:: ../wx/lib/dialogs.py
- :literal:
-
-As you can see, they both rely on the ``prefix.rename()`` function
-defined in ``prefix.py``:
-
-.. include:: ../wx/prefix.py
- :literal:
-
-Again, the technique is very similar to the one used by the wx
-package.
+There's more to the old wxPython than just the wxPython.wx module.
+And we've got those extra modules covered as well. Each of those
+modules (as well as the lib subpackage) has been moved to the new wx
+package and reverse-renamers have been placed in the wxPython package
+as needed.
How do I use this new wx package?
In most cases, existing code can be modified with a simple search and
replace.
-One extra issue you might run into when converting existing code is
-that the wx.__version__ attribute is no longer available, since the
-new wx namespace doesn't include any private attributes from the old
-wxPython.wx namespace. The solution is to use the wx.VERSION_STRING
-attribute, which was introduced in wxPython 2.4.1.
Where can I find example programs using the new wx syntax?
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>wxPython Documentation</title>
+<meta name="author" content="Patrick K. O'Brien" />
+<meta name="organization" content="Orbtech" />
+<meta name="date" content="2003-07-02" />
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="wxpython-documentation">
+<h1 class="title">wxPython Documentation</h1>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr><th class="docinfo-name">Author:</th>
+<td>Patrick K. O'Brien</td></tr>
+<tr><th class="docinfo-name">Contact:</th>
+<td><a class="first last reference" href="mailto:pobrien@orbtech.com">pobrien@orbtech.com</a></td></tr>
+<tr><th class="docinfo-name">Organization:</th>
+<td><a class="first last reference" href="http://www.orbtech.com/">Orbtech</a></td></tr>
+<tr><th class="docinfo-name">Date:</th>
+<td>2003-07-02</td></tr>
+<tr><th class="docinfo-name">Revision:</th>
+<td>1.2</td></tr>
+</tbody>
+</table>
+<div class="section" id="wxpython-manual">
+<h1><a name="wxpython-manual">wxPython Manual</a></h1>
+<p><a class="reference" href="wxPythonManual.html">The wxPython Manual</a> is a reference to the wxPython toolkit.</p>
+</div>
+<div class="section" id="wxpython-developer-reference">
+<h1><a name="wxpython-developer-reference">wxPython Developer Reference</a></h1>
+<p><a class="reference" href="http://www.orbtech.com/www/wx/epydoc/">The wxPython source code documentation</a> is for developers, and was
+created using the Epydoc tool.</p>
+</div>
+<div class="section" id="wxpython-tutorial">
+<h1><a name="wxpython-tutorial">wxPython Tutorial</a></h1>
+<p><a class="reference" href="wxPythonTutorial.html">The wxPython Tutorial</a> will help get you started with wxPython.</p>
+</div>
+<div class="section" id="wxpython-examples">
+<h1><a name="wxpython-examples">wxPython Examples</a></h1>
+<p><a class="reference" href="wxPythonExamples.html">The wxPython Examples</a> illustrates example programs using wxPython.</p>
+</div>
+<div class="section" id="wx-package">
+<h1><a name="wx-package">wx Package</a></h1>
+<p><a class="reference" href="wxPackage.html">The wxPython wx Package</a> explains the new prefix-less wx package.</p>
+</div>
+<div class="section" id="py-manual">
+<h1><a name="py-manual">Py Manual</a></h1>
+<p><a class="reference" href="PyManual.html">The Py Manual</a> documents the Py collection of programs and source
+code modules, including:</p>
+<ul class="simple">
+<li>PyAlaCarte</li>
+<li>PyAlaMode</li>
+<li>PyCrust</li>
+<li>PyFilling</li>
+<li>PyShell</li>
+<li>PyWrap</li>
+</ul>
+</div>
+<div class="section" id="py-developer-reference">
+<h1><a name="py-developer-reference">Py Developer Reference</a></h1>
+<p><a class="reference" href="http://www.orbtech.com/www/wx/epydoc/public/wx.py-module.html">The Py source code documentation</a> is for developers, and was created
+using the Epydoc tool.</p>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>Example Programs Using wxPython</title>
+<meta name="author" content="Patrick K. O'Brien" />
+<meta name="organization" content="Orbtech" />
+<meta name="date" content="2003-07-02" />
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="example-programs-using-wxpython">
+<h1 class="title">Example Programs Using wxPython</h1>
+<h2 class="subtitle" id="a-survival-guide-for-the-post-wx-prefixed-world">A survival guide for the post-wx-prefixed world.</h2>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr><th class="docinfo-name">Author:</th>
+<td>Patrick K. O'Brien</td></tr>
+<tr><th class="docinfo-name">Contact:</th>
+<td><a class="first last reference" href="mailto:pobrien@orbtech.com">pobrien@orbtech.com</a></td></tr>
+<tr><th class="docinfo-name">Organization:</th>
+<td><a class="first last reference" href="http://www.orbtech.com/">Orbtech</a></td></tr>
+<tr><th class="docinfo-name">Date:</th>
+<td>2003-07-02</td></tr>
+<tr><th class="docinfo-name">Revision:</th>
+<td>1.2</td></tr>
+</tbody>
+</table>
+<div class="contents topic" id="contents">
+<p class="topic-title"><a name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#introduction" id="id1" name="id1">Introduction</a></li>
+<li><a class="reference" href="#background-with-tongue-firmly-in-cheek" id="id2" name="id2">Background (with tongue firmly in cheek)</a></li>
+<li><a class="reference" href="#basic-program-example" id="id3" name="id3">Basic Program Example</a></li>
+<li><a class="reference" href="#hello-wxpython-example" id="id4" name="id4">Hello wxPython Example</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h1><a class="toc-backref" href="#id1" name="introduction">Introduction</a></h1>
+<p>This document illustrates example programs using wxPython. All the
+examples make use of the new wx package syntax introduced in wxPython
+2.4.1, which is a bit different than older examples you might come
+across.</p>
+</div>
+<div class="section" id="background-with-tongue-firmly-in-cheek">
+<h1><a class="toc-backref" href="#id2" name="background-with-tongue-firmly-in-cheek">Background (with tongue firmly in cheek)</a></h1>
+<p>If something hits you on the head, don't run around screaming that the
+sky is falling. Instead, take a close look and see if it wasn't a
+"wx" prefix that hit you. Apparently, they're dropping off wxPython
+class names like flies dropping dead in the scorching heat of a
+summer's day.</p>
+<p>Yes, the world is changing, and even our little wxPython world must
+change with it. Then again, I'm not fond of pesky summertime flies,
+and I'm not too upset that the "wx" prefixes are going to bite the
+dust. I think it's for the best. But, being the kind, considerate
+person that I am, I decided to write this guide to make the wx
+namespace transition easier for everyone, even Chicken Little.</p>
+<div class="note">
+<p class="admonition-title">Note</p>
+<p>Say what?</p>
+<p>If you have no idea what I mean by the "wx namespace transition,"
+consider yourself lucky. You can simply use these examples to
+learn wxPython in its current state (beginning with wxPython
+version 2.4.1). All you need to know is that previous wxPython
+code used a slightly different syntax that some folks (including
+me) considered ugly. So we changed it. And that's when the sky
+starting falling...</p>
+<p>If you want more of the technical details, read the <a class="reference" href="wxPackage.html">wx package
+documentation</a>.</p>
+</div>
+<p>Rather than simply <strong>tell</strong> you that everything will be okay, I
+decided to <strong>show</strong> you that everything will be okay. To do that,
+I've created a bunch of example programs using the new wx package. I
+hope you like them.</p>
+</div>
+<div class="section" id="basic-program-example">
+<h1><a class="toc-backref" href="#id3" name="basic-program-example">Basic Program Example</a></h1>
+<p>It doesn't get much simpler than this. Every wxPython program needs
+an application and a frame. To encourage good coding habits, I've
+split them into separate modules. They don't do much, but they're a
+good starting point.</p>
+<p>I include a simple App class in the frame module because the PyWrap
+"wrapper" utility (<tt class="literal"><span class="pre">pywrap</span></tt>) only works with modules that contain an
+application class. So including a simple one in each of your frame
+modules allows you to use the PyWrap runtime wrapper and debug your
+frames independent of your full application.</p>
+<p>Here is the module (<tt class="literal"><span class="pre">frame.py</span></tt>) that defines the frame class:</p>
+<pre class="literal-block">
+#!/usr/bin/env python
+
+"""Basic frame class, with App for testing."""
+
+__author__ = "Patrick K. O'Brien <pobrien@orbtech.com>"
+__cvsid__ = "$Id$"
+__revision__ = "$Revision$"[11:-2]
+
+import wx
+
+class Frame(wx.Frame):
+ """Frame class."""
+
+ def __init__(self, parent=None, id=-1, title='Title',
+ pos=wx.DefaultPosition, size=(400, 200)):
+ """Create a Frame instance."""
+ wx.Frame.__init__(self, parent, id, title, pos, size)
+
+class App(wx.App):
+ """Application class."""
+
+ def OnInit(self):
+ self.frame = Frame()
+ self.frame.Show()
+ self.SetTopWindow(self.frame)
+ return True
+
+def main():
+ app = App()
+ app.MainLoop()
+
+if __name__ == '__main__':
+ main()
+
+</pre>
+<p>And here is the module (<tt class="literal"><span class="pre">app.py</span></tt>) that defines the application class
+and imports the frame from <tt class="literal"><span class="pre">frame.py</span></tt>:</p>
+<pre class="literal-block">
+#!/usr/bin/env python
+
+"""Basic application class."""
+
+__author__ = "Patrick K. O'Brien <pobrien@orbtech.com>"
+__cvsid__ = "$Id$"
+__revision__ = "$Revision$"[11:-2]
+
+import wx
+
+from frame import Frame
+
+class App(wx.App):
+ """Application class."""
+
+ def OnInit(self):
+ self.frame = Frame()
+ self.frame.Show()
+ self.SetTopWindow(self.frame)
+ return True
+
+def main():
+ app = App()
+ app.MainLoop()
+
+if __name__ == '__main__':
+ main()
+
+</pre>
+</div>
+<div class="section" id="hello-wxpython-example">
+<h1><a class="toc-backref" href="#id4" name="hello-wxpython-example">Hello wxPython Example</a></h1>
+<p>This program displays an image file (<tt class="literal"><span class="pre">wxPython.jpg</span></tt>) inside a frame
+sized to match the graphic.</p>
+<div class="figure">
+<p><img alt="screenshots/hello-win98.png" scale="100" src="screenshots/hello-win98.png" /></p>
+<p class="caption">Running <tt class="literal"><span class="pre">hello.py</span></tt> on Windows.</p>
+</div>
+<div class="figure">
+<p><img alt="screenshots/hello-linux.png" scale="100" src="screenshots/hello-linux.png" /></p>
+<p class="caption">Running <tt class="literal"><span class="pre">hello.py</span></tt> on Linux.</p>
+</div>
+<div class="figure">
+<p><img alt="screenshots/hello-mac.png" scale="100" src="screenshots/hello-mac.png" /></p>
+<p class="caption">Running <tt class="literal"><span class="pre">hello.py</span></tt> on Mac OS X.</p>
+</div>
+<p>Here is the source code for <tt class="literal"><span class="pre">hello.py</span></tt>:</p>
+<pre class="literal-block">
+#!/usr/bin/env python
+
+"""Hello, wxPython! program."""
+
+__author__ = "Patrick K. O'Brien <pobrien@orbtech.com>"
+__cvsid__ = "$Id$"
+__revision__ = "$Revision$"[11:-2]
+
+import wx
+
+class Frame(wx.Frame):
+ """Frame class that displays an image."""
+
+ def __init__(self, image, parent=None, id=-1,
+ pos=wx.DefaultPosition, title='Hello, wxPython!'):
+ """Create a Frame instance and display image."""
+ temp = image.ConvertToBitmap()
+ size = temp.GetWidth(), temp.GetHeight()
+ wx.Frame.__init__(self, parent, id, title, pos, size)
+ self.bmp = wx.StaticBitmap(parent=self, id=-1, bitmap=temp)
+
+class App(wx.App):
+ """Application class."""
+
+ def OnInit(self):
+ wx.InitAllImageHandlers()
+ image = wx.Image('wxPython.jpg', wx.BITMAP_TYPE_JPEG)
+ self.frame = Frame(image)
+ self.frame.Show()
+ self.SetTopWindow(self.frame)
+ return True
+
+def main():
+ app = App()
+ app.MainLoop()
+
+if __name__ == '__main__':
+ main()
+
+</pre>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>The wxPython Manual</title>
+<meta name="author" content="Patrick K. O'Brien" />
+<meta name="organization" content="Orbtech" />
+<meta name="date" content="2003-07-02" />
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="the-wxpython-manual">
+<h1 class="title">The wxPython Manual</h1>
+<h2 class="subtitle" id="a-guide-to-wxpython-for-python-programmers">A guide to wxPython for Python programmers</h2>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr><th class="docinfo-name">Author:</th>
+<td>Patrick K. O'Brien</td></tr>
+<tr><th class="docinfo-name">Contact:</th>
+<td><a class="first last reference" href="mailto:pobrien@orbtech.com">pobrien@orbtech.com</a></td></tr>
+<tr><th class="docinfo-name">Organization:</th>
+<td><a class="first last reference" href="http://www.orbtech.com/">Orbtech</a></td></tr>
+<tr><th class="docinfo-name">Date:</th>
+<td>2003-07-02</td></tr>
+<tr><th class="docinfo-name">Revision:</th>
+<td>1.2</td></tr>
+<tr class="field"><th class="docinfo-name">License:</th><td class="field-body">wxWindows Free Documentation Licence, Version 3</td>
+</tr>
+</tbody>
+</table>
+<div class="contents topic" id="contents">
+<p class="topic-title"><a name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#introduction" id="id1" name="id1">Introduction</a></li>
+<li><a class="reference" href="#what-is-wxpython" id="id2" name="id2">What is wxPython?</a></li>
+<li><a class="reference" href="#wxpython-requirements" id="id3" name="id3">wxPython requirements</a><ul>
+<li><a class="reference" href="#ms-windows" id="id4" name="id4">MS-Windows</a></li>
+<li><a class="reference" href="#linux-or-unix" id="id5" name="id5">Linux or Unix</a></li>
+<li><a class="reference" href="#mac-os-x" id="id6" name="id6">Mac OS X</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#what-is-wxwindows" id="id7" name="id7">What is wxWindows?</a></li>
+<li><a class="reference" href="#why-another-cross-platform-development-tool" id="id8" name="id8">Why another cross-platform development tool?</a></li>
+<li><a class="reference" href="#wxpython-overview" id="id9" name="id9">wxPython Overview</a></li>
+<li><a class="reference" href="#utilities-and-libraries-supplied-with-wxpython" id="id10" name="id10">Utilities and libraries supplied with wxPython</a></li>
+<li><a class="reference" href="#creating-and-deleting-wxpython-objects" id="id11" name="id11">Creating and deleting wxPython objects</a></li>
+<li><a class="reference" href="#app-overview" id="id12" name="id12">App overview</a><ul>
+<li><a class="reference" href="#application-initialization" id="id13" name="id13">Application initialization</a></li>
+<li><a class="reference" href="#application-shutdown" id="id14" name="id14">Application shutdown</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#sizer-overview" id="id15" name="id15">Sizer overview</a><ul>
+<li><a class="reference" href="#the-idea-behind-sizers" id="id16" name="id16">The idea behind sizers</a></li>
+<li><a class="reference" href="#common-features" id="id17" name="id17">Common features</a><ul>
+<li><a class="reference" href="#a-minimal-size" id="id18" name="id18">A minimal size</a></li>
+<li><a class="reference" href="#a-border" id="id19" name="id19">A border</a></li>
+<li><a class="reference" href="#an-alignment" id="id20" name="id20">An alignment</a></li>
+<li><a class="reference" href="#a-stretch-factor" id="id21" name="id21">A stretch factor</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#boxsizer" id="id22" name="id22">BoxSizer</a></li>
+<li><a class="reference" href="#staticboxsizer" id="id23" name="id23">StaticBoxSizer</a></li>
+<li><a class="reference" href="#gridsizer" id="id24" name="id24">GridSizer</a></li>
+<li><a class="reference" href="#flexgridsizer" id="id25" name="id25">FlexGridSizer</a></li>
+<li><a class="reference" href="#notebooksizer" id="id26" name="id26">NotebookSizer</a></li>
+<li><a class="reference" href="#programming-with-boxsizer" id="id27" name="id27">Programming with BoxSizer</a></li>
+<li><a class="reference" href="#programming-with-gridsizer" id="id28" name="id28">Programming with GridSizer</a></li>
+<li><a class="reference" href="#programming-with-flexgridsizer" id="id29" name="id29">Programming with FlexGridSizer</a></li>
+<li><a class="reference" href="#programming-with-notebooksizer" id="id30" name="id30">Programming with NotebookSizer</a></li>
+<li><a class="reference" href="#programming-with-staticboxsizer" id="id31" name="id31">Programming with StaticBoxSizer</a></li>
+<li><a class="reference" href="#dialog-createbuttonsizer" id="id32" name="id32">Dialog.CreateButtonSizer</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#date-and-time-classes-overview" id="id33" name="id33">Date and time classes overview</a><ul>
+<li><a class="reference" href="#all-date-time-classes-at-a-glance" id="id34" name="id34">All date/time classes at a glance</a></li>
+<li><a class="reference" href="#datetime-characteristics" id="id35" name="id35">DateTime characteristics</a></li>
+<li><a class="reference" href="#difference-between-datespan-and-timespan" id="id36" name="id36">Difference between DateSpan and TimeSpan</a></li>
+<li><a class="reference" href="#date-arithmetics" id="id37" name="id37">Date arithmetics</a></li>
+<li><a class="reference" href="#time-zone-considerations" id="id38" name="id38">Time zone considerations</a></li>
+<li><a class="reference" href="#daylight-saving-time-dst" id="id39" name="id39">Daylight saving time (DST)</a></li>
+<li><a class="reference" href="#datetime-and-holidays" id="id40" name="id40">DateTime and Holidays</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#classes-by-category" id="id41" name="id41">Classes by category</a></li>
+<li><a class="reference" href="#id-constants" id="id42" name="id42">ID constants</a></li>
+<li><a class="reference" href="#source-document" id="id43" name="id43">Source document</a></li>
+<li><a class="reference" href="#submitting-changes-to-the-source-document" id="id44" name="id44">Submitting changes to the source document</a></li>
+<li><a class="reference" href="#contributors" id="id45" name="id45">Contributors</a></li>
+<li><a class="reference" href="#license" id="id46" name="id46">License</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h1><a class="toc-backref" href="#id1" name="introduction">Introduction</a></h1>
+<p>This is a guide to the wxPython GUI toolkit, written <strong>by</strong> a Python
+programmer <strong>for</strong> his fellow Python programmers. It began as a
+simple translation of the wxWindows documentation (which is written
+for C++ programmers), and evolved from there. And while there's
+nothing wrong with C++...</p>
+<p>Okay, you got me there. I hate C++. That's why I use Python. If you
+like C++, go read the wxWindows documentation. If you'd rather read a
+guide that's written with Python programmers in mind, keep reading
+this one. If you like it, feel free to send me freshly roasted coffee
+beans, dark chocolate, and large denomination currency. Better yet,
+buy huge quantities of my wxPython book (written with Robin Dunn) and
+send one to each of your friends, relatives, and coworkers.</p>
+</div>
+<div class="section" id="what-is-wxpython">
+<h1><a class="toc-backref" href="#id2" name="what-is-wxpython">What is wxPython?</a></h1>
+<p>wxPython is a GUI toolkit for the Python programming language. It
+allows Python programmers to create programs with a robust, highly
+functional graphical user interface, simply and easily. It is
+implemented as a Python extension module (native code) that wraps the
+popular wxWindows cross platform GUI library, which is written in C++.</p>
+<p>Like Python and wxWindows, wxPython is Open Source, which means that
+it is free for anyone to use and the source code is available for
+anyone to look at and modify. And anyone can contribute fixes or
+enhnacments to the project.</p>
+<p>wxPython is a cross-platform toolkit. This means that the same
+program will run on multiple platforms without modification.
+Currently supported platforms are 32-bit Microsoft Windows, most Unix
+or unix-like systems, and Macintosh OS X.</p>
+<p>Since the language is Python, wxPython programs are simple, easy to
+write and easy to understand.</p>
+</div>
+<div class="section" id="wxpython-requirements">
+<h1><a class="toc-backref" href="#id3" name="wxpython-requirements">wxPython requirements</a></h1>
+<p>To make use of wxPython, you currently need one of the following
+setups.</p>
+<div class="section" id="ms-windows">
+<h2><a class="toc-backref" href="#id4" name="ms-windows">MS-Windows</a></h2>
+<ul class="simple">
+<li>A 486 or higher PC running MS Windows.</li>
+<li>At least ?? MB of disk space.</li>
+</ul>
+</div>
+<div class="section" id="linux-or-unix">
+<h2><a class="toc-backref" href="#id5" name="linux-or-unix">Linux or Unix</a></h2>
+<ul class="simple">
+<li>Almost any C++ compiler, including GNU C++ (EGCS 1.1.1 or above).</li>
+<li>Almost any Unix workstation, and one of: GTK+ 1.2, GTK+ 2.0, Motif
+1.2 or higher, Lesstif.</li>
+<li>At least ?? MB of disk space.</li>
+</ul>
+</div>
+<div class="section" id="mac-os-x">
+<h2><a class="toc-backref" href="#id6" name="mac-os-x">Mac OS X</a></h2>
+<ul class="simple">
+<li>A PowerPC Mac running Mac OS X 10.x.</li>
+<li>At least ?? MB of disk space.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="what-is-wxwindows">
+<h1><a class="toc-backref" href="#id7" name="what-is-wxwindows">What is wxWindows?</a></h1>
+<p>wxWindows is a C++ framework providing GUI (Graphical User Interface)
+and other facilities on more than one platform. Version 2 currently
+supports all desktop versions of MS Windows, Unix with GTK+, Unix with
+Motif, and MacOS. An OS/2 port is in progress.</p>
+<p>wxWindows was originally developed at the Artificial Intelligence
+Applications Institute, University of Edinburgh, for internal use, and
+was first made publicly available in 1992. Version 2 is a vastly
+improved version written and maintained by Julian Smart, Robert
+Roebling, Vadim Zeitlin, Vaclav Slavik and many others.</p>
+<p>Please note that in the following, "MS Windows" often refers to all
+platforms related to Microsoft Windows, including 16-bit and 32-bit
+variants, unless otherwise stated. All trademarks are acknowledged.</p>
+</div>
+<div class="section" id="why-another-cross-platform-development-tool">
+<h1><a class="toc-backref" href="#id8" name="why-another-cross-platform-development-tool">Why another cross-platform development tool?</a></h1>
+<p>wxWindows was developed to provide a cheap and flexible way to
+maximize investment in GUI application development. While a number of
+commercial class libraries already existed for cross-platform
+development, none met all of the following criteria:</p>
+<ul class="simple">
+<li>low price</li>
+<li>source availability</li>
+<li>simplicity of programming</li>
+<li>support for a wide range of compilers</li>
+</ul>
+<p>Since wxWindows was started, several other free or almost-free GUI
+frameworks have emerged. However, none has the range of features,
+flexibility, documentation and the well-established development team
+that wxWindows has.</p>
+<p>As open source software, wxWindows has benefited from comments, ideas,
+bug fixes, enhancements and the sheer enthusiasm of users. This gives
+wxWindows a certain advantage over its commercial competitors (and
+over free libraries without an independent development team), plus a
+robustness against the transience of one individual or company. This
+openness and availability of source code is especially important when
+the future of thousands of lines of application code may depend upon
+the longevity of the underlying class library.</p>
+<p>Version 2 goes much further than previous versions in terms of
+generality and features, allowing applications to be produced that are
+often indistinguishable from those produced using single-platform
+toolkits such as Motif, GTK+ and MFC.</p>
+<p>The importance of using a platform-independent class library cannot be
+overstated, since GUI application development is very time-consuming,
+and sustained popularity of particular GUIs cannot be guaranteed.
+Code can very quickly become obsolete if it addresses the wrong
+platform or audience. wxWindows helps to insulate the programmer from
+these winds of change. Although wxWindows may not be suitable for
+every application (such as an OLE-intensive program), it provides
+access to most of the functionality a GUI program normally requires,
+plus many extras such as network programming, PostScript output, and
+HTML rendering; and it can of course be extended as needs dictate. As
+a bonus, it provides a far cleaner and easier programming interface
+than the native APIs. Programmers may find it worthwhile to use
+wxWindows even if they are developing on only one platform.</p>
+<p>It is impossible to sum up the functionality of wxWindows in a few
+paragraphs, but here are some of the benefits:</p>
+<ul class="simple">
+<li>Low cost (free, in fact!)</li>
+<li>You get the source.</li>
+<li>Available on a variety of popular platforms.</li>
+<li>Works with almost all popular C++ compilers and Python.</li>
+<li>Over 50 example programs.</li>
+<li>Over 1000 pages of printable and on-line documentation.</li>
+<li>Includes Tex2RTF, to allow you to produce your own documentation in
+Windows Help, HTML and Word RTF formats.</li>
+<li>Simple-to-use, object-oriented API.</li>
+<li>Flexible event system.</li>
+<li>Graphics calls include lines, rounded rectangles, splines,
+polylines, etc.</li>
+<li>Constraint-based and sizer-based layouts.</li>
+<li>Print/preview and document/view architectures.</li>
+<li>Toolbar, notebook, tree control, advanced list control classes.</li>
+<li>PostScript generation under Unix, normal MS Windows printing on the
+PC.</li>
+<li>MDI (Multiple Document Interface) support.</li>
+<li>Can be used to create DLLs under Windows, dynamic libraries on Unix.</li>
+<li>Common dialogs for file browsing, printing, colour selection, etc.</li>
+<li>Under MS Windows, support for creating metafiles and copying them to
+the clipboard.</li>
+<li>An API for invoking help from applications.</li>
+<li>Ready-to-use HTML window (supporting a subset of HTML).</li>
+<li>Dialog Editor for building dialogs.</li>
+<li>Network support via a family of socket and protocol classes.</li>
+<li>Support for platform independent image processing.</li>
+<li>Built-in support for many file formats (BMP, PNG, JPEG, GIF, XPM,
+PNM, PCX).</li>
+</ul>
+</div>
+<div class="section" id="wxpython-overview">
+<h1><a class="toc-backref" href="#id9" name="wxpython-overview">wxPython Overview</a></h1>
+<p>To set a wxPython application going, you will need to derive an App
+class and override App.OnInit.</p>
+<p>An application must have a top-level Frame or Dialog window. Each
+frame may contain one or more instances of classes such as Panel,
+SplitterWindow or other windows and controls.</p>
+<p>A frame can have a MenuBar, a ToolBar, a status line, and an Icon for
+when the frame is iconized.</p>
+<p>A Panel is used to place controls (classes derived from Control) which
+are used for user interaction. Examples of controls are Button,
+CheckBox, Choice, ListBox, RadioBox, Slider.</p>
+<p>Instances of Dialog can also be used for controls, and they have the
+advantage of not requiring a separate frame.</p>
+<p>Instead of creating a dialog box and populating it with items, it is
+possible to choose one of the convenient common dialog classes, such
+as MessageDialog and FileDialog.</p>
+<p>You never draw directly onto a window. Instead, you use a device
+context (DC). DC is the base for ClientDC, PaintDC, MemoryDC,
+PostScriptDC, MemoryDC, MetafileDC and PrinterDC. If your drawing
+functions have DC as a parameter, you can pass any of these DCs to the
+function, and thus use the same code to draw to several different
+devices. You can draw using the member functions of DC, such as
+DC.DrawLine and DC.DrawText. Control colour on a window (Colour) with
+brushes (Brush) and pens (Pen).</p>
+<!-- To intercept events, you add a DECLARE_EVENT_TABLE macro to the
+window class declaration, and put a BEGIN_EVENT_TABLE
+... END_EVENT_TABLE block in the implementation file. Between these
+macros, you add event macros which map the event (such as a mouse
+click) to a member function. These might override predefined event
+handlers such as for KeyEvent and MouseEvent. -->
+<p>Most modern applications will have an on-line, hypertext help system;
+for this, you need Help and the HelpController class to control
+Help.</p>
+<p>GUI applications aren't all graphical wizardry. You'll also need
+lists and hash tables. But since you're working with Python, you
+should use the ones Python provides (list, tuple, dict), rather than
+the wxWindows versions. Same goes for the database related classes.
+The basic rule of thumb is this: If you can do it directly in Python,
+you probably should. If there is a reason not to use a Python data
+type, wxPython will provide a wrapper for the wxWindows class.</p>
+<p>You will undoubtedly need some platform-independent file functions,
+and you may find it handy to maintain and search a list of paths using
+PathList. There's a miscellany of operating system and other
+functions.</p>
+<p>See also Classes by Category for a list of classes.</p>
+</div>
+<div class="section" id="utilities-and-libraries-supplied-with-wxpython">
+<h1><a class="toc-backref" href="#id10" name="utilities-and-libraries-supplied-with-wxpython">Utilities and libraries supplied with wxPython</a></h1>
+<p>In addition to the core wxWindows library, a number of further
+libraries and utilities are supplied with each distribution.</p>
+<p>[Need to list these.]</p>
+</div>
+<div class="section" id="creating-and-deleting-wxpython-objects">
+<h1><a class="toc-backref" href="#id11" name="creating-and-deleting-wxpython-objects">Creating and deleting wxPython objects</a></h1>
+<p>[This section needs to be reviewed.]</p>
+<!-- In general, classes derived from wxWindow must dynamically
+allocated with new and deleted with delete. If you delete a window,
+all of its children and descendants will be automatically deleted,
+so you don't need to delete these descendants explicitly. -->
+<!-- When deleting a frame or dialog, use Destroy rather than delete so
+that the wxWindows delayed deletion can take effect. This waits
+until idle time (when all messages have been processed) to actually
+delete the window, to avoid problems associated with the GUI
+sending events to deleted windows. -->
+<!-- If you decide to allocate a C++ array of objects (such as wxBitmap)
+that may be cleaned up by wxWindows, make sure you delete the array
+explicitly before wxWindows has a chance to do so on exit, since
+calling delete on array members will cause memory problems. -->
+<!-- wxColour can be created statically: it is not automatically cleaned
+up and is unlikely to be shared between other objects; it is
+lightweight enough for copies to be made. -->
+<!-- Beware of deleting objects such as a wxPen or wxBitmap if they are
+still in use. Windows is particularly sensitive to this: so make
+sure you make calls like wxDC::SetPen(wxNullPen) or
+wxDC::SelectObject(wxNullBitmap) before deleting a drawing object
+that may be in use. Code that doesn't do this will probably work
+fine on some platforms, and then fail under Windows. -->
+</div>
+<div class="section" id="app-overview">
+<h1><a class="toc-backref" href="#id12" name="app-overview">App overview</a></h1>
+<p>Classes: wx.App</p>
+<div class="section" id="application-initialization">
+<h2><a class="toc-backref" href="#id13" name="application-initialization">Application initialization</a></h2>
+<p>The OnInit method defined for a class derived from wx.App will usually
+create a top window as a bare minimum.</p>
+<p>OnInit must return a boolean value to indicate whether processing
+should continue (True) or not (False). You call App.SetTopWindow to
+let wxPython know about the top window.</p>
+<p>An application closes by destroying all windows. Because all frames
+must be destroyed for the application to exit, it is advisable to use
+parent frames wherever possible when creating new frames, so that
+deleting the top level frame will automatically delete child frames.
+The alternative is to explicitly delete child frames in the top-level
+frame's CloseEvent handler.</p>
+<p>In emergencies the wx.Exit() function can be called to kill the
+application, however, normally the application shuts down
+automatically, see below.</p>
+<p>An example of defining an application follows:</p>
+<pre class="literal-block">
+import wx
+
+from frame import Frame
+
+class App(wx.App):
+ """Application class."""
+
+ def OnInit(self):
+ self.frame = Frame()
+ self.frame.Show()
+ self.SetTopWindow(self.frame)
+ return True
+
+def main():
+ app = App()
+ app.MainLoop()
+
+if __name__ == '__main__':
+ main()
+</pre>
+</div>
+<div class="section" id="application-shutdown">
+<h2><a class="toc-backref" href="#id14" name="application-shutdown">Application shutdown</a></h2>
+<p>The application normally shuts down when the last of its top level
+windows is closed. This is normally the expected behaviour and means
+that it is enough to call Close() in response to the "Exit" menu
+command if your program has a single top level window. If this
+behaviour is not desirable, App.SetExitOnFrameDelete can be called to
+change it. Note that such logic doesn't apply for the windows shown
+before the program enters the main loop: in other words, you can
+safely show a dialog from App.OnInit and not be afraid that your
+application terminates when this dialog -- which is the last top level
+window for the moment -- is closed.</p>
+<p>Another aspect of the application shutdown is the OnExit which is
+called when the application exits but before wxPython cleans up its
+internal structures. You should delete all wxPython objects that you
+created by the time OnExit finishes.</p>
+<p>For example, this code may crash:</p>
+<p>[Need examples of objects needing cleanup to keep app from crashing.]</p>
+</div>
+</div>
+<div class="section" id="sizer-overview">
+<h1><a class="toc-backref" href="#id15" name="sizer-overview">Sizer overview</a></h1>
+<p>Classes: wx.Sizer, wx.GridSizer, wx.FlexGridSizer, wx.BoxSizer,
+wx.StaticBoxSizer, wx.NotebookSizer, wx.CreateButtonSizer</p>
+<table border class="table">
+<colgroup>
+<col width="21%" />
+<col width="79%" />
+</colgroup>
+<tbody valign="top">
+<tr><td>Sizer</td>
+<td>Abstract base class.</td>
+</tr>
+<tr><td>GridSizer</td>
+<td>A sizer for laying out windows in a grid with all
+fields having the same size.</td>
+</tr>
+<tr><td>FlexGridSizer</td>
+<td>A sizer for laying out windows in a flexible grid.</td>
+</tr>
+<tr><td>BoxSizer</td>
+<td>A sizer for laying out windows in a row or column.</td>
+</tr>
+<tr><td>StaticBoxSizer</td>
+<td>Same as BoxSizer, but with a surrounding static box.</td>
+</tr>
+<tr><td>NotebookSizer</td>
+<td>Sizer to use with the Notebook control.</td>
+</tr>
+</tbody>
+</table>
+<p>Sizers, as represented by the wx.Sizer class and its descendants in
+the wxPython class hierarchy, have become the method of choice to
+define the layout of controls in dialogs in wxPython because of their
+ability to create visually appealing dialogs independent of the
+platform, taking into account the differences in size and style of the
+individual controls. Editors such as wxDesigner, wxrcedit, XRCed and
+wxWorkshop create dialogs based exclusively on sizers, practically
+forcing the user to create platform independent layouts without
+compromises.</p>
+<div class="section" id="the-idea-behind-sizers">
+<h2><a class="toc-backref" href="#id16" name="the-idea-behind-sizers">The idea behind sizers</a></h2>
+<p>The layout algorithm used by sizers in wxPython is closely related to
+layout systems in other GUI toolkits, such as Java's AWT, the GTK
+toolkit or the Qt toolkit. It is based upon the idea of individual
+subwindows reporting their minimal required size and their ability to
+get stretched if the size of the parent window has changed. This will
+most often mean that the programmer does not set the start-up size of
+a dialog, the dialog will rather be assigned a sizer and this sizer
+will be queried about the recommended size. This sizer in turn will
+query its children (which can be normal windows, empty space or other
+sizers) so that a hierarchy of sizers can be constructed. Note that
+wx.Sizer does not derive from wx.Window and thus does not interfere
+with tab ordering and requires very few resources compared to a real
+window on screen.</p>
+<p>What makes sizers so well fitted for use in wxPython is the fact that
+every control reports its own minimal size and the algorithm can
+handle differences in font sizes or different window (dialog item)
+sizes on different platforms without problems. For example, if the
+standard font as well as the overall design of Linux/GTK widgets
+requires more space than on Windows, the initial dialog size will
+automatically be bigger on Linux/GTK than on Windows.</p>
+<p>There are currently five different kinds of sizers available in
+wxPython. Each represents either a certain way to lay out dialog items
+in a dialog or it fulfils a special task such as wrapping a static box
+around a dialog item (or another sizer). These sizers will be
+discussed one by one in the text below.</p>
+</div>
+<div class="section" id="common-features">
+<h2><a class="toc-backref" href="#id17" name="common-features">Common features</a></h2>
+<p>All sizers are containers, that is, they are used to lay out one
+dialog item (or several dialog items), which they contain. Such items
+are sometimes referred to as the children of the sizer. Independent
+of how the individual sizers lay out their children, all children have
+certain features in common:</p>
+<div class="section" id="a-minimal-size">
+<h3><a class="toc-backref" href="#id18" name="a-minimal-size">A minimal size</a></h3>
+<p>This minimal size is usually identical to the initial size of the
+controls and may either be set explicitly in the size field of the
+control constructor or may be calculated by wxPython, typically by
+setting the height and/or the width of the item to -1. Note that only
+some controls can calculate their size (such as a checkbox) whereas
+others (such as a listbox) don't have any natural width or height and
+thus require an explicit size. Some controls can calculate their
+height, but not their width (e.g. a single line text control):</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="a-border">
+<h3><a class="toc-backref" href="#id19" name="a-border">A border</a></h3>
+<p>The border is just empty space and is used to separate dialog items in
+a dialog. This border can either be all around, or at any combination
+of sides such as only above and below the control. The thickness of
+this border must be set explicitly, typically 5 points. The following
+samples show dialogs with only one dialog item (a button) and a border
+of 0, 5, and 10 pixels around the button:</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="an-alignment">
+<h3><a class="toc-backref" href="#id20" name="an-alignment">An alignment</a></h3>
+<p>Often, a dialog item is given more space than its minimal size plus
+its border. Depending on what flags are used for the respective dialog
+item, the dialog item can be made to fill out the available space
+entirely, i.e. it will grow to a size larger than the minimal size, or
+it will be moved to either the centre of the available space or to
+either side of the space. The following sample shows a listbox and
+three buttons in a horizontal box sizer; one button is centred, one is
+aligned at the top, one is aligned at the bottom:</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="a-stretch-factor">
+<h3><a class="toc-backref" href="#id21" name="a-stretch-factor">A stretch factor</a></h3>
+<p>If a sizer contains more than one child and it is offered more space
+than its children and their borders need, the question arises how to
+distribute the surplus space among the children. For this purpose, a
+stretch factor may be assigned to each child, where the default value
+of 0 indicates that the child will not get more space than its
+requested minimum size. A value of more than zero is interpreted in
+relation to the sum of all stretch factors in the children of the
+respective sizer, i.e. if two children get a stretch factor of 1, they
+will get half the extra space each independent of whether one control
+has a minimal sizer inferior to the other or not. The following
+sample shows a dialog with three buttons, the first one has a stretch
+factor of 1 and thus gets stretched, whereas the other two buttons
+have a stretch factor of zero and keep their initial width:</p>
+<p>[Need graphics]</p>
+<p>Within wxDesigner, this stretch factor gets set from the Option menu.</p>
+</div>
+</div>
+<div class="section" id="boxsizer">
+<h2><a class="toc-backref" href="#id22" name="boxsizer">BoxSizer</a></h2>
+<p>BoxSizer can lay out its children either vertically or horizontally,
+depending on what flag is being used in its constructor. When using a
+vertical sizer, each child can be centered, aligned to the right or
+aligned to the left. Correspondingly, when using a horizontal sizer,
+each child can be centered, aligned at the bottom or aligned at the
+top. The stretch factor described in the last paragraph is used for
+the main orientation, i.e. when using a horizontal box sizer, the
+stretch factor determines how much the child can be stretched
+horizontally. The following sample shows the same dialog as in the
+last sample, only the box sizer is a vertical box sizer now:</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="staticboxsizer">
+<h2><a class="toc-backref" href="#id23" name="staticboxsizer">StaticBoxSizer</a></h2>
+<p>StaticBoxSixer is the same as a BoxSizer, but surrounded by a static
+box. Here is a sample:</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="gridsizer">
+<h2><a class="toc-backref" href="#id24" name="gridsizer">GridSizer</a></h2>
+<p>GridSizer is a two-dimensional sizer. All children are given the same
+size, which is the minimal size required by the biggest child, in this
+case the text control in the left bottom border. Either the number of
+columns or the number or rows is fixed and the grid sizer will grow in
+the respectively other orientation if new children are added:</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="flexgridsizer">
+<h2><a class="toc-backref" href="#id25" name="flexgridsizer">FlexGridSizer</a></h2>
+<p>Another two-dimensional sizer derived from GridSizer. The width of
+each column and the height of each row are calculated individually
+according the minimal requirements from the respectively biggest
+child. Additionally, columns and rows can be declared to be
+stretchable if the sizer is assigned a size different from that which
+it requested. The following sample shows the same dialog as the one
+above, but using a flex grid sizer:</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="notebooksizer">
+<h2><a class="toc-backref" href="#id26" name="notebooksizer">NotebookSizer</a></h2>
+<p>NotebookSizer can be used with notebooks. It calculates the size of
+each notebook page and sets the size of the notebook to the size of
+the biggest page plus some extra space required for the notebook tabs
+and decorations.</p>
+<p>[Need graphics]</p>
+</div>
+<div class="section" id="programming-with-boxsizer">
+<h2><a class="toc-backref" href="#id27" name="programming-with-boxsizer">Programming with BoxSizer</a></h2>
+<p>The basic idea behind a BoxSizer is that windows will most often be
+laid out in rather simple basic geometry, typically in a row or a
+column or several hierarchies of either.</p>
+<p>As an example, we will construct a dialog that will contain a text
+field at the top and two buttons at the bottom. This can be seen as a
+top-hierarchy column with the text at the top and buttons at the
+bottom and a low-hierarchy row with an OK button to the left and a
+Cancel button to the right. In many cases (particularly dialogs under
+Unix and normal frames) the main window will be resizable by the user
+and this change of size will have to get propagated to its children.
+In our case, we want the text area to grow with the dialog, whereas
+the button shall have a fixed size. In addition, there will be a thin
+border around all controls to make the dialog look nice and - to make
+matter worse - the buttons shall be centred as the width of the dialog
+changes.</p>
+<p>It is the unique feature of a box sizer, that it can grow in both
+directions (height and width) but can distribute its growth in the
+main direction (horizontal for a row) unevenly among its children. In
+our example case, the vertical sizer is supposed to propagate all its
+height changes to only the text area, not to the button area. This is
+determined by the proportion parameter when adding a window (or
+another sizer) to a sizer. It is interpreted as a weight factor,
+i.e. it can be zero, indicating that the window may not be resized at
+all, or above zero. If several windows have a value above zero, the
+value is interpreted relative to the sum of all weight factors of the
+sizer, so when adding two windows with a value of 1, they will both
+get resized equally much and each half as much as the sizer owning
+them.</p>
+<p>Then what do we do when a column sizer changes its width? This
+behaviour is controlled by flags (the second parameter of the Add()
+function): zero or no flag indicates that the window will preserve it
+is original size, wx.GROW flag (same as wx.EXPAND) forces the window
+to grow with the sizer, and wx.SHAPED flag tells the window to change
+it is size proportionally, preserving original aspect ratio. When
+wx.GROW flag is not used, the item can be aligned within available
+space. wx.ALIGN_LEFT, wx.ALIGN_TOP, wx.ALIGN_RIGHT, wx.ALIGN_BOTTOM,
+wx.ALIGN_CENTER_HORIZONTAL and wx.ALIGN_CENTER_VERTICAL do what they
+say. wx.ALIGN_CENTRE (same as wx.ALIGN_CENTER) is defined as
+(<tt class="literal"><span class="pre">wx.ALIGN_CENTER_HORIZONTAL</span> <span class="pre">|</span> <span class="pre">wx.ALIGN_CENTER_VERTICAL</span></tt>). Default
+alignment is <tt class="literal"><span class="pre">wx.ALIGN_LEFT</span> <span class="pre">|</span> <span class="pre">wx.ALIGN_TOP</span></tt>.</p>
+<p>As mentioned above, any window belonging to a sizer may have border,
+and it can be specified which of the four sides may have this border,
+using the wx.TOP, wx.LEFT, wx.RIGHT and wx.BOTTOM constants or wx.ALL
+for all directions (and you may also use wx.NORTH, wx.WEST etc
+instead). These flags can be used in combination with the alignment
+flags above as the second parameter of the Add() method using the
+binary or operator (<tt class="literal"><span class="pre">|</span></tt>). The sizer of the border also must be made
+known, and it is the third parameter in the Add() method. This means,
+that the entire behaviour of a sizer and its children can be
+controlled by the three parameters of the Add() method.</p>
+<p>[Show code and graphic here.]</p>
+</div>
+<div class="section" id="programming-with-gridsizer">
+<h2><a class="toc-backref" href="#id28" name="programming-with-gridsizer">Programming with GridSizer</a></h2>
+<p>GridSizer is a sizer which lays out its children in a two-dimensional
+table with all table fields having the same size, i.e. the width of
+each field is the width of the widest child, the height of each field
+is the height of the tallest child.</p>
+<p>[Show code and graphic here.]</p>
+</div>
+<div class="section" id="programming-with-flexgridsizer">
+<h2><a class="toc-backref" href="#id29" name="programming-with-flexgridsizer">Programming with FlexGridSizer</a></h2>
+<p>FlexGridSizer is a sizer which lays out its children in a
+two-dimensional table with all table fields in one row having the same
+height and all fields in one column having the same width, but all
+rows or all columns are not necessarily the same height or width as in
+the GridSizer.</p>
+<p>[Show code and graphic here.]</p>
+</div>
+<div class="section" id="programming-with-notebooksizer">
+<h2><a class="toc-backref" href="#id30" name="programming-with-notebooksizer">Programming with NotebookSizer</a></h2>
+<p>NotebookSizer is a specialized sizer to make sizers work in connection
+with using notebooks. This sizer is different from any other sizer as
+you must not add any children to it - instead, it queries the notebook
+class itself. The only thing this sizer does is to determine the size
+of the biggest page of the notebook and report an adjusted minimal
+size to a more toplevel sizer.</p>
+<p>In order to query the size of notebook page, this page needs to have
+its own sizer, otherwise the NotebookSizer will ignore it. Notebook
+pages get their sizer by assigning one to them using SetSizer() and
+setting the auto-layout option to True using SetAutoLayout(). Here is
+one example showing how to add a notebook page that the notebook sizer
+is aware of:</p>
+<p>[Show code and graphic here.]</p>
+</div>
+<div class="section" id="programming-with-staticboxsizer">
+<h2><a class="toc-backref" href="#id31" name="programming-with-staticboxsizer">Programming with StaticBoxSizer</a></h2>
+<p>StaticBoxSizer is a sizer derived from BoxSizer but adds a static box
+around the sizer. Note that this static box has to be created
+separately.</p>
+<p>[Show code and graphic here.]</p>
+</div>
+<div class="section" id="dialog-createbuttonsizer">
+<h2><a class="toc-backref" href="#id32" name="dialog-createbuttonsizer">Dialog.CreateButtonSizer</a></h2>
+<p>As a convenience, the Dialog class has a CreateButtonSizer(flags)
+method that can be used to create a standard button sizer in which
+standard buttons are displayed. The following flags can be passed to
+this method:</p>
+<table border class="table">
+<colgroup>
+<col width="19%" />
+<col width="81%" />
+</colgroup>
+<tbody valign="top">
+<tr><td>wx.YES_NO</td>
+<td>add Yes/No subpanel</td>
+</tr>
+<tr><td>wx.YES</td>
+<td>return wx.ID_YES</td>
+</tr>
+<tr><td>wx.NO</td>
+<td>return wx.ID_NO</td>
+</tr>
+<tr><td>wx.NO_DEFAULT</td>
+<td>make the wx.NO button the default, otherwise wx.YES or
+wx.OK button will be default</td>
+</tr>
+<tr><td>wx.OK</td>
+<td>return wx.ID_OK</td>
+</tr>
+<tr><td>wx.CANCEL</td>
+<td>return wx.ID_CANCEL</td>
+</tr>
+<tr><td>wx.HELP</td>
+<td>return wx.ID_HELP</td>
+</tr>
+<tr><td>wx.FORWARD</td>
+<td>return wx.ID_FORWARD</td>
+</tr>
+<tr><td>wx.BACKWARD</td>
+<td>return wx.ID_BACKWARD</td>
+</tr>
+<tr><td>wx.SETUP</td>
+<td>return wx.ID_SETUP</td>
+</tr>
+<tr><td>wx.MORE</td>
+<td>return wx.ID_MORE</td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="section" id="date-and-time-classes-overview">
+<h1><a class="toc-backref" href="#id33" name="date-and-time-classes-overview">Date and time classes overview</a></h1>
+<p>wxPython provides a set of powerful classes to work with dates and
+times. Some of the supported features of the DateTime class are:</p>
+<table border class="table">
+<colgroup>
+<col width="18%" />
+<col width="82%" />
+</colgroup>
+<tbody valign="top">
+<tr><td>Wide range</td>
+<td>The range of supported dates goes from about 4714 B.C. to
+some 480 million years in the future.</td>
+</tr>
+<tr><td>Precision</td>
+<td>Not using floating point calculations anywhere ensures that
+the date calculations don't suffer from rounding
+errors.</td>
+</tr>
+<tr><td>Many features</td>
+<td>Not only all usual calculations with dates are
+supported, but also more exotic week and year day
+calculations, work day testing, standard astronomical
+functions, conversion to and from strings in either
+strict or free format.</td>
+</tr>
+<tr><td>Efficiency</td>
+<td>Objects of DateTime are small (8 bytes) and working
+with them is fast</td>
+</tr>
+</tbody>
+</table>
+<div class="section" id="all-date-time-classes-at-a-glance">
+<h2><a class="toc-backref" href="#id34" name="all-date-time-classes-at-a-glance">All date/time classes at a glance</a></h2>
+<p>There are 3 main classes: except DateTime itself which represents an
+absolute moment in time, there are also two classes - TimeSpan and
+DateSpan which represent the intervals of time.</p>
+<p>There are also helper classes which are used together with DateTime:
+DateTimeHolidayAuthority which is used to determine whether a given
+date is a holiday or not and DateTimeWorkDays which is a derivation of
+this class for which (only) Saturdays and Sundays are the holidays.
+See more about these classes in the discussion of the holidays.</p>
+</div>
+<div class="section" id="datetime-characteristics">
+<h2><a class="toc-backref" href="#id35" name="datetime-characteristics">DateTime characteristics</a></h2>
+<p>DateTime stores the time as a signed number of milliseconds since the
+Epoch which is fixed, by convention, to Jan 1, 1970 - however this is
+not visible to the class users (in particular, dates prior to the
+Epoch are handled just as well (or as bad) as the dates after it).
+But it does mean that the best resolution which can be achieved with
+this class is 1 millisecond.</p>
+<p>The size of DateTime object is 8 bytes because it is represented as a
+64 bit integer. The resulting range of supported dates is thus
+approximatively 580 million years, but due to the current limitations
+in the Gregorian calendar support, only dates from Nov 24, 4714BC are
+supported (this is subject to change if there is sufficient interest
+in doing it).</p>
+<p>Finally, the internal representation is time zone independent (always
+in GMT) and the time zones only come into play when a date is broken
+into year/month/day components. See more about timezones below.</p>
+<p>Currently, the only supported calendar is Gregorian one (which is used
+even for the dates prior to the historic introduction of this calendar
+which was first done on Oct 15, 1582 but is, generally speaking,
+country, and even region, dependent). Future versions will probably
+have Julian calendar support as well and support for other calendars
+(Maya, Hebrew, Chinese...) is not ruled out.</p>
+</div>
+<div class="section" id="difference-between-datespan-and-timespan">
+<h2><a class="toc-backref" href="#id36" name="difference-between-datespan-and-timespan">Difference between DateSpan and TimeSpan</a></h2>
+<p>While there is only one logical way to represent an absolute moment in
+the time (and hence only one DateTime class), there are at least two
+methods to describe a time interval.</p>
+<p>First, there is the direct and self-explaining way implemented by
+TimeSpan: it is just a difference in milliseconds between two moments
+in time. Adding or subtracting such an interval to DateTime is always
+well-defined and is a fast operation.</p>
+<p>But in daily life other, calendar-dependent time interval
+specifications are used. For example, 'one month later' is commonly
+used. However, it is clear that this is not the same as TimeSpan of
+60*60*24*31 seconds because 'one month later' Feb 15 is Mar 15 and not
+Mar 17 or Mar 16 (depending on whether the year is leap or not).</p>
+<p>This is why there is another class for representing such intervals
+called DateSpan. It handles these sort of operations in the most
+natural way possible, but note that manipulating with intervals of
+this kind is not always well-defined. Consider, for example, Jan 31 +
+'1 month': this will give Feb 28 (or 29), i.e. the last day of
+February and not the non-existent Feb 31. Of course, this is what is
+usually wanted, but you still might be surprised to notice that now
+subtracting back the same interval from Feb 28 will result in Jan 28
+and not Jan 31 we started with!</p>
+<p>So, unless you plan to implement some kind of natural language parsing
+in the program, you should probably use TimeSpan instead of DateSpan
+(which is also more efficient). However, DateSpan may be very useful
+in situations when you do need to understand what 'in a month' means
+(of course, it is just DateTime.Now() + DateSpan.Month()).</p>
+</div>
+<div class="section" id="date-arithmetics">
+<h2><a class="toc-backref" href="#id37" name="date-arithmetics">Date arithmetics</a></h2>
+<p>Many different operations may be performed with the dates, however not
+all of them make sense. For example, multiplying a date by a number
+is an invalid operation, even though multiplying either of the time
+span classes by a number is perfectly valid.</p>
+<p>Here is what can be done:</p>
+<table border class="table">
+<colgroup>
+<col width="19%" />
+<col width="81%" />
+</colgroup>
+<tbody valign="top">
+<tr><td>Addition</td>
+<td>a TimeSpan or DateSpan can be added to DateTime resulting in
+a new DateTime object and also 2 objects of the same
+span class can be added together giving another object
+of the same class.</td>
+</tr>
+<tr><td>Subtraction</td>
+<td>the same types of operations as above are allowed and,
+additionally, a difference between two DateTime
+objects can be taken and this will yield TimeSpan.</td>
+</tr>
+<tr><td>Multiplication</td>
+<td>a TimeSpan or DateSpan object can be multiplied by an
+integer number resulting in an object of the same
+type.</td>
+</tr>
+<tr><td>Unary minus</td>
+<td>a TimeSpan or DateSpan object may finally be negated
+giving an interval of the same magnitude but of
+opposite time direction.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="time-zone-considerations">
+<h2><a class="toc-backref" href="#id38" name="time-zone-considerations">Time zone considerations</a></h2>
+<p>Although the time is always stored internally in GMT, you will usually
+work in the local time zone. Because of this, all DateTime
+constructors and setters which take the broken down date assume that
+these values are for the local time zone. Thus, DateTime(1,
+DateTime.Jan, 1970) will not correspond to the DateTime Epoch unless
+you happen to live in the UK.</p>
+<p>All methods returning the date components (year, month, day, hour,
+minute, second...) will also return the correct values for the local
+time zone by default. So, generally, doing the natural things will
+lead to natural and correct results.</p>
+<p>If you only want to do this, you may safely skip the rest of this
+section. However, if you want to work with different time zones, you
+should read it to the end.</p>
+<p>In this (rare) case, you are still limited to the local time zone when
+constructing DateTime objects, i.e. there is no way to construct a
+DateTime corresponding to the given date in, say, Pacific Standard
+Time. To do it, you will need to call ToTimezone or MakeTimezone
+methods to adjust the date for the target time zone. There are also
+special versions of these functions ToGMT and MakeGMT for the most
+common case - when the date should be constructed in GMT.</p>
+<p>You also can just retrieve the value for some time zone without
+converting the object to it first. For this you may pass TimeZone
+argument to any of the methods which are affected by the time zone
+(all methods getting date components and the date formatting ones, for
+example). In particular, the Format() family of methods accepts a
+TimeZone parameter and this allows to simply print time in any time
+zone.</p>
+<p>To see how to do it, the last issue to address is how to construct a
+TimeZone object which must be passed to all these methods. First of
+all, you may construct it manually by specifying the time zone offset
+in seconds from GMT, but usually you will just use one of the symbolic
+time zone names and let the conversion constructor do the
+job. I.e. you would just write</p>
+<p>wxDateTime dt(...whatever...);
+printf("The time is %s in local time zone", dt.FormatTime().c_str());
+printf("The time is %s in GMT", dt.FormatTime(wxDateTime::GMT).c_str());</p>
+</div>
+<div class="section" id="daylight-saving-time-dst">
+<h2><a class="toc-backref" href="#id39" name="daylight-saving-time-dst">Daylight saving time (DST)</a></h2>
+<p>DST (a.k.a. 'summer time') handling is always a delicate task which is
+better left to the operating system which is supposed to be configured
+by the administrator to behave correctly. Unfortunately, when doing
+calculations with date outside of the range supported by the standard
+library, we are forced to deal with these issues ourselves.</p>
+<p>Several functions are provided to calculate the beginning and end of
+DST in the given year and to determine whether it is in effect at the
+given moment or not, but they should not be considered as absolutely
+correct because, first of all, they only work more or less correctly
+for only a handful of countries (any information about other ones
+appreciated!) and even for them the rules may perfectly well change in
+the future.</p>
+<p>The time zone handling methods use these functions too, so they are
+subject to the same limitations.</p>
+</div>
+<div class="section" id="datetime-and-holidays">
+<h2><a class="toc-backref" href="#id40" name="datetime-and-holidays">DateTime and Holidays</a></h2>
+<p>[TODO]</p>
+</div>
+</div>
+<div class="section" id="classes-by-category">
+<h1><a class="toc-backref" href="#id41" name="classes-by-category">Classes by category</a></h1>
+<p>Not done yet.</p>
+</div>
+<div class="section" id="id-constants">
+<h1><a class="toc-backref" href="#id42" name="id-constants">ID constants</a></h1>
+<p>wxPython provides the following predefined ID constants:</p>
+<p>ID_ABORT
+ID_ABOUT
+ID_ANY
+ID_APPLY
+ID_BACKWARD
+ID_CANCEL
+ID_CLEAR
+ID_CLOSE
+ID_CLOSE_ALL
+ID_CONTEXT_HELP
+ID_COPY
+ID_CUT
+ID_DEFAULT
+ID_DUPLICATE
+ID_EXIT
+ID_FILE1
+ID_FILE2
+ID_FILE3
+ID_FILE4
+ID_FILE5
+ID_FILE6
+ID_FILE7
+ID_FILE8
+ID_FILE9
+ID_FILTERLISTCTRL
+ID_FIND
+ID_FORWARD
+ID_HELP
+ID_HELP_COMMANDS
+ID_HELP_CONTENTS
+ID_HELP_CONTEXT
+ID_HELP_PROCEDURES
+ID_IGNORE
+ID_MORE
+ID_NEW
+ID_NO
+ID_NOTOALL
+ID_OK
+ID_OPEN
+ID_PASTE
+ID_PREVIEW
+ID_PRINT
+ID_PRINT_SETUP
+ID_REDO
+ID_RESET
+ID_RETRY
+ID_REVERT
+ID_SAVE
+ID_SAVEAS
+ID_SELECTALL
+ID_SEPARATOR
+ID_SETUP
+ID_STATIC
+ID_TREECTRL
+ID_UNDO
+ID_YES
+ID_YESTOALL</p>
+</div>
+<div class="section" id="source-document">
+<h1><a class="toc-backref" href="#id43" name="source-document">Source document</a></h1>
+<p>The source document is named wxPythonManual.txt and can be found by
+clicking the link at the bottom of this page (assuming you are viewing
+the html file). It is written using a fantastic formatting convention
+called reStructuredText. The wxPythonManual.html file is created
+using the Docutils utilities, which can turn reStructuredText
+documents into html, xml, pdf, and even OpenOffice files.</p>
+</div>
+<div class="section" id="submitting-changes-to-the-source-document">
+<h1><a class="toc-backref" href="#id44" name="submitting-changes-to-the-source-document">Submitting changes to the source document</a></h1>
+<p>Some items in the source text file look like this:</p>
+<pre class="literal-block">
+.. This is text from the wxWindows documentation that needs to be
+ translated into something appropriate for the wxPython version.
+ The two dots followed by uniformly indented text turns this
+ paragraph into a reStructuredText comment, so it doesn't appear
+ in any output file, such as the html file.
+</pre>
+<p>They have been commented out and are awaiting editorial review and a
+rewrite so that they make sense in the context of wxPython. Feel free
+to send me suggestions for rewording these, or any other parts of this
+document that you think need improving. I will be eternally grateful
+to you and will show my gratitude by adding your name to the list of
+contributors. (Contributors who also send me gifts of coffee,
+chocolate, or currency will have their names listed in bold.)</p>
+</div>
+<div class="section" id="contributors">
+<h1><a class="toc-backref" href="#id45" name="contributors">Contributors</a></h1>
+<p>Individuals who contributed to this documentation (in order by last
+name):</p>
+<ul class="simple">
+<li>Robin Dunn</li>
+<li>Patrick K. O'Brien</li>
+<li>Robert Roebling</li>
+<li>Julian Smart</li>
+<li>Vadim Zeitlin</li>
+</ul>
+</div>
+<div class="section" id="license">
+<h1><a class="toc-backref" href="#id46" name="license">License</a></h1>
+<p>This document began as a translation of the wxWindows documentation.
+As such, it adheres to the same license, which is provided here:</p>
+<pre class="literal-block">
+ wxWindows Free Documentation Licence, Version 3
+ ===============================================
+
+ Copyright (c) 1998 Julian Smart, Robert Roebling et al
+
+ Everyone is permitted to copy and distribute verbatim copies
+ of this licence document, but changing it is not allowed.
+
+ WXWINDOWS FREE DOCUMENTATION LICENCE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 1. Permission is granted to make and distribute verbatim copies of this
+ manual or piece of documentation provided any copyright notice and this
+ permission notice are preserved on all copies.
+
+ 2. Permission is granted to process this file or document through a
+ document processing system and, at your option and the option of any third
+ party, print the results, provided a printed document carries a copying
+ permission notice identical to this one.
+
+ 3. Permission is granted to copy and distribute modified versions of this
+ manual or piece of documentation under the conditions for verbatim
+ copying, provided also that any sections describing licensing conditions
+ for this manual, such as, in particular, the GNU General Public Licence,
+ the GNU Library General Public Licence, and any wxWindows Licence are
+ included exactly as in the original, and provided that the entire
+ resulting derived work is distributed under the terms of a permission
+ notice identical to this one.
+
+ 4. Permission is granted to copy and distribute translations of this
+ manual or piece of documentation into another language, under the above
+ conditions for modified versions, except that sections related to
+ licensing, including this paragraph, may also be included in translations
+ approved by the copyright holders of the respective licence documents in
+ addition to the original English.
+
+ WARRANTY DISCLAIMER
+
+ 5. BECAUSE THIS MANUAL OR PIECE OF DOCUMENTATION IS LICENSED FREE OF CHARGE,
+ THERE IS NO WARRANTY FOR IT, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+ EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
+ PARTIES PROVIDE THIS MANUAL OR PIECE OF DOCUMENTATION "AS IS" WITHOUT
+ WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
+ LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF
+ THE MANUAL OR PIECE OF DOCUMENTATION IS WITH YOU. SHOULD THE MANUAL OR
+ PIECE OF DOCUMENTATION PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
+ NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+ 6. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL
+ ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+ REDISTRIBUTE THE MANUAL OR PIECE OF DOCUMENTATION AS PERMITTED ABOVE, BE
+ LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+ CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+ MANUAL OR PIECE OF DOCUMENTATION (INCLUDING BUT NOT LIMITED TO LOSS OF
+ DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+ PARTIES OR A FAILURE OF A PROGRAM BASED ON THE MANUAL OR PIECE OF
+ DOCUMENTATION TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR
+ OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+
+</pre>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
+<title>The wxPython Tutorial</title>
+<meta name="author" content="Patrick K. O'Brien" />
+<meta name="organization" content="Orbtech" />
+<meta name="date" content="2003-07-02" />
+<link rel="stylesheet" href="default.css" type="text/css" />
+</head>
+<body>
+<div class="document" id="the-wxpython-tutorial">
+<h1 class="title">The wxPython Tutorial</h1>
+<h2 class="subtitle" id="how-to-get-up-and-running-with-wxpython">How to get up and running with wxPython</h2>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr><th class="docinfo-name">Author:</th>
+<td>Patrick K. O'Brien</td></tr>
+<tr><th class="docinfo-name">Contact:</th>
+<td><a class="first last reference" href="mailto:pobrien@orbtech.com">pobrien@orbtech.com</a></td></tr>
+<tr><th class="docinfo-name">Organization:</th>
+<td><a class="first last reference" href="http://www.orbtech.com/">Orbtech</a></td></tr>
+<tr><th class="docinfo-name">Date:</th>
+<td>2003-07-02</td></tr>
+<tr><th class="docinfo-name">Revision:</th>
+<td>1.2</td></tr>
+<tr class="field"><th class="docinfo-name">License:</th><td class="field-body">wxWindows Free Documentation Licence, Version 3</td>
+</tr>
+</tbody>
+</table>
+<div class="contents topic" id="contents">
+<p class="topic-title"><a name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#introduction" id="id1" name="id1">Introduction</a></li>
+<li><a class="reference" href="#what-is-wxpython" id="id2" name="id2">What is wxPython?</a></li>
+<li><a class="reference" href="#license" id="id3" name="id3">License</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h1><a class="toc-backref" href="#id1" name="introduction">Introduction</a></h1>
+<p>This is a tutorial for the wxPython GUI toolkit. It uses the new wx
+package syntax that was introduced in wxPython 2.4.1.</p>
+</div>
+<div class="section" id="what-is-wxpython">
+<h1><a class="toc-backref" href="#id2" name="what-is-wxpython">What is wxPython?</a></h1>
+<p>wxPython is a GUI toolkit for the Python programming language. It
+allows Python programmers to create programs with a graphical user
+interface for Windows, Linux, and Mac OS X.</p>
+</div>
+<div class="section" id="license">
+<h1><a class="toc-backref" href="#id3" name="license">License</a></h1>
+<p>This document adheres to the same license as the other documentation
+that comes with wxWindows:</p>
+<pre class="literal-block">
+ wxWindows Free Documentation Licence, Version 3
+ ===============================================
+
+ Copyright (c) 1998 Julian Smart, Robert Roebling et al
+
+ Everyone is permitted to copy and distribute verbatim copies
+ of this licence document, but changing it is not allowed.
+
+ WXWINDOWS FREE DOCUMENTATION LICENCE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 1. Permission is granted to make and distribute verbatim copies of this
+ manual or piece of documentation provided any copyright notice and this
+ permission notice are preserved on all copies.
+
+ 2. Permission is granted to process this file or document through a
+ document processing system and, at your option and the option of any third
+ party, print the results, provided a printed document carries a copying
+ permission notice identical to this one.
+
+ 3. Permission is granted to copy and distribute modified versions of this
+ manual or piece of documentation under the conditions for verbatim
+ copying, provided also that any sections describing licensing conditions
+ for this manual, such as, in particular, the GNU General Public Licence,
+ the GNU Library General Public Licence, and any wxWindows Licence are
+ included exactly as in the original, and provided that the entire
+ resulting derived work is distributed under the terms of a permission
+ notice identical to this one.
+
+ 4. Permission is granted to copy and distribute translations of this
+ manual or piece of documentation into another language, under the above
+ conditions for modified versions, except that sections related to
+ licensing, including this paragraph, may also be included in translations
+ approved by the copyright holders of the respective licence documents in
+ addition to the original English.
+
+ WARRANTY DISCLAIMER
+
+ 5. BECAUSE THIS MANUAL OR PIECE OF DOCUMENTATION IS LICENSED FREE OF CHARGE,
+ THERE IS NO WARRANTY FOR IT, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+ EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
+ PARTIES PROVIDE THIS MANUAL OR PIECE OF DOCUMENTATION "AS IS" WITHOUT
+ WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
+ LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF
+ THE MANUAL OR PIECE OF DOCUMENTATION IS WITH YOU. SHOULD THE MANUAL OR
+ PIECE OF DOCUMENTATION PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
+ NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+ 6. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL
+ ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+ REDISTRIBUTE THE MANUAL OR PIECE OF DOCUMENTATION AS PERMITTED ABOVE, BE
+ LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+ CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+ MANUAL OR PIECE OF DOCUMENTATION (INCLUDING BUT NOT LIMITED TO LOSS OF
+ DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+ PARTIES OR A FAILURE OF A PROGRAM BASED ON THE MANUAL OR PIECE OF
+ DOCUMENTATION TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR
+ OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+
+</pre>
+</div>
+</div>
+<hr class="footer" />
+<div class="footer">
+Generated on: 2004-02-04 23:31 UTC.
+</div>
+</body>
+</html>
projects / wxWidgets.git / commitdiff
