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://wxWidgets.org/snapshots/">http://wxWidgets.org/snapshots/</a>, a checkout from CVS, or
-one of the released wxPythonSrc-2.5.* tarballs. I'll also assume that
+one of the released wxPython-src-2.5.* tarballs. I'll also assume that
you know your way around your system, the compiler, etc. and most
importantly, that you know what you are doing! ;-)</p>
<p>If you want to also install the version of wxPython you build to be in
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>
+<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,
+plus some patches. Get the sources for version 1.3.22, and then apply
+the patches in wxPython/SWIG and then build SWIG like normal. See the
+README.txt in the wxPython/SWIG 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>
<p>In the text below I'll use WXDIR with environment variable syntax
-(either $WXDIR or %WXDIR%) to refer to the top level directory were
+(either $WXDIR or %WXDIR%) to refer to the top level directory where
your wxWidgerts and wxPython sources are located. It will equate to
whereever you checked out the wxWidgets module from CVS, or untarred
-the wxPythonSrc tarball to. You can either substitute the $WXDIR text
+the wxPython-src tarball to. You can either substitute the $WXDIR text
below with your actual dir, or set the value in the environment and
use it just like you see it below.</p>
<p>If you run into what appears to be compatibility issues between
wxWidgets and wxPython while building wxPython, be sure you are using
-the wxWidgets sources included with the wxPythonSrc tarball or the CVS
-snapshot, and not a previously installed version or a version
+the wxWidgets sources included with the wxPython-src tarball or the
+CVS snapshot, and not a previously installed version or a version
installed from one of the standard wxWidgets installers. With the
"unstable" releases (have a odd-numbered minor release value, where
the APIs are allowed to change) there are often significant
</pre>
<p>On OS X of course you'll want to use --with-mac instead of
--with-gtk.</p>
-<p><strong>NOTE</strong>: Due to a recent change there is a dependency problem in the
-multilib builds of wxWidgets on OSX, so I have switched to a
-monolithic build on that platform. (IOW, all of the core code in
-one shared library instead of several.) I would also expect other
-unix builds to do just fine with a monolithic library, but I havn't
-tested it in a while so your mileage may vary. Anyway, to switch
+<p><strong>NOTE</strong>: Due to a recent change there is currently a dependency
+problem in the multilib builds of wxWidgets on OSX, so I have
+switched to using a monolithic build. That means that all of the
+core wxWidgets code is placed in in one shared library instead of
+several. wxPython can be used with either mode, so use whatever
+suits you on Linux and etc. but use monolithic on OSX. To switch
to the monolithic build of wxWidgets just add this configure flag:</p>
<pre class="literal-block">
--enable-monolithic \
</pre>
-<p>By default GTK2 will be selected if it is on your build system. To
-force the use of GTK 1.2.x add this flag:</p>
+<p>By default GTK2 will be selected if its development pacakge is
+installed on your build system. To force the use of GTK 1.2.x
+instead add this flag:</p>
<pre class="literal-block">
--disable-gtk2 \
</pre>
-<p>To make the wxWidgets build be Unicode enabled (strongly
-recommended if you are building with GTK2) then add:</p>
+<p>To make the wxWidgets build be unicode enabled (strongly
+recommended if you are building with GTK2) then add the following.
+When wxPython is unicode enabled then all strings that are passed
+to wx functions and methods will first be converted to unicode
+objects, and any 'strings' returned from wx functions and methods
+will actually be unicode objects.:</p>
<pre class="literal-block">
--enable-unicode \
</pre>
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 $*
+ && make -C contrib/src/stc $*
</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>
GTK2. If you built wxWidgets to use GTK 1.2.x then you should add
this flag to the command-line:</p>
<pre class="literal-block">
-WXPORT=gtk2
+WXPORT=gtk
</pre>
<p>If you would like to do a Unicode enabled build (all strings sent
to or retruned from wx functions are Unicode objects) and your
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>Starting with 2.5.3.0 wxPython can be built for either the monlithic
+or the multi-lib wxWidgets builds. (Monolithic means that all the
+core wxWidgets code is in one DLL, and multi-lib means that the core
+code is divided into multiple DLLs.) To select which one to use
+specify the MONOLITHIC flag for both the wxWidgets build and the
+wxPython build as shown below, setting it to either 0 or 1.</p>
<p>Just like the unix versions I also use some scripts to help me build
wxWidgets, but I use some non-standard stuff to do it. So if you have
bash (cygwin or probably MSYS too) or 4NT plus unix-like cat and sed
executing nmake with a bunch of extra command line parameters.
The base set are:</p>
<pre class="literal-block">
--f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1
+-f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1
</pre>
<p>If doing a debug build then add:</p>
<pre class="literal-block">
contrib libraries:</p>
<pre class="literal-block">
%WXDIR%\contrib\build\gizmos
- %WXDIR%\contrib\build\xrc
%WXDIR%\contrib\build\stc
%WXDIR%\contrib\build\ogl
development version please refer to INSTALL.txt.</p>
<p>Change to the %WXDIR%\wxPython dir and run the this command,
making sure that you use the version of python that you want to
-build for (if you have more than one on your system):</p>
+build for (if you have more than one on your system) and to match
+the MONOLITHIC flag with how you built wxWidgets:</p>
<pre class="literal-block">
cd %WXDIR%\wxPython
-python setup.py build_ext --inplace
+python setup.py build_ext --inplace MONOLITHIC=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
<div class="document" id="recent-changes-for-wxpython">
<h1 class="title">Recent Changes for wxPython</h1>
<div class="section" id="id1">
-<h1><a name="id1">2.5.2.8</a></h1>
+<h1><a name="id1">2.5.3.0</a></h1>
+<p>wxMac focus and border refreshes corrected.</p>
+<p>Updated internal PNG library.</p>
+<p>wxMac fix for metal appearance on wx.ToolBar.</p>
+<p>wx.grid.Grid fix allowing DoGetBestSize to be called before CreateGrid
+(which means that a min size doesn't need to be specified.)</p>
+<p>wxMac fix for not sending a native click to a control if it is not
+enabled (does an enable itself)</p>
+<p>Added wx.lib.ogl.DrawnShape, and fixed various little bugs in the new
+OGL.</p>
+<p>Added support to XRC and XRCed for the 3-state checkbox flags and also
+for wx.ToggleButton. Updated the generic window styles supported by
+XRCed.</p>
+<p>It is now possible to create "stock" buttons. Basically this means
+that you only have to provide one of the stock IDs (and either an
+empty label or a label that matches the stock label) when creating the
+button and wxWidgets will choose the stock label to go with it
+automatically. Additionally on the platforms that have a native
+concept of a stock button (currently only GTK2) then the native stock
+button will be used. For example, the following will result in a
+button with "Cancel" as the label and an accelerator on the "C", and
+if run on wxGTK2 then there will also be an image of a red X:</p>
+<pre class="literal-block">
+b = wx.Button(parent, wx.ID_CANCEL)
+</pre>
+<p>Added wx.lib.ticker.Ticker class from Chris Mellon.</p>
+<p>Fix some incorrect clipping regions in wxSTC on wxGTK.</p>
+<p>Added wrapper for wx.grid.Grid.GetOrCreateCellAttr.</p>
+<p>Removed my copy of distutils from the wxPython source tree. Now that
+I am no longer doing builds on Python 2.1 the newest distutils is no
+longer needed. (There is still one small bug in Python 2.2 distutils
+on win32, but it is easily worked around.) This sovles the problem of
+incorrect builds on some systems where the system installed distutils
+has been patched to behave slightly differently, for example SuSE on
+x86_64 or Chandler's build.</p>
+<p>Updated to SWIG 1.3.22 (plus my patch.) See wxPython/SWIG/README.txt
+in the source tree if you need to use SWIG when building your own copy
+of wxPython, or other extension modules that need to integrate with
+the wxPython modules.</p>
+<p>Added wx.Frame.RequestUserAttention which, if the platform suports it,
+will do something (such as flash the task bar item) to suggest to the
+user that they should look at that window.</p>
+<p>"Fixed" wx.grid.Grid.SetDefaultEditor and SetDefaultRenderer by making
+them register the editor or renderer for the "string" data type.</p>
+<p>Added depth param to wx.Image.ConvertToBitmap.</p>
+<p>Extended the wx.calendar.CalendarCtrl class with methods that get/set
+a Python datetime or date object. (These will only work with Python
+2.3+) The methods are PySetDate, PyGetDate, PySetLowerDateLimit,
+PySetUpperDateLimit, PySetDateRange, PyGetLowerDateLimit, and
+PyGetUpperDateLimit. Also, CalendarEvent was extended with PySetDate
+and PyGetDate methods.</p>
+<p>wxMSW: SetBackgroundColour on a wx.Choice or a wx.ComboBox will now
+also set the colour of the dropdown.</p>
+<p>wxMac: MessageDialog now supports wx.NO_DEFAULT style</p>
+<p>wxMSW: added AssociateHandle and DissociateHandle to wx.Window</p>
+<p>wxMac: fix for toolbar tooltips</p>
+<p>wx.Sizer.Show (and Hide) now take an optional parameter specifying if
+the item to be shown should be searched for recursivly in subsizers,
+and return a boolean value indicating if the item was found.</p>
+<p>wxMSW: fixed MaximizeEvent generation in wx.Frame</p>
+<p>wxMSW: fixed sending duplicate EVT_COMBOBOX events</p>
+<p>Smoother time estimation updates in wx.ProgressDialog (patch 992813)</p>
+<p>Made wx.Listbook events more consistent with wx.Notebook ones (patch
+1001271)</p>
+<p>Fixed rounding errors in variable status bar panes widths computation
+(patch 1030021)</p>
+<p>Added possibility to specify printer bin (patch 910272)</p>
+<p>wxMSW: fixed wx.ListCtrl's SetWindowStyleFlag() to not remove
+WS_VISIBLE; also refresh the control automatically (closes bug
+1019440)</p>
+<p>Added wx.Choicebook, yet another notebook-like control.</p>
+<p>wxMSW: Make radiobutton tab behaviour the same on MSW as in standard
+MSW app, i.e. tab into the activated, not necessarily the first radio
+button.</p>
+<p>Added limited support for wxEventLoop (you can't derive from a
+wx.PyEventLoop version yet...) Updated and moved the sample showing
+how to replace the MainLoop to samples/mainloop/mainloop.py.</p>
+<p>The C++ xrc lib has been moved out of contrib and into the core, so it
+is always built by default. wxPython's build has also changed
+accordingly and will build the xrc module as part of the core set of
+modules built by default. If you were axplicitly using BUILD_XRC then
+it will no longer be recognized as a build option, otherwise you
+should notice no difference.</p>
+<p>wxMac: Fixed radio toolbar buttons to correctly untoggle the others
+when a new one is selected.</p>
+<p>wxMac: Fixed GetLineLength and GetLineText for MLTE text controls</p>
+<p>wxMac: wx.TaskBarIcon is implemented by allowing you to change the
+app's icon on the Dock and also specifying a menu that should be
+merged with the normal dock popup menu. See the MigrationGuide for
+more details and a warning.</p>
+<p>Added wx.TopLevelWindow.IsActive() which tells you if the frame or
+dialog is or containts the active window with the keyboard focus.</p>
+<p>Added ability to create a font based on pixel size rather than point
+size via the FontFromPixelSize constructor.</p>
+<p>Updated the Scintilla used by StyledTextCtrl to version 1.61</p>
+<p>Improved image HitTest for TreeListCtrl.</p>
+<p>Added wx.App.IsMainLoopRunning.</p>
+<p>wxGTK: Make wxComboBox spit out a bit fewer surplus events when
+holding down the mouse button.</p>
+<p>wxGTK: Enable key based navigation through notebook tabs as in the
+native control with Left and right keys. Support for vetoing.</p>
+<p>FloatCanvas updates from Chris Barker</p>
+<dl>
+<dt>PyPlot updates from Gordon Williams:</dt>
+<dd><ul class="first last simple">
+<li>Added bar graph demo</li>
+<li>Modified line end shape from round to square.</li>
+<li>Removed FloatDCWrapper for conversion to ints and ints in
+arguments</li>
+<li>Imported modules given leading underscore to name.</li>
+<li>Added Cursor Line Tracking and User Point Labels.</li>
+<li>Demo for Cursor Line Tracking and Point Labels.</li>
+<li>Size of plot preview frame adjusted to show page better.</li>
+<li>Added helper functions PositionUserToScreen and
+PositionScreenToUser in PlotCanvas.</li>
+<li>Added functions GetClosestPoints (all curves) and GetClosestPoint
+(only closest curve) can be in either user coords or screen
+coords.</li>
+</ul>
+</dd>
+<dt>MaskedEdit updates from Will Sadkin:</dt>
+<dd><ul class="first last simple">
+<li>Added '*' mask char that means "all ansii chars" (ords 32-255)</li>
+<li>Added proper unicode support to masked controls and wx.tools.dbg</li>
+<li>Fixed two reported missing import bugs introduced by package
+creation</li>
+<li>Converted masked package doc strings to reST format for better
+epydoc support</li>
+<li>lots of doc string improvements and function hiding to better
+reflect package's public contents.</li>
+</ul>
+</dd>
+</dl>
+<p>Restructured the installer packages slightly to help facilitate having
+multiple versions of wxPython installed at the same time. See the
+Migrarion Guide for more information.</p>
+<dl>
+<dt>Applied patch from Pim Van Heuven that modifies 4 files:</dt>
+<dd><ul class="first last simple">
+<li>wxPython/demo/ListCtrl_edit.py (new demo)</li>
+<li>wxPython/demo/Main.py (include new demo in demo app)</li>
+<li>wxPython/wx/lib/mixins/listctrl.py (several improvements to
+TextEditMixin)</li>
+<li>wxPython/wx/lib/wxpTag.py (some small fixes)</li>
+</ul>
+</dd>
+</dl>
+<p>Added (thanks to Kevin Ollivier!) wrappers for wx.WebKitCtrl for the
+OSX build. Other platforms will raise an exception if you try to use
+it.</p>
+<p>wxPython on OSX can now be built in Unicode mode, can support multiple
+version installs, and comes with an uninstaller script.</p>
+</div>
+<div class="section" id="id2">
+<h1><a name="id2">2.5.2.8</a></h1>
<p>Predominantly a bug-fix release.</p>
<blockquote>
<ul class="simple">
</ul>
</blockquote>
</div>
-<div class="section" id="id2">
-<h1><a name="id2">2.5.2.7</a></h1>
+<div class="section" id="id3">
+<h1><a name="id3">2.5.2.7</a></h1>
<p>wx.ADJUST_MINSIZE is now the default behaviour for window items in
sizers. This means that the item's GetMinSize and/or GetBestSize will
be called when calculating layout and the return value from that will
... wx.MilliSleep(10)
</pre>
</div>
-<div class="section" id="id3">
-<h1><a name="id3">2.5.1.5</a></h1>
+<div class="section" id="id4">
+<h1><a name="id4">2.5.1.5</a></h1>
<p>(See also the <a class="reference" href="MigrationGuide.html">MigrationGuide</a> file for details about some of the
big changes that have happened in this release and how you should
adapt your code.)</p>
MigrationGuide for more details on using the new module.</p>
<p>Floats are allowed again as function parameters where ints are expected.</p>
</div>
-<div class="section" id="id5">
-<h1><a name="id5">2.4.2.4</a></h1>
+<div class="section" id="id6">
+<h1><a name="id6">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
<p>Added wxMaskedNumCtrl.</p>
<p>Added Chris Barker's FloatCanvas.</p>
</div>
-<div class="section" id="id6">
-<h1><a name="id6">2.4.1.2</a></h1>
+<div class="section" id="id7">
+<h1><a name="id7">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
and Spacers can be specified with a wxSize (or 2-tuple) parameter</p>
<p>Added wxCursorFromBits.</p>
</div>
-<div class="section" id="id7">
-<h1><a name="id7">2.4.0.7</a></h1>
+<div class="section" id="id8">
+<h1><a name="id8">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
<p>Updated pycolourchooser.</p>
<p>Updated to 0.9b of PyCrust.</p>
</div>
-<div class="section" id="id8">
-<h1><a name="id8">2.4.0.4</a></h1>
+<div class="section" id="id9">
+<h1><a name="id9">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>Fixed typemaps for wxGridCellCoordsArray.</p>
<p>Updated to the 0.9a version of PyCrust</p>
</div>
-<div class="section" id="id9">
-<h1><a name="id9">2.4.0.2</a></h1>
+<div class="section" id="id10">
+<h1><a name="id10">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="id10">
-<h1><a name="id10">2.4.0.1</a></h1>
+<div class="section" id="id11">
+<h1><a name="id11">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="id11">
-<h1><a name="id11">2.3.4.2</a></h1>
+<div class="section" id="id12">
+<h1><a name="id12">2.3.4.2</a></h1>
<p>Various bug fixes.</p>
</div>
-<div class="section" id="id12">
-<h1><a name="id12">2.3.4.1</a></h1>
+<div class="section" id="id13">
+<h1><a name="id13">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>
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="id13">
-<h1><a name="id13">2.3.3.1</a></h1>
+<div class="section" id="id14">
+<h1><a name="id14">2.3.3.1</a></h1>
<p>Added wxSplashScreen.</p>
<p>Added wxGenericDirCtrl.</p>
<p>Added wxMultiChoiceDialog.</p>
<p>Added wxPython.lib.mixins.rubberband module from Robb Shecter.</p>
<p>Added wxTimeCtrl from Will Sadkin.</p>
</div>
-<div class="section" id="id14">
-<h1><a name="id14">2.3.2.1</a></h1>
+<div class="section" id="id15">
+<h1><a name="id15">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="id15">
-<h1><a name="id15">2.3.2</a></h1>
+<div class="section" id="id16">
+<h1><a name="id16">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,
wxPython/contrib/dllwidget and wxPython/demo/dllwidget for more
details.</p>
</div>
-<div class="section" id="id16">
-<h1><a name="id16">2.3.1</a></h1>
+<div class="section" id="id17">
+<h1><a name="id17">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>Fixed img2py to work correctly with Python 2.1.</p>
<p>Added enhanced wxVTKRenderWindow by Prabhu Ramachandran</p>
</div>
-<div class="section" id="id17">
-<h1><a name="id17">2.3.0</a></h1>
+<div class="section" id="id18">
+<h1><a name="id18">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
by having smaller functional apps to play with. They can be found in
wxPython/samples.</p>
</div>
-<div class="section" id="id18">
-<h1><a name="id18">2.2.6</a></h1>
+<div class="section" id="id19">
+<h1><a name="id19">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="id19">
-<h1><a name="id19">2.2.5</a></h1>
+<div class="section" id="id20">
+<h1><a name="id20">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
</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>
+into the same bin dir used by Python by using this command, plus
+whatever WXPORT, UNICODE, etc. settings you used for the initial
+build step:</p>
<pre class="literal-block">
-python2.3 setup.py install
+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
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>
+<li>You need to use pythonw at the command line or the 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">
<p>You should not use AddWindow, AddSizer, AddSpacer (and similar for
Insert, Prepend, and etc.) methods any longer. Just use Add and the
wrappers will figure out what to do. <strong>[Changed in 2.5.2.x]</strong>
-AddWindow, AddSize, AddSpacer and etc. will now issue a
+AddWindow, AddSizer, AddSpacer and etc. will now issue a
DeprecationWarning.</p>
<p><strong>[Changed in 2.5.2.x]</strong> The Sizers have had some fundamental internal
changes in the 2.5.2.x release intended to make them do more of the
the "internal" module names have changed, but you shouldn't have been
using them anyway so it shouldn't bother you. ;-) In case you were
erroneously using them in 2.4, here are the internal extension modules
-no longer exist:</p>
+that no longer exist:</p>
<blockquote>
<ul class="simple">
<li>clip_dnd</li>
<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>
</div>
-<div class="section" id="other-stuff">
-<h1><a name="other-stuff">Other Stuff</a></h1>
+<div class="section" id="wx-taskbaricon">
+<h1><a name="wx-taskbaricon">wx.TaskBarIcon</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>wx.TaskbarIcon now works on all three platforms, although for wxGTK it
+depends on support from the Window Manager. On OS X the icon replaces
+the application's icon on the dock and when you right click on it the
+app's default popup menu is merged with the wx.TaskBarIcon's menu.
+Because of how it is implemented on the Mac using the Dock most of the
+TaskBarIcon events will _not_ be emitted on that platform, but since
+98% of the time you simply want to display an icon and have a popup
+menu it shouldn't be much of a problem. You can still use the other
+events on the other platforms, you'll just want to be sure that you
+can do everything you want via the menu too.</p>
+<p>Since popping up a menu is the most common thing to do with a
+TaskBarIcon the class has some new built in functionality to
+facilitate that. To use the TaskBarIcon in this new way, simply
+derive a new class from TaskBarIcon and implement a CreatePopupMenu
+method that creates and returns the menu. That's all there is to it,
+besides binding event handlers for the menu items of course. Take a
+look at the DemoTaskBarIcon class in the demo/Main.py module for an
+example.</p>
+<p><strong>NOTE</strong>: Unfortunately due to being able to support virtualizing
+CreatePopupMenu the C++ TaskBarIcon instance now holds a reference to
+the Python instance, and so you will need to explicitly Destroy() your
+TaskBarIcon instance when you are done with it. (Like you do with
+wx.Dialogs.) If you don't destroy it then wxWidgets will assume that
+you want the app to keep running with just the icon in the task bar
+and the MainLoop will not exit.</p>
+</div>
+<div class="section" id="version-number-change">
+<h1><a name="version-number-change">Version Number Change</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>Starting with 2.5.3.0 the Unicode versions of wxPython will no longer
+have a 'u' appended to the fourth component of the version number.
+Please check for the presence of "unicode" in the <cite>wx.PlatformInfo</cite>
+tuple instead. (This tuple of strings has been available since the
+first 2.5 version.) For example:</p>
+<pre class="literal-block">
+if "unicode" in wx.PlatformInfo:
+ # do whatever
+ ...
+</pre>
+</div>
+<div class="section" id="multi-version-installs">
+<h1><a name="multi-version-installs">Multi-Version Installs</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>Starting with 2.5.3.0 the wx and wxPython pacakge directories will be
+installed in a subdirectory of the site-packages directory, instead of
+directly in site-pacakges. This is done to help facilitate having
+multiple versions of wxPython installed side-by-side. Why would you
+want to do this? One possible scenario is you have an app that
+requires wxPython 2.4 but you want to use the newest 2.5 to do your
+development with. Or perhaps you want to be able to test your app
+with several different versions of wxPython to ensure compatibility.
+Before everyone panics, rest asured that if you only install one
+version of wxPython then you should notice no difference in how
+things work.</p>
+<p>In addition to installing wxPython into a "versioned" subdirectory of
+site-packages, a file named <cite>wx.pth</cite> is optionally installed that will
+contain the name of the versioned subdirectory. This will cause that
+subdirectory to be automatically added to the sys.path and so doing an
+"import wx" will find the package in the subdirectory like like it
+would have if it was still located directly in site-packages. I say
+"optionally" above because that is how you can control which install
+of wxPython is the default one. Which ever version installs the
+wx.pth file will be the one that is imported with a plain "import wx"
+statement. Of course you can always manipulate that by editing the
+wx.pth file, or by setting PYTHONPATH in the environment, or by the
+method described in the next paragraph.</p>
+<p>Finally, a new module named wxversion.py is installed to the
+site-pacakges directory. It can be used to manipulate the sys.path at
+runtime so your applications can select which version of wxPython they
+would like to to have imported. You use it like this:</p>
+<pre class="literal-block">
+import wxversion
+wxversion.require("2.4")
+import wx
+</pre>
+<p>Then eventhough a 2.5 version of wxPython may be the default the
+application that does the above the first time that wx is imported
+will actually get a 2.4 version. <strong>NOTE:</strong> There isn't actually a 2.4
+version of wxPython that supports this, but there will be.</p>
+<p>Please see this wiki page for more details, HowTo's and FAQ's:
+<a class="reference" href="http://wiki.wxpython.org/index.cgi/MultiVersionInstalls">http://wiki.wxpython.org/index.cgi/MultiVersionInstalls</a></p>
+</div>
+<div class="section" id="miscellaneous-stuff">
+<h1><a name="miscellaneous-stuff">Miscellaneous Stuff</a></h1>
<p>wxPyDefaultPosition and wxPyDefaultSize are gone. Use the
wxDefaultPosition and wxDefaultSize objects instead.</p>
<p>Similarly, the wxSystemSettings backwards compatibiility aliases for
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>
-<p>wx.TaskbarIcon works on wxGTK-based platforms (for some window
-managers,) however you have to manage it a little bit more than you
-did before. Basically, the app will treat it like a top-level frame
-in that if the wx.TaskBarIcon still exists when all the frames are
-closed then the app will still not exit. You need to ensure that the
-wx.TaskBarIcon is destroyed when your last Frame is closed. For
-wxPython apps it is usually enough if your main frame object holds the
-only reference to the wx.TaskBarIcon, then when the frame is closed
-Python reference counting takes care of the rest.</p>
<p>Before Python 2.3 it was possible to pass a floating point object as a
parameter to a function that expected an integer, and the
PyArg_ParseTuple family of functions would automatically convert to
Here is one of them, it is the <tt class="literal"><span class="pre">simple</span></tt> sample.</p>
<pre class="literal-block">
#----------------------------------------------------------------------
-# A very simple wxPython example. Just a wxFrame, wxPanel,
-# wxStaticText, wxButton, and a wxBoxSizer, but it shows the basic
+# A very simple wxPython example. Just a wx.Frame, wx.Panel,
+# wx.StaticText, wx.Button, and a wx.BoxSizer, but it shows the basic
# structure of any wxPython application.
#----------------------------------------------------------------------
class MyApp(wx.App):
def OnInit(self):
frame = MyFrame(None, "Simple wxPython App")
- frame.Show(True)
self.SetTopWindow(frame)
+
+ print "Print statements go to this stdout window by default."
+
+ frame.Show(True)
return True
-app = MyApp(True)
+app = MyApp(redirect=True)
app.MainLoop()
projects / wxWidgets.git / commitdiff
