Regenned the ReST docs
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@27702 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -44,6 +44,15 @@ whereever you checked out the wxWidgets module from CVS, or untarred
|
||||
the wxPythonSrc 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
|
||||
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
|
||||
differences between the W.X.Y release of wxWidgets and the W.X.Y.Z
|
||||
release of wxPython.</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
|
||||
@@ -131,7 +140,7 @@ instead.</p>
|
||||
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
|
||||
time. If you want to install the development version 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
|
||||
@@ -161,16 +170,16 @@ 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>If you get errors about being unable to find libGLU, wxGLCanvas
|
||||
being undeclared, or something similar 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 $WXDIR/wxPython/wxPython and
|
||||
$WXDIR/wxPython/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
|
||||
<li><p class="first">To run code with the development version of wxPython, just set the
|
||||
PYTHONPATH to the wxPython dir located in the source tree. For
|
||||
example:</p>
|
||||
<pre class="literal-block">
|
||||
@@ -212,7 +221,7 @@ 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. This policy will change with Python 2.4
|
||||
and MSVC 7.1 will be used starting with that version.</p>
|
||||
<p>If you want to build a debugable version of wxWidgets and wxPython you
|
||||
<p>If you want to build a debuggable version of wxWidgets 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
|
||||
@@ -221,15 +230,31 @@ 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
|
||||
wxWidgets, but I use some non-standard stuff to do it. So if you want
|
||||
to use my scripts 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 alot of steps involved and I won't be going into details
|
||||
here. There is a copy of my build scripts in %WXDIR%wxPythondistribmsw
|
||||
that you can use for reference (if you don't use them directly) for
|
||||
adapting these instructions to your specific needs. The directions
|
||||
below assume that you are using my scripts.</p>
|
||||
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
|
||||
programs then there is a copy of my wxWidgets build scripts in
|
||||
%WXDIR%\wxPython\distrib\msw. Just copy them to
|
||||
%WXDIR%\build\msw and you can use them to do your build, otherwise
|
||||
you can do everything by hand as described below. But if you do work
|
||||
by hand and something doesn't seem to be working correctly please
|
||||
refer to the build scripts to see what may need to be done
|
||||
differently.</p>
|
||||
<p>The <a href="#id1" name="id2"><span class="problematic" id="id2">*</span></a>.btm files are for 4NT and the others are for bash. They are:</p>
|
||||
<div class="system-message" id="id1">
|
||||
<p class="system-message-title">System Message: <a name="id1">WARNING/2</a> (<tt>/home/work/projects/wx2.5/wxPython/docs/BUILD.txt</tt>, line 259); <em><a href="#id2">backlink</a></em></p>
|
||||
Inline emphasis start-string without end-string.</div>
|
||||
<blockquote>
|
||||
<p>.make/.make.btm Builds the main lib and the needed contribs
|
||||
.mymake/.mymake.btm Builds just one lib, use by .make
|
||||
.makesetup.mk A makefile that will copy and edit setup.h</p>
|
||||
<div class="system-message">
|
||||
<p class="system-message-title">System Message: ERROR/3 (<tt>/home/work/projects/wx2.5/wxPython/docs/BUILD.txt</tt>, line 264)</p>
|
||||
Unexpected indentation.</div>
|
||||
<blockquote>
|
||||
as needed for the different types of builds</blockquote>
|
||||
</blockquote>
|
||||
<p>Okay. Here's what you've been waiting for, the instructions! Adapt
|
||||
accordingly if you are using the bash shell.</p>
|
||||
<ol class="arabic">
|
||||
<li><p class="first">Set an environment variable to the root of the wxWidgets source
|
||||
tree. This is used by the makefiles:</p>
|
||||
@@ -237,16 +262,13 @@ tree. This is used by the makefiles:</p>
|
||||
set WXWIN=%WXDIR%
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">Copy setup0.h to setup.h</p>
|
||||
<blockquote>
|
||||
<p>cd %WXDIR%includewxmsw
|
||||
copy setup0.h setup.h</p>
|
||||
</blockquote>
|
||||
<li><p class="first">Copy setup0.h to setup.h:</p>
|
||||
<pre class="literal-block">
|
||||
cd %WXDIR%\include\wx\msw
|
||||
copy setup0.h setup.h
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">Edit %WXDIR%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>
|
||||
<li><p class="first">Edit %WXDIR%\include\wx\msw\setup.h and change a few settings:</p>
|
||||
<pre class="literal-block">
|
||||
wxDIALOG_UNIT_COMPATIBILITY 0
|
||||
wxUSE_DEBUG_CONTEXT 1
|
||||
@@ -257,18 +279,33 @@ wxUSE_POSTSCRIPT 1
|
||||
wxUSE_AFM_FOR_POSTSCRIPT 0
|
||||
wxUSE_DISPLAY 1
|
||||
</pre>
|
||||
<p>If you are using my build scripts then a few more settings will be
|
||||
changed and then a copy of setup.h is placed in a subdir of
|
||||
%WXWIN%\libvc_dll. If you are doing it by hand and making a
|
||||
UNICODE build, then also change these:</p>
|
||||
<pre class="literal-block">
|
||||
wxUSE_UNICODE 1
|
||||
wxUSE_UNICODE_MSLU 1
|
||||
</pre>
|
||||
<p>If you are doing a "hybrid" build (which is the same as the
|
||||
binaries that I release) then also change these:</p>
|
||||
<pre class="literal-block">
|
||||
wxUSE_MEMORY_TRACING 0
|
||||
wxUSE_DEBUG_CONTEXT 0
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">Make sure that %WXDIR%libvc_dll directory is on the PATH. The
|
||||
<li><p class="first">Make sure that %WXDIR%\lib\vc_dll directory is on the PATH. The
|
||||
wxWidgets DLLs will end up there as part of the build and so you'll
|
||||
need it on the PATH for them to be found at runtime.</p>
|
||||
</li>
|
||||
<li><p class="first">Change to the %WXDIR%buildmsw directory and copy my build scripts
|
||||
there from their default location in %WXDIR%wxPythondistribmsw
|
||||
if they are not present already.</p>
|
||||
<li><p class="first">Change to the %WXDIR%\build\msw directory</p>
|
||||
<blockquote>
|
||||
<p>cd %WXDIR%\build\msw</p>
|
||||
</blockquote>
|
||||
</li>
|
||||
<li><p class="first">Use the .make.btm command to build wxWidgets. It needs one
|
||||
command-line parameter which controls what kind of build(s) to do.
|
||||
Use one of the following:</p>
|
||||
<li><p class="first">If using my scripts then use the .make.btm command to build
|
||||
wxWidgets. 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
|
||||
@@ -280,18 +317,45 @@ both-uni and finally both unicode libraries
|
||||
<p>For example:</p>
|
||||
<pre class="literal-block">
|
||||
.make hybrid
|
||||
|
||||
You can also pass additional command line parameters as needed and
|
||||
</pre>
|
||||
<p>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::
|
||||
|
||||
clean up the build:</p>
|
||||
<pre class="literal-block">
|
||||
.make hybrid clean
|
||||
</pre>
|
||||
<p>If <em>not</em> using my scripts then you can do it by hand by directly
|
||||
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
|
||||
</pre>
|
||||
<p>If doing a debug build then add:</p>
|
||||
<pre class="literal-block">
|
||||
BUILD=debug
|
||||
</pre>
|
||||
<p>otherwise add these:</p>
|
||||
<pre class="literal-block">
|
||||
DEBUG_FLAG=1 CXXFLAGS=/D__NO_VC_CRTDBG__ WXDEBUGFLAG=h BUILD=release
|
||||
</pre>
|
||||
<p>If doing a Unicode build then add these flags:</p>
|
||||
<pre class="literal-block">
|
||||
UNICODE=1 MSLU=1
|
||||
</pre>
|
||||
<p>Now, from the %WXDIR%\build\msw directory run nmake with your
|
||||
selection of command-line flags as described above. Repeat this
|
||||
same command from the following directories in order to build the
|
||||
contrib libraries:</p>
|
||||
<pre class="literal-block">
|
||||
%WXDIR%\contrib\build\gizmos
|
||||
%WXDIR%\contrib\build\xrc
|
||||
%WXDIR%\contrib\build\stc
|
||||
%WXDIR%\contrib\build\ogl
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">When that is done it will have built the main wxWidgets 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><p class="first">When that is all done it will have built the main wxWidgets DLLs
|
||||
and also some of the contribs DLLs. There should be a ton of DLLs
|
||||
and lots of lib files and other stuff in %WXDIR%\lib\vc_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
|
||||
@@ -299,9 +363,9 @@ 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 %WXDIR%wxPython dir and run the this command,
|
||||
makeing sure that you use the version of python that you want to
|
||||
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>
|
||||
<pre class="literal-block">
|
||||
cd %WXDIR%\wxPython
|
||||
@@ -328,7 +392,7 @@ wxPython and wx packages locally in %WXDIR%/wxPython/wxPython and
|
||||
%WXDIR%/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
|
||||
<li><p class="first">To run code with the development version of wxPython, just set the
|
||||
PYTHONPATH to the wxPython dir in the CVS tree. For example:</p>
|
||||
<pre class="literal-block">
|
||||
set PYTHONPATH=%WXDIR%\wxPython
|
||||
|
@@ -11,7 +11,95 @@
|
||||
<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.1.5</a></h1>
|
||||
<h1><a name="id1">2.5.2.0</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
|
||||
be used for the minimum size used by the sizer. The wx.FIXED_MINSIZE
|
||||
flag was added that will cause the sizer to use the old behaviour in
|
||||
that it will <em>not</em> call the window's methods to determine the new best
|
||||
size, instead the minsize that the window had when added to the sizer
|
||||
(or the size the window was created with) will always be used.</p>
|
||||
<p>Related to the above, when controls and some other window types are
|
||||
created either the size passed to the constructor, or their "best
|
||||
size" if an explicit size was not passed in, is set as the window's
|
||||
minimal size. For non top-level windows that hasn't meant much in the
|
||||
past, but now the sizers are sensitive to the window's minimal size.
|
||||
The key point to understand here is that it is no longer the window's
|
||||
size it has when added to the sizer that matters, but its minimal
|
||||
size. So you might have some issues to iron out if you create a
|
||||
control without a size and then set its size to something before
|
||||
adding it to the sizer. Since it's minimal size is probably not the
|
||||
size you set then the sizer will appear to be misbehaving. The fix is
|
||||
to either set the size when calling the window's constructor, or to
|
||||
reset the min size by calling SetSizeHints. You can call SetSizeHints
|
||||
at anytime to change the minsize of a window, just call the sizer's
|
||||
Layout method to redistribute the controls as needed.</p>
|
||||
<p>Added new MaskedEditControl code from Will Sadkin. The modules are
|
||||
now locaed in their own sub-package, wx.lib.masked. Demos updated.</p>
|
||||
<p>The changes that implemented the incompatible wx.DC methods in 2.5.1.5
|
||||
have been reverted. The wx.DC methods are now compatible with the 2.4
|
||||
implemetation. In addition a set of renamed methods have been added
|
||||
that take wx.Point and/or wx.Size objects instead of individual
|
||||
parameters.</p>
|
||||
<p>Added wx.lib.mixins.listctrl.TextEditMixin, a mixin class that allows
|
||||
all columns of a wx.ListCtrl in report mode to be edited.</p>
|
||||
<p>Deprecated the wx.iewin module.</p>
|
||||
<p>Deprecated the wx.Sizer.AddWindow, AddSizer, AddSpacer methods as well
|
||||
as their Insert* and Prepend* counterparts.</p>
|
||||
<p>Added a generic StaticBitmap class in wx.lib.statbmp for the same
|
||||
reasons that stattext was created, so it could be mouse sensitive on
|
||||
all platforms like normal windows. Also updated stattext.py and
|
||||
buttons.py to handle attribute (font & colour) defaults and
|
||||
inheritance the new way. If you have custom controls of your own you
|
||||
should review stattxt.py or one of the others to see how it is to be
|
||||
done.</p>
|
||||
<p>wx.InitAllImageHandlers is now an empty function that does nothing but
|
||||
exist for backwards compatibility. The C++ version is now called
|
||||
automatically when wxPython is initialized. Since all the handlers
|
||||
are included in the wxWidgets shared library anyway, this imposes only
|
||||
a very small amount of overhead and removes several unneccessary
|
||||
problems.</p>
|
||||
<p>Replaced wx/lib/pubsub.py with a version that uses weak references to
|
||||
track the subscribers, plus other fixes/additions. Thanks go to
|
||||
Oliver Schoenborn and Robb Shecter.</p>
|
||||
<p>wxGTK now uses gtk_init_check so wxPython can raise an exception if
|
||||
there is no DISPLAY available or other initializaion problem.</p>
|
||||
<p>wx.GetKeyState now has an implementation for wxGTK and is able to
|
||||
detect the up/down or toggle state of modifier and toggle keys.</p>
|
||||
<p>The LC_NUMERIC locale is now reset back to "C" (compatibility) when
|
||||
running on wxGTK to work around the fact that GTK requires the locale
|
||||
to be set to the system settings but Python depends on LC_NUMERIC
|
||||
remaining compatible with "C".</p>
|
||||
<p>Switched gizmos.TreeListCtrl to the newer version of the code from the
|
||||
wxCode project.</p>
|
||||
<p>OGL is dead! LONG LIVE OGL! (Oops, sorry. A bit of my dramatic side
|
||||
leaked out there...) The wx.ogl module has been deprecated in favor
|
||||
of the new Python port of the OGL library located at wx.lib.ogl
|
||||
contributed by Pierre Hj<48>lm. This will hopefully greatly extend the
|
||||
life of OGL within wxPython by making it more easily maintainable and
|
||||
less prone to getting rusty as there seems to be less and less
|
||||
interest in maintaining the C++ version. At this point there are just
|
||||
a couple minor known compatibility differences, please see the
|
||||
<a class="reference" href="MigrationGuide.html">MigrationGuide</a> file for details.</p>
|
||||
<p>EVT_STC_POSCHANGED has been removed as it has been deprecated in
|
||||
Scintilla for several releases now.</p>
|
||||
<p>All the Window and GDI (pen, bitmap, etc.) class constructors and also
|
||||
many toplevel functions and static methods will now check that a
|
||||
wx.App object has already been created and will raise a
|
||||
wx.PyNoAppError exception if not.</p>
|
||||
<p>Added more default args as needed to allow most window types to be
|
||||
constructed with only the parent window arg. In some cases other args
|
||||
may be required for normal operation, but they can usually be set
|
||||
after construction.</p>
|
||||
<p>Removed the deprecated ErrorDialogs and PythonBitmaps modules. If you
|
||||
were using these in your apps then please join wxPython-dev and assist
|
||||
with a more modern reimplementation.</p>
|
||||
<p>Added a new version (0.8.3) of FloatCanvas from Chris Barker. It's now
|
||||
in a subpackage of wx.lib.</p>
|
||||
</div>
|
||||
<div class="section" id="id2">
|
||||
<h1><a name="id2">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>
|
||||
@@ -47,7 +135,7 @@ distros please send me a patch.</p>
|
||||
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 Python pacakges, and also the command-line tool
|
||||
extension modules and Python packages, 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
|
||||
@@ -92,8 +180,8 @@ migrating away from using activexwrapper as well. Please see the
|
||||
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="id2">
|
||||
<h1><a name="id2">2.4.2.4</a></h1>
|
||||
<div class="section" id="id4">
|
||||
<h1><a name="id4">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
|
||||
@@ -102,8 +190,8 @@ demonstrated in the Threads sample in the demo.</p>
|
||||
<p>Added wxMaskedNumCtrl.</p>
|
||||
<p>Added Chris Barker's FloatCanvas.</p>
|
||||
</div>
|
||||
<div class="section" id="id3">
|
||||
<h1><a name="id3">2.4.1.2</a></h1>
|
||||
<div class="section" id="id5">
|
||||
<h1><a name="id5">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
|
||||
@@ -154,8 +242,8 @@ 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="id4">
|
||||
<h1><a name="id4">2.4.0.7</a></h1>
|
||||
<div class="section" id="id6">
|
||||
<h1><a name="id6">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
|
||||
@@ -185,8 +273,8 @@ think I am testing in the future...</p>
|
||||
<p>Updated pycolourchooser.</p>
|
||||
<p>Updated to 0.9b of PyCrust.</p>
|
||||
</div>
|
||||
<div class="section" id="id5">
|
||||
<h1><a name="id5">2.4.0.4</a></h1>
|
||||
<div class="section" id="id7">
|
||||
<h1><a name="id7">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>
|
||||
@@ -242,25 +330,25 @@ doesn't have a standard place for them.</p>
|
||||
<p>Fixed typemaps for wxGridCellCoordsArray.</p>
|
||||
<p>Updated to the 0.9a version of PyCrust</p>
|
||||
</div>
|
||||
<div class="section" id="id6">
|
||||
<h1><a name="id6">2.4.0.2</a></h1>
|
||||
<div class="section" id="id8">
|
||||
<h1><a name="id8">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="id7">
|
||||
<h1><a name="id7">2.4.0.1</a></h1>
|
||||
<div class="section" id="id9">
|
||||
<h1><a name="id9">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="id8">
|
||||
<h1><a name="id8">2.3.4.2</a></h1>
|
||||
<div class="section" id="id10">
|
||||
<h1><a name="id10">2.3.4.2</a></h1>
|
||||
<p>Various bug fixes.</p>
|
||||
</div>
|
||||
<div class="section" id="id9">
|
||||
<h1><a name="id9">2.3.4.1</a></h1>
|
||||
<div class="section" id="id11">
|
||||
<h1><a name="id11">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>
|
||||
@@ -314,8 +402,8 @@ windows when desired.</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="id10">
|
||||
<h1><a name="id10">2.3.3.1</a></h1>
|
||||
<div class="section" id="id12">
|
||||
<h1><a name="id12">2.3.3.1</a></h1>
|
||||
<p>Added wxSplashScreen.</p>
|
||||
<p>Added wxGenericDirCtrl.</p>
|
||||
<p>Added wxMultiChoiceDialog.</p>
|
||||
@@ -457,15 +545,15 @@ 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="id11">
|
||||
<h1><a name="id11">2.3.2.1</a></h1>
|
||||
<div class="section" id="id13">
|
||||
<h1><a name="id13">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="id12">
|
||||
<h1><a name="id12">2.3.2</a></h1>
|
||||
<div class="section" id="id14">
|
||||
<h1><a name="id14">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,
|
||||
@@ -547,8 +635,8 @@ 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="id13">
|
||||
<h1><a name="id13">2.3.1</a></h1>
|
||||
<div class="section" id="id15">
|
||||
<h1><a name="id15">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>
|
||||
@@ -561,8 +649,8 @@ subclass wxXmlResourceHandler, etc...</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="id14">
|
||||
<h1><a name="id14">2.3.0</a></h1>
|
||||
<div class="section" id="id16">
|
||||
<h1><a name="id16">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
|
||||
@@ -658,13 +746,13 @@ please send it to me for inclusion in this package.</p>
|
||||
by having smaller functional apps to play with. They can be found in
|
||||
wxPython/samples.</p>
|
||||
</div>
|
||||
<div class="section" id="id15">
|
||||
<h1><a name="id15">2.2.6</a></h1>
|
||||
<div class="section" id="id17">
|
||||
<h1><a name="id17">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="id16">
|
||||
<h1><a name="id16">2.2.5</a></h1>
|
||||
<div class="section" id="id18">
|
||||
<h1><a name="id18">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
|
||||
|
@@ -97,8 +97,8 @@ install MacPython-OSX-2.3 from <a class="reference" href="http://www.python.org/
|
||||
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,
|
||||
instead. However, on Panther the site-packages dir is sym-linked
|
||||
to /Library/Python/2.3 so the wxPython packages 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
|
||||
@@ -119,7 +119,8 @@ assertions into Python exceptions, then use "release" instead of
|
||||
"hybrid" when building wxWidgets and add "FINAL=1" to the setup.py
|
||||
command line.</p>
|
||||
</li>
|
||||
<li><p class="first">Install wxPython like this:</p>
|
||||
<li><p class="first">Install wxPython like this. Remember to add any additional flags
|
||||
you added for the build such as UNICODE or USE_SWIG:</p>
|
||||
<pre class="literal-block">
|
||||
python setup.py install
|
||||
</pre>
|
||||
@@ -128,7 +129,7 @@ python setup.py install
|
||||
found at runtime by the extension modules without requiring that
|
||||
they be installed on the PATH:</p>
|
||||
<pre class="literal-block">
|
||||
copy %WXWIN%\lib\vc_dll\wx*h_*.dll c:\Python23\Lib\site-pacakges\wx
|
||||
copy %WXWIN%\lib\vc_dll\wx*h_*.dll c:\Python23\Lib\site-packages\wx
|
||||
</pre>
|
||||
</li>
|
||||
</ol>
|
||||
|
@@ -11,17 +11,17 @@
|
||||
<div class="document" id="wxpython-2-5-migration-guide">
|
||||
<h1 class="title">wxPython 2.5 Migration Guide</h1>
|
||||
<p>This document will help explain some of the major changes in wxPython
|
||||
2.5 and let you know what you need to do to adapt your programs to
|
||||
those changes. Be sure to also check in the <a class="reference" href="CHANGES.html">CHANGES</a> file like
|
||||
usual to see info about the not so major changes and other things that
|
||||
have been added to wxPython.</p>
|
||||
2.5 since the 2.4 series and let you know what you need to do to adapt
|
||||
your programs to those changes. Be sure to also check in the <a class="reference" href="CHANGES.html">CHANGES</a>
|
||||
file like usual to see info about the not so major changes and other
|
||||
things that have been added to wxPython.</p>
|
||||
<div class="section" id="wxname-change">
|
||||
<h1><a name="wxname-change">wxName Change</a></h1>
|
||||
<p>The <strong>wxWindows</strong> project and library is now known as
|
||||
<strong>wxWidgets</strong>. Please see <a class="reference" href="http://www.wxwidgets.org/name.htm">here</a> for more details.</p>
|
||||
<p>This won't really affect wxPython all that much, other than the fact
|
||||
that the wxwindows.org domain name will be changing to wxwidgets.org,
|
||||
so mail list, CVS, and etc. addresses will be changing. We're going
|
||||
that the wxwindows.org domain name has changed to wxwidgets.org,
|
||||
so mail list, CVS, and etc. addresses have also changed. We're going
|
||||
to try and smooth the transition as much as possible, but I wanted you
|
||||
all to be aware of this change if you run into any issues.</p>
|
||||
</div>
|
||||
@@ -46,6 +46,10 @@ yet.</p>
|
||||
<p>Also, you will probably not be able to do any kind of GUI or bitmap
|
||||
operation unless you first have created an app object, (even on
|
||||
Windows where most anything was possible before.)</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> All the Window and GDI (pen, bitmap, etc.)
|
||||
class constructors and also many toplevel functions and static methods
|
||||
will now check that a wx.App object has already been created and will
|
||||
raise a wx.PyNoAppError exception if not.</p>
|
||||
</div>
|
||||
<div class="section" id="swig-1-3">
|
||||
<h1><a name="swig-1-3">SWIG 1.3</a></h1>
|
||||
@@ -54,23 +58,25 @@ customizations added that I hope to get folded back into the main SWIG
|
||||
distribution.) This has some far reaching ramifications:</p>
|
||||
<blockquote>
|
||||
<p>All classes derive from object and so all are now "new-style
|
||||
classes"</p>
|
||||
classes." This also allows you to use mixin classes that are
|
||||
new-style and to use properties, staticmethod, etc.</p>
|
||||
<p>Public data members of the C++ classes are wrapped as Python
|
||||
properties using property() instead of using __getattr__/__setattr__
|
||||
like before. Normally you shouldn't notice any difference, but if
|
||||
you were previously doing something with __getattr__/__setattr__
|
||||
in derived classes then you may have to adjust things.</p>
|
||||
<p>Static C++ methods are wrapped using the staticmethod()
|
||||
feature of Python and so are accessible as ClassName.MethodName
|
||||
as expected. They are still available as top level functions
|
||||
properties using property() instead of using
|
||||
__getattr__/__setattr__ hacks like before. Normally you shouldn't
|
||||
notice any difference, but if you were previously doing something
|
||||
with __getattr__/__setattr__ in derived classes then you may have
|
||||
to adjust things.</p>
|
||||
<p>Static C++ methods are wrapped using the staticmethod() feature of
|
||||
Python and so are accessible as ClassName.MethodName as expected.
|
||||
They are still also available as top level functions named like
|
||||
ClassName_MethodName as before.</p>
|
||||
<p>The relationship between the wxFoo and wxFooPtr classes have
|
||||
changed for the better. Specifically, all instances that you see
|
||||
will be wxFoo even if they are created internally using wxFooPtr,
|
||||
because wxFooPtr.__init__ will change the instance's __class__ as
|
||||
will be wx.Foo even if they are created internally using wx.FooPtr,
|
||||
because wx.FooPtr.__init__ will change the instance's __class__ as
|
||||
part of the initialization. If you have any code that checks
|
||||
class type using something like isinstance(obj, wxFooPtr) you will
|
||||
need to change it to isinstance(obj, wxFoo).</p>
|
||||
class type using something like isinstance(obj, wx.FooPtr) you will
|
||||
need to change it to isinstance(obj, wx.Foo).</p>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="binding-events">
|
||||
@@ -136,7 +142,7 @@ values:</p>
|
||||
</pre>
|
||||
<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
|
||||
change your EVT_* to be an instance of wx.PyEventBinder instead of a
|
||||
function. For example, if you used to have something like this:</p>
|
||||
<pre class="literal-block">
|
||||
myCustomEventType = wxNewEventType()
|
||||
@@ -150,6 +156,16 @@ EVT_MY_CUSTOM_EVENT = wx.PyEventBinder(myCustomEventType, 1)
|
||||
</pre>
|
||||
<p>The second parameter is an integer in [0, 1, 2] that specifies the
|
||||
number of IDs that are needed to be passed to Connect.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> There is also an Unbind method added to
|
||||
wx.EvtHandler that can be used to disconenct event handlers. It looks
|
||||
like this:</p>
|
||||
<pre class="literal-block">
|
||||
def Unbind(self, event, source=None, id=wx.ID_ANY, id2=wx.ID_ANY):
|
||||
"""
|
||||
Disconencts the event handler binding for event from self.
|
||||
Returns True if successful.
|
||||
"""
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="the-wx-namespace">
|
||||
<h1><a name="the-wx-namespace">The wx Namespace</a></h1>
|
||||
@@ -162,12 +178,13 @@ Instead of dynamically changing the names at module load time like in
|
||||
2.4, the compatibility modules are generated at build time and contain
|
||||
assignment statements like this:</p>
|
||||
<pre class="literal-block">
|
||||
wxWindow = wx.core.Window
|
||||
wxWindow = wx._core.Window
|
||||
</pre>
|
||||
<p>Don't let the "core" in the name bother you. That and some other
|
||||
<p>Don't let the "_core" in the name bother you. That and some other
|
||||
modules are implementation details, and everything that was in the
|
||||
wxPython.wx module before will still be in the wx package namespace
|
||||
after this change. So from your code you would use it as wx.Window.</p>
|
||||
after this change. So from your code you would use it as wx.Window or
|
||||
wxWindow if you import from the wxPython.wx module.</p>
|
||||
<p>A few notes about how all of this was accomplished might be
|
||||
interesting... SWIG is now run twice for each module that it is
|
||||
generating code for. The first time it outputs an XML representaion
|
||||
@@ -210,119 +227,77 @@ just fine.</p>
|
||||
</div>
|
||||
<div class="section" id="new-wx-dc-methods">
|
||||
<h1><a name="new-wx-dc-methods">New wx.DC Methods</a></h1>
|
||||
<p>Many of the Draw methods of wx.DC have alternate forms in C++ that take
|
||||
wxPoint or wxSize parameters (let's call these <em>Type A</em>) instead of
|
||||
the individual x, y, width, height, etc. parameters (and we'll call
|
||||
these <em>Type B</em>). In the rest of the library I normally made the <em>Type
|
||||
A</em> forms of the methods be the default method with the "normal" name,
|
||||
and had renamed the <em>Type B</em> forms of the methods to some similar
|
||||
name. For example in wx.Window we have these Python methods:</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> In wxPython 2.5.1.5 there was a new
|
||||
implementation of the wx.DC Draw and other methods that broke
|
||||
backwards compatibility in the name of consistency. That change has
|
||||
been reverted and the wx.DC Draw methods with 2.4 compatible
|
||||
signatures have been restored. In addition a new set of methods have
|
||||
been added that take wx.Point and/or wx.Size parameters instead of
|
||||
separate integer parameters. The Draw and etc. methods now available
|
||||
in the wx.DC class are:</p>
|
||||
<pre class="literal-block">
|
||||
SetSize(size) # Type A
|
||||
SetSizeWH(width, height) # Type B
|
||||
FloodFill(self, x, y, colour, style = wx.FLOOD_SURFACE)
|
||||
FoodFillPoint(self, pt, colour, style = wx.FLOOD_SURFACE)
|
||||
|
||||
GetPixel(self, x,y)
|
||||
GetPixelPoint(self, pt)
|
||||
|
||||
DrawLine(self, x1, y1, x2, y2)
|
||||
DrawLinePoint(self, pt1, pt2)
|
||||
|
||||
CrossHair(self, x, y)
|
||||
CrossHairPoint(self, pt)
|
||||
|
||||
DrawArc(self, x1, y1, x2, y2, xc, yc)
|
||||
DrawArcPoint(self, pt1, pt2, centre)
|
||||
|
||||
DrawCheckMark(self, x, y, width, height)
|
||||
DrawCheckMarkRect(self, rect)
|
||||
|
||||
DrawEllipticArc(self, x, y, w, h, sa, ea)
|
||||
DrawEllipticArcPointSize(self, pt, sz, sa, ea)
|
||||
|
||||
DrawPoint(self, x, y)
|
||||
DrawPointPoint(self, pt)
|
||||
|
||||
DrawRectangle(self, x, y, width, height)
|
||||
DrawRectangleRect(self, rect)
|
||||
DrawRectanglePointSize(self, pt, sz)
|
||||
|
||||
DrawRoundedRectangle(self, x, y, width, height, radius)
|
||||
DrawRoundedRectangleRect(self, r, radius)
|
||||
DrawRoundedRectanglePointSize(self, pt, sz, radius)
|
||||
|
||||
DrawCircle(self, x, y, radius)
|
||||
DrawCirclePoint(self, pt, radius)
|
||||
|
||||
DrawEllipse(self, x, y, width, height)
|
||||
DrawEllipseRect(self, rect)
|
||||
DrawEllipsePointSize(self, pt, sz)
|
||||
|
||||
DrawIcon(self, icon, x, y)
|
||||
DrawIconPoint(self, icon, pt)
|
||||
|
||||
DrawBitmap(self, bmp, x, y, useMask = False)
|
||||
DrawBitmapPoint(self, bmp, pt, useMask = False)
|
||||
|
||||
DrawText(self, text, x, y)
|
||||
DrawTextPoint(self, text, pt)
|
||||
|
||||
DrawRotatedText(self, text, x, y, angle)
|
||||
DrawRotatedTextPoint(self, text, pt, angle)
|
||||
|
||||
bool Blit(self, xdest, ydest, width, height, sourceDC, xsrc, ysrc,
|
||||
rop = wx.COPY, useMask = False, xsrcMask = -1, ysrcMask = -1)
|
||||
BlitPointSize(self, destPt, sz, sourceDC, srcPt, rop = wx.COPY,
|
||||
useMask = False, srcPtMask = wxDefaultPosition)
|
||||
|
||||
|
||||
SetClippingRegion(self, x, y, width, height)
|
||||
SetClippingRegionPointSize(self, pt, sz)
|
||||
SetClippingRegionAsRegion(self, region)
|
||||
SetClippingRect(self, rect)
|
||||
</pre>
|
||||
<p>For various reasons the new <em>Type A</em> methods in wx.DC were never added
|
||||
and the existing <em>Type B</em> methods were never renamed. Now that lots
|
||||
of other things are also changing in wxPython it has been decided that
|
||||
it is a good time to also do the method renaming in wx.DC too in order
|
||||
to be consistent with the rest of the library. The methods in wx.DC
|
||||
that are affected are listed here:</p>
|
||||
<pre class="literal-block">
|
||||
FloodFillXY(x, y, colour, style = wx.FLOOD_SURFACE)
|
||||
FloodFill(point, colour, style = wx.FLOOD_SURFACE)
|
||||
|
||||
GetPixelXY(x, y)
|
||||
GetPixel(point)
|
||||
|
||||
DrawLineXY(x1, y1, x2, y2)
|
||||
DrawLine(point1, point2)
|
||||
|
||||
CrossHairXY(x, y)
|
||||
CrossHair(point)
|
||||
|
||||
DrawArcXY(x1, y1, x2, y2, xc, yc)
|
||||
DrawArc(point1, point2, center)
|
||||
|
||||
DrawCheckMarkXY(x, y, width, height)
|
||||
DrawCheckMark(rect)
|
||||
|
||||
DrawEllipticArcXY(x, y, w, h, start_angle, end_angle)
|
||||
DrawEllipticArc(point, size, start_angle, end_angle)
|
||||
|
||||
DrawPointXY(x, y)
|
||||
DrawPoint(point)
|
||||
|
||||
DrawRectangleXY(x, y, width, height)
|
||||
DrawRectangle(point, size)
|
||||
DrawRectangleRect(rect)
|
||||
|
||||
DrawRoundedRectangleXY(x, y, width, height, radius)
|
||||
DrawRoundedRectangle(point, size, radius)
|
||||
DrawRoundedRectangleRect(rect, radius)
|
||||
|
||||
DrawCircleXY(x, y, radius)
|
||||
DrawCircle(point, radius)
|
||||
|
||||
DrawEllipseXY(x, y, width, height)
|
||||
DrawEllipse(point, size)
|
||||
DrawEllipseRect(rect)
|
||||
|
||||
DrawIconXY(icon, x, y)
|
||||
DrawIcon(icon, point)
|
||||
|
||||
DrawBitmapXY(bmp, x, y, useMask = FALSE)
|
||||
DrawBitmap(bmp, point, useMask = FALSE)
|
||||
|
||||
DrawTextXY(text, x, y)
|
||||
DrawText(text, point)
|
||||
|
||||
DrawRotatedTextXY(text, x, y, angle)
|
||||
DrawRotatedText(text, point, angle)
|
||||
|
||||
|
||||
BlitXY(xdest, ydest, width, height, sourceDC, xsrc, ysrc,
|
||||
rop = wxCOPY, useMask = FALSE, xsrcMask = -1, ysrcMask = -1)
|
||||
Blit(destPt, size, sourceDC, srcPt,
|
||||
rop = wxCOPY, useMask = FALSE, srcPtMask = wx.DefaultPosition)
|
||||
|
||||
SetClippingRegionXY(x, y, width, height)
|
||||
SetClippingRegion(point, size)
|
||||
SetClippingRect(rect)
|
||||
SetClippingRegionAsRegion(region);
|
||||
</pre>
|
||||
<p>If you have code that draws on a DC and you are using the new wx
|
||||
namespace then you <strong>will</strong> get errors because of these changes, but
|
||||
it should be easy to fix the code. You can either change the name of
|
||||
the <em>Type B</em> method called to the names shown above, or just add
|
||||
parentheses around the parameters as needed to turn them into tuples
|
||||
and let the SWIG typemaps turn them into the wx.Point or wx.Size
|
||||
object that is expected. Then you will be calling the new <em>Type A</em>
|
||||
method. For example, if you had this code before:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle(x, y, width, height)
|
||||
</pre>
|
||||
<p>You could either continue to use the <em>Type B</em> method by changing the
|
||||
name to DrawRectangleXY, or just change it to the new <em>Type A</em> by
|
||||
adding some parentheses like this:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle((x, y), (width, height))
|
||||
</pre>
|
||||
<p>Or if you were already using a point and size like this:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle(p.x, p.y, s.width, s.height)
|
||||
</pre>
|
||||
<p>Then you can just simplify it like this:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle(p, s)
|
||||
</pre>
|
||||
<p>Now before you start yelling and screaming at me for breaking all your
|
||||
code, take note that up above I said, "...using the new wx namespace..."
|
||||
That's because if you are still importing from wxPython.wx then there
|
||||
are some classes defined there with Draw and etc. methods that have
|
||||
2.4 compatible signatures. However if/when the old wxPython.wx
|
||||
namespace is removed then these classes will be removed too so you
|
||||
should plan on migrating to the new namespace and new DC Draw methods
|
||||
before that time.</p>
|
||||
</div>
|
||||
<div class="section" id="building-extending-and-embedding-wxpython">
|
||||
<h1><a name="building-extending-and-embedding-wxpython">Building, Extending and Embedding wxPython</a></h1>
|
||||
@@ -384,15 +359,49 @@ class MyDialog(wx.Dialog):
|
||||
<h1><a name="sizers">Sizers</a></h1>
|
||||
<p>The hack allowing the old "option" keyword parameter has been removed.
|
||||
If you use keyword args with w.xSizer Add, Insert, or Prepend methods
|
||||
then you will need to use the <tt class="literal"><span class="pre">proportion</span></tt> name instead of <tt class="literal"><span class="pre">option</span></tt>.</p>
|
||||
then you will need to use the <tt class="literal"><span class="pre">proportion</span></tt> name instead of
|
||||
<tt class="literal"><span class="pre">option</span></tt>. (The <tt class="literal"><span class="pre">proportion</span></tt> keyword was also allowed in 2.4.2.4.)</p>
|
||||
<p>When adding a spacer to a sizer you now need to use a wx.Size or a
|
||||
2-integer sequence instead of separate width and height parameters.</p>
|
||||
2-integer sequence instead of separate width and height parameters.
|
||||
This was optionally allowed in 2.4, but now it is required. This
|
||||
allows for more consistency in how you add the various types of items
|
||||
to a sizer. The first parameter defines the item (instead of the
|
||||
possibily first two, depending on if you are doing a spacer or not,)
|
||||
and that item can either be a window, a sizer or a spacer (which can
|
||||
be a sequence or a wx.Size.) Removing the option for separate width
|
||||
and height parameters greatly simplified the wrapper code.</p>
|
||||
<p>The wx.GridBagSizer class (very similar to the RowColSizer in the
|
||||
library) has been added to C++ and wrapped for wxPython. It can also
|
||||
be used from XRC.</p>
|
||||
<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.</p>
|
||||
wrappers will figure out what to do. <strong>[Changed in 2.5.2.0]</strong>
|
||||
AddWindow, AddSize, AddSpacer and etc. will now issue a
|
||||
DeprecationWarning.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> 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 be used for the minimum size used
|
||||
by the sizer. The wx.FIXED_MINSIZE flag was added that will cause the
|
||||
sizer to use the old behaviour in that it will <em>not</em> call the window's
|
||||
methods to determine the new best size, instead the minsize that the
|
||||
window had when added to the sizer (or the size the window was created
|
||||
with) will always be used.</p>
|
||||
<p>Related to the above, when controls and some other window types are
|
||||
created either the size passed to the constructor, or their "best
|
||||
size" if an explicit size was not passed in, is set as the window's
|
||||
minimal size. For non top-level windows that hasn't meant much in the
|
||||
past, but now the sizers are sensitive to the window's minimal size.
|
||||
The key point to understand here is that it is no longer the window's
|
||||
size it has when added to the sizer that matters, but its minimal
|
||||
size. So you might have some issues to iron out if you create a
|
||||
control without a size and then set its size to something before
|
||||
adding it to the sizer. Since it's minimal size is probably not the
|
||||
size you set then the sizer will appear to be misbehaving. The fix is
|
||||
to either set the size when calling the window's constructor, or to
|
||||
reset the min size by calling SetSizeHints. You can call SetSizeHints
|
||||
at anytime to change the minsize of a window, just call the sizer's
|
||||
Layout method to redistribute the controls as needed.</p>
|
||||
</div>
|
||||
<div class="section" id="platforminfo">
|
||||
<h1><a name="platforminfo">PlatformInfo</a></h1>
|
||||
@@ -517,22 +526,141 @@ output appended as a comment to the modules produced by the
|
||||
genaxmodule tool. Beyond that you'll need to consult the docs
|
||||
provided by the makers of the ActiveX control that you are using.</p>
|
||||
</div>
|
||||
<div class="section" id="other-stuff">
|
||||
<h1><a name="other-stuff">Other Stuff</a></h1>
|
||||
<div class="section" id="png-images">
|
||||
<h1><a name="png-images">PNG Images</a></h1>
|
||||
<p>Prior to 2.5 the PNG image handler would convert all alpha channel
|
||||
information to a mask when the image was loaded. Pixels that were
|
||||
more than halfway transparent would be made fully transparent by the
|
||||
mask and the rest would be made fully opaque.</p>
|
||||
<p>In 2.5 the image handler has been updated to preserve the alpha
|
||||
channel and will now only create a mask when all the pixels in the
|
||||
image are either fully transparent or fully opaque. In addition, the
|
||||
wx.DC.DrawBitmap and wx.DC.Blit methods are able to correctly blend
|
||||
the pixels in the image with partially transparent alpha values.
|
||||
(Currently only on MSW and Mac, if anybody knows how to do it for GTK
|
||||
then please submit a patch!)</p>
|
||||
<p>If you are using a PNG with an alpha channel but you need to have a
|
||||
wx.Mask like you automatically got in 2.4 then you can do one of the
|
||||
following:</p>
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>Edit the image and make all the partially transparent pixels be
|
||||
fully transparent.</li>
|
||||
<li>Use a different image type.</li>
|
||||
<li>Set a mask based on colour after you load the image.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="ogl-is-dead-long-live-ogl">
|
||||
<h1><a name="ogl-is-dead-long-live-ogl">OGL is dead! LONG LIVE OGL!</a></h1>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong></p>
|
||||
<p>The wx.ogl module has been deprecated in favor of the new Python port
|
||||
of the OGL library located at wx.lib.ogl contributed by Pierre Hj<48>lm.
|
||||
This will hopefully greatly extend the life of OGL within wxPython by
|
||||
making it more easily maintainable and less prone to getting rusty as
|
||||
there seems to be less and less interest in maintaining the C++
|
||||
version.</p>
|
||||
<p>There are only a few known compatibility issues at this time. First
|
||||
is the location of OGL. The deprecated version is located in the
|
||||
wx.ogl module, and the new version is in the wx.lib.ogl package. So
|
||||
this just means that to start using the new version you need to adjust
|
||||
your imports. So if your code currently has something like this:</p>
|
||||
<pre class="literal-block">
|
||||
import wx
|
||||
import wx.ogl as ogl
|
||||
</pre>
|
||||
<p>Then just change it to this:</p>
|
||||
<pre class="literal-block">
|
||||
import wx
|
||||
import wx.lib.ogl as ogl
|
||||
</pre>
|
||||
<p>The other compatibility issue deals with removing a wart in the
|
||||
original API that was necessary in order to allow overloaded methods
|
||||
in derived classes to call the same method in the base class when
|
||||
using the old SWIG. Instead dedaling with the wart you can now just
|
||||
call the base class method like you woudl for any other Python class.
|
||||
For example, if you had to do something like this previously:</p>
|
||||
<pre class="literal-block">
|
||||
class MyDividedShape(ogl.DividedShape):
|
||||
...
|
||||
def OnSizingEndDragLeft(self, pt, x, y, keys, attch):
|
||||
self.base_OnSizingEndDragLeft(pt, x, y, keys, attch)
|
||||
...
|
||||
</pre>
|
||||
<p>You will need to change it to be like this:</p>
|
||||
<pre class="literal-block">
|
||||
class MyDividedShape(ogl.DividedShape):
|
||||
...
|
||||
def OnSizingEndDragLeft(self, pt, x, y, keys, attch):
|
||||
ogl.DividedShape.OnSizingEndDragLeft(self, pt, x, y, keys, attch)
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="obsolete-modules">
|
||||
<h1><a name="obsolete-modules">Obsolete Modules</a></h1>
|
||||
<p>Instead of over a dozen separate extension modules linked together
|
||||
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 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>
|
||||
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>
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>clip_dnd</li>
|
||||
<li>cmndlgs</li>
|
||||
<li>controls</li>
|
||||
<li>controls2</li>
|
||||
<li>events</li>
|
||||
<li>filesys</li>
|
||||
<li>fonts</li>
|
||||
<li>frames</li>
|
||||
<li>gdi</li>
|
||||
<li>image</li>
|
||||
<li>mdi</li>
|
||||
<li>misc</li>
|
||||
<li>misc2</li>
|
||||
<li>printfw</li>
|
||||
<li>sizers</li>
|
||||
<li>stattool</li>
|
||||
<li>streams</li>
|
||||
<li>utils</li>
|
||||
<li>windows</li>
|
||||
<li>windows2</li>
|
||||
<li>windows3</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p>They have been replaced by the following, but please remember that
|
||||
these are just "implementation details" and you should really be using
|
||||
the objects in these modules only via the wx or wxPython.wx packages:</p>
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>_core</li>
|
||||
<li>_gdi</li>
|
||||
<li>_windows</li>
|
||||
<li>_controls</li>
|
||||
<li>_misc</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<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>
|
||||
<p>wxPyDefaultPosition and wxPyDefaultSize are gone. Use the
|
||||
wxDefaultPosition and wxDefaultSize objects instead.</p>
|
||||
<p>Similarly, the wxSystemSettings backwards compatibiility aliases for
|
||||
GetSystemColour, GetSystemFont and GetSystemMetric have also gone into
|
||||
the bit-bucket. Use GetColour, GetFont and GetMetric instead.</p>
|
||||
<p>Use the Python True/False constants instead of the true, TRUE, false,
|
||||
FALSE that used to be provided with wxPython.</p>
|
||||
<p>Use None instead of the ancient and should have been removed a long
|
||||
time ago wx.NULL alias.</p>
|
||||
<p>wx.TreeCtrl.GetFirstChild no longer needs to be passed the cookie
|
||||
variable as the 2nd parameter. It still returns it though, for use
|
||||
with GetNextChild.</p>
|
||||
<p>The wx.NO_FULL_REPAINT_ON_RESIZE style is now the default style for
|
||||
all windows. The name still exists for compatibility, but it is set
|
||||
to zero. If you want to disable the setting (so it matches the old
|
||||
@@ -546,22 +674,22 @@ wxPyTypeCast at all.</p>
|
||||
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 now, 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>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
|
||||
integer by truncating the fractional portion of the number. With
|
||||
Python 2.3 that behavior was deprecated and a deprecation warning is
|
||||
raised when you pass a floating point value, (for example, calling
|
||||
wx.DC.DrawLineXY with floats for the position and size,) and lots of
|
||||
wx.DC.DrawLine with floats for the position and size,) and lots of
|
||||
developers using wxPython had to scramble to change their code to call
|
||||
int() before calling wxPython methods. Recent changes in SWIG have
|
||||
moved the conversion out of PyArg_ParseTuple to custom code that SWIG
|
||||
@@ -575,6 +703,13 @@ functions in wxPython for parameters that are expecting an integer.
|
||||
If the object is not already an integer then it will be asked to
|
||||
convert itself to one. A similar conversion fragment is in place for
|
||||
parameters that expect floating point values.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> The MaskedEditCtrl modules have been moved
|
||||
to their own sub-package, wx.lib.masked. See the docstrings and demo
|
||||
for changes in capabilities, usage, etc.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> wx.MaskColour constructor has been deprecated
|
||||
and will raise a DeprecationWarning if used. The main wx.Mask
|
||||
constructor has been modified to be compatible with wx.MaskColour so
|
||||
you should use it instead.</p>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
|
@@ -7,7 +7,7 @@
|
||||
<title>The Py Manual</title>
|
||||
<meta name="author" content="Patrick K. O'Brien" />
|
||||
<meta name="organization" content="Orbtech" />
|
||||
<meta name="date" content="2004-03-26" />
|
||||
<meta name="date" content="2004-04-15" />
|
||||
<link rel="stylesheet" href="default.css" type="text/css" />
|
||||
</head>
|
||||
<body>
|
||||
@@ -25,9 +25,9 @@
|
||||
<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>2004-03-26</td></tr>
|
||||
<td>2004-04-15</td></tr>
|
||||
<tr><th class="docinfo-name">Revision:</th>
|
||||
<td>1.4</td></tr>
|
||||
<td>1.5</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<div class="contents topic" id="contents">
|
||||
@@ -45,32 +45,31 @@
|
||||
<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>
|
||||
<li><a class="reference" href="#projects-using-py" id="id15" name="id15">Projects using Py</a></li>
|
||||
<li><a class="reference" href="#history-of-changes" id="id16" name="id16">History of changes</a><ul>
|
||||
<li><a class="reference" href="#to-2004" id="id17" name="id17">0.9.4 (1/25/2004 to //2004)</a></li>
|
||||
<li><a class="reference" href="#to-1-24-2004" id="id18" name="id18">0.9.3 (9/25/2003 to 1/24/2004)</a></li>
|
||||
<li><a class="reference" href="#to-9-25-2003" id="id19" name="id19">0.9.2 (5/3/2003 to 9/25/2003)</a></li>
|
||||
<li><a class="reference" href="#to-5-2-2003" id="id20" name="id20">0.9.1 (3/21/2003 to 5/2/2003)</a></li>
|
||||
<li><a class="reference" href="#to-3-20-2003" id="id21" name="id21">0.9 (2/27/2003 to 3/20/2003)</a></li>
|
||||
<li><a class="reference" href="#to-2-26-2003" id="id22" name="id22">0.8.2 (1/5/2003 to 2/26/2003)</a></li>
|
||||
<li><a class="reference" href="#to-12-25-2002" id="id23" name="id23">0.8.1 (12/20/2002 to 12/25/2002)</a></li>
|
||||
<li><a class="reference" href="#to-12-16-2002" id="id24" name="id24">0.8 (10/29/2002 to 12/16/2002)</a></li>
|
||||
<li><a class="reference" href="#to-8-27-2002" id="id25" name="id25">0.7.2 (2/22/2002 to 8/27/2002)</a></li>
|
||||
<li><a class="reference" href="#to-2-21-2002" id="id26" name="id26">0.7.1 (12/12/2001 to 2/21/2002)</a></li>
|
||||
<li><a class="reference" href="#to-12-11-2001" id="id27" name="id27">0.7 (10/15/2001 to 12/11/2001)</a></li>
|
||||
<li><a class="reference" href="#to-10-12-2001" id="id28" name="id28">0.6.1 (9/19/2001 to 10/12/2001)</a></li>
|
||||
<li><a class="reference" href="#to-9-12-2001" id="id29" name="id29">0.6 (8/21/2001 to 9/12/2001)</a></li>
|
||||
<li><a class="reference" href="#to-8-20-2001" id="id30" name="id30">0.5.4 (8/17/2001 to 8/20/2001)</a></li>
|
||||
<li><a class="reference" href="#id1" id="id31" name="id31">0.5.3 (8/16/2001)</a></li>
|
||||
<li><a class="reference" href="#to-8-15-2001" id="id32" name="id32">0.5.2 (8/14/2001 to 8/15/2001)</a></li>
|
||||
<li><a class="reference" href="#to-8-14-2001" id="id33" name="id33">0.5.1 (8/10/2001 to 8/14/2001)</a></li>
|
||||
<li><a class="reference" href="#id2" id="id34" name="id34">0.5 (8/8/2001)</a></li>
|
||||
<li><a class="reference" href="#to-8-7-2001" id="id35" name="id35">0.4 (8/4/2001 to 8/7/2001)</a></li>
|
||||
<li><a class="reference" href="#to-8-3-2001" id="id36" name="id36">0.3 (8/2/2001 to 8/3/2001)</a></li>
|
||||
<li><a class="reference" href="#to-8-2-2001" id="id37" name="id37">0.2 (7/30/2001 to 8/2/2001)</a></li>
|
||||
<li><a class="reference" href="#to-7-19-2001" id="id38" name="id38">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="id39" name="id39">In the beginning, there was pie... (7/1/2001)</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
@@ -93,8 +92,7 @@ and includes PyCrust, so PyCrust is no longer distributed separately.</p>
|
||||
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
|
||||
source code modules that can be used in your own programs, 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
|
||||
@@ -135,10 +133,7 @@ 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>
|
||||
These modules are the same ones used by all the Py programs.</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>
|
||||
@@ -193,9 +188,7 @@ 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>
|
||||
namespace viewer.</p>
|
||||
</div>
|
||||
<div class="section" id="py-modules">
|
||||
<h1><a class="toc-backref" href="#id14" name="py-modules">Py modules</a></h1>
|
||||
@@ -208,14 +201,8 @@ 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>
|
||||
<h1><a class="toc-backref" href="#id15" 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>
|
||||
@@ -228,11 +215,11 @@ runtime.</p>
|
||||
</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>
|
||||
<h1><a class="toc-backref" href="#id16" 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>
|
||||
<h2><a class="toc-backref" href="#id17" 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
|
||||
@@ -243,12 +230,12 @@ programs and modules, since the beginning.</p>
|
||||
empty dictionary.</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>
|
||||
<h2><a class="toc-backref" href="#id18" 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>
|
||||
<h2><a class="toc-backref" href="#id19" 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
|
||||
@@ -291,7 +278,7 @@ def CanPaste(self):
|
||||
</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>
|
||||
<h2><a class="toc-backref" href="#id20" 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>
|
||||
@@ -326,7 +313,7 @@ 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>
|
||||
<h2><a class="toc-backref" href="#id21" 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">
|
||||
@@ -358,7 +345,7 @@ except NameError:
|
||||
<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>
|
||||
<h2><a class="toc-backref" href="#id22" 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>
|
||||
@@ -393,7 +380,7 @@ func = 3 .
|
||||
<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>
|
||||
<h2><a class="toc-backref" href="#id23" 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
|
||||
@@ -405,7 +392,7 @@ 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>
|
||||
<h2><a class="toc-backref" href="#id24" 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
|
||||
@@ -432,7 +419,7 @@ Platform: linux2
|
||||
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>
|
||||
<h2><a class="toc-backref" href="#id25" 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',
|
||||
@@ -470,7 +457,7 @@ boxes. Renamed <tt class="literal"><span class="pre">readIn</span></tt> to <tt
|
||||
<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>
|
||||
<h2><a class="toc-backref" href="#id26" 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
|
||||
@@ -497,7 +484,7 @@ to insert from history - Shift+Up and Shift+Down.</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>
|
||||
<h2><a class="toc-backref" href="#id27" 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>
|
||||
@@ -521,7 +508,7 @@ package/module name conflicts that kept you from doing <tt class="literal"><span
|
||||
<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>
|
||||
<h2><a class="toc-backref" href="#id28" 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
|
||||
@@ -539,7 +526,7 @@ 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>
|
||||
<h2><a class="toc-backref" href="#id29" 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>
|
||||
@@ -560,7 +547,7 @@ sys.path.insert(0, os.curdir)
|
||||
<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>
|
||||
<h2><a class="toc-backref" href="#id30" 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,
|
||||
@@ -578,14 +565,14 @@ demo.</p>
|
||||
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>
|
||||
<h2><a class="toc-backref" href="#id31" 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>
|
||||
<h2><a class="toc-backref" href="#id32" 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>
|
||||
@@ -596,7 +583,7 @@ 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>
|
||||
<h2><a class="toc-backref" href="#id33" 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
|
||||
@@ -648,23 +635,23 @@ exclude one or the other or both with:</p>
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="id2">
|
||||
<h2><a class="toc-backref" href="#id35" name="id2">0.5 (8/8/2001)</a></h2>
|
||||
<h2><a class="toc-backref" href="#id34" 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>
|
||||
<h2><a class="toc-backref" href="#id35" 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>
|
||||
<h2><a class="toc-backref" href="#id36" 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>
|
||||
<h2><a class="toc-backref" href="#id37" 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>
|
||||
@@ -672,7 +659,7 @@ exclude one or the other or both with:</p>
|
||||
<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>
|
||||
<h2><a class="toc-backref" href="#id38" 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
|
||||
@@ -685,7 +672,7 @@ response.</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>
|
||||
<h2><a class="toc-backref" href="#id39" 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
|
||||
|
Reference in New Issue
Block a user