Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merged the wxPy_newswig branch into the HEAD branch (main trunk)

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@24541 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
2003-11-12 21:34:20 +00:00
parent eb6a4098a0
commit d14a1e2856
987 changed files with 671143 additions and 783083 deletions
Download Patch File Download Diff File Expand all files Collapse all files

261
wxPython/docs/BUILD.devel.txt Normal file
View File

@@ -0,0 +1,261 @@
Building wxPython 2.5 for Development and Testing
=================================================
This file describes how I build wxWindows and wxPython while doing
development and testing, and is meant to help other people that want
to do the same thing. I'll assume that you are using either a CVS
snapshot or a checkout from CVS. (Currently you need to use the
wxPy_newswig branch of the wwxPython subtree of CVS.) I'll also
assume that you know what you are doing and so I may not be as
detailed here as I am in other BUILD docs.
If you want to make changes to any of the *.i files, or 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 when it is released. 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.
Building on Linux and OS X
--------------------------
These two platforms are built almost the same way while in development
so I'll combine the descriptions about their build process here.
First we will build wxWindows and install it to an out of the way
place, then do the same for wxPython.
1. Create a build directory in the main wxWindows dir, and configure
wxWindows. If you want to have multiple builds with different
configure options, just use different subdirectories. I normally
put the configure command in a script named ".configure" in each
build dir so I can easily blow away everything in the build dir and
rerun the script without having to remember the options I used
before::
mkdir bld
cd bld
../configure --prefix=/opt/wx/2.5 \
--with-gtk \
--with-opengl \
--disable-monolithic \
--enable-debug \
--enable-geometry
On OS X of course you'll want to use --with-mac instead of
--with-gtk. For GTK2 and unicode add:
--enable-gtk2 \
--enable-unicode
Notice that I used a prefix of /opt/wx/2.5. You can use whatever
path you want, even the standard ones if you like, but this lets me
easily have multiple versions and ports of wxWindows "installed"
and makes it easy to switch between them.
2. To build and install wxWindows you could just use "make" but there
are other libraries that also need to be built so again I make a
script to do it all for me so I don't forget anything. This time
it is called ".make" (I use the leading ". so when I do "rm -r *"
in my build dir I don't lose my scripts too.) This is what it
looks like::
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 $*
So you just use .make as if it where make, but don't forget to set
the execute bit on .make first!::
.make
.make install
When it's done you should have an installed set of files under
/opt/wx/2.5 containing just wxWindows. Now to use this version of
wxWindows you just need to add /opt/wx/2.5/bin to the PATH and set
LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.5/lib.
3. I also have a script to help me build wxPython and it is checked in
to the CVS as wxWindows/wxPython/b, but probably don't want to use
it as it's very cryptic and expects that you want to run SWIG, so
if you don't have the latest patched up version of SWIG then you'll
probably get stuck. So I'll just give the raw commands instead.
We're not going to install the development version of wxPython with
these commands, so it won't impact your already installed version
of the latest release. You'll be able test with this version when
you want to, and use the installed release version the rest of the
time. If you ever do want to install the development verison just
use the normal distutils commands to do it.
Make sure that the first wx-config found on the PATH is the one you
installed above, and then change to the wxWindows/wxPython dir and
run the this command::
cd wxPython
python2.3 setup.py build_ext --inplace --debug
If you are building with GTK2 then add the following flags to the
command line::
WXPORT=gtk2 UNICODE=1
If you are wanting to have the source files regenerated with swig,
then you need to turn on the USE_SWIG flag and optionally tell it
where to find the new swig executable, so add these flags::
USE_SWIG=1 SWIG=/opt/swig/bin/swig
When the setup.py command is done you should have fully populated
wxPython and wx packages locally in wxWindows/wxPython/wxPython and
.../wx, with all the extension modules (*.so files) located in the
wx package.
4. To run code with the development verison of wxPython, just set the
PYTHONPATH to the wxPython dir in the CVS tree. For example::
export LD_LIBRARY=/opt/wx/2.5/lib
export PYTHONPATH=/myprojects/wxWindows/wxPython
cd /myprojects/wxWindows/wxPython/demo
python2.3 demo.py
Building on Windows
-------------------
The Windows builds currently require the use of Microsoft Visual C++.
Theoretically, other compilers (such as mingw32 or the Borland
compilers) can also be used but I've never done the work to make that
happen. If you want to try that then first you'll want to find out if
there are any tricks that have to be done to make Python extension
modules using that compiler, and then make a few changes to setup.py
to accomodate that. (And send the patches to me.) If you plan on
using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also
have to build Python and any other extension modules that you use with
that compiler because a different version of the C runtime likbrary is
used. The Python executable that comes from PythonLabs and the
wxPythons that I distribute are built with MSVC 6 with all the Service
Packs applied.
If you want to build a debugable version of wxWindows and wxPython you
will need to have also built a debug version of Python and any other
extension modules you need to use. You can tell if you have them
already if there is a _d in the file names, for example python_d.exe
or python23_d.dll. If you don't need to trace through the C/C++ parts
of the code with the debugger then building the normal (or hybrid)
version is fine, and you can use the regular python executables with
it.
Just like the unix versions I also use some scripts to help me build
wxWindows, but I use some non-standard stuff to do it. So if you want
to use them too you'll need to get a copy or 4DOS or 4NT from
http://www.jpsoft.com/ and also a copy of unix-like cat and sed
programs. You can also do by hand what my scripts are doing, but
there are a lof steps involved and I won't be going into details
here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw
1. Set an environment variable to the root of the wxWindows source
tree::
set WXWIN=e:\projects\wxWindows
2. Copy setup0.h to setup.h
cd %WXWIN%\include\wx\msw
copy setup0.h setup.h
3. Edit setup.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::
wxDIALOG_UNIT_COMPATIBILITY 0
wxUSE_DEBUG_CONTEXT 1
wxUSE_MEMORY_TRACING 1
wxUSE_DIALUP_MANAGER 0
wxUSE_GLCANVAS 1
wxUSE_POSTSCRIPT 1
wxUSE_AFM_FOR_POSTSCRIPT 0
4. Make a %WXWIN%\BIN directory and add it to the PATH. My build
scripts will copy the wxWindows DLLs there.
5. Change to the %WXWIN%\build\msw directory and copy my build scripts
there.
6. Use the .make command to build wxWindows. It needs one
command-line parameter which controls what kind of build(s) to do.
Use one of the following::
debug Build debug version
hybrid Build hybrid version
both Both debug and hybrid
debug-uni Build a debug unicode library
hybrid-uni Hybrid unicode (see the pattern yet? ;-)
both-uni and finally both unicode libraries
For example::
.make hybrid
7. When that is done there should be a ton of DLLs in %WXDIR%\bin and
lots of lib files and stuff in %WXDIR%\lib\vc_dll
8. Building wxPython on Windows is very similar to doing it for the
unix systems. We're not going to install the development version
of wxPython with these commands, so it won't impact your already
installed version of the latest release. You'll be able 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 just use the normal distutils commands to do
it.
Change to the wxWindows\wxPython dir and run the this command::
cd %WXWIN%\wxPython
python setup.py build_ext --inplace
If you are wanting to have the source files regenerated with swig,
then you need to turn on the USE_SWIG flag and optionally tell it
where to find the new swig executable, so add these flags::
USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe
If you have a debug version of Python and wxWindows and want to
build a debug version of wxPython too, add the --debug flag to the
command line. You should then end up with a set of *_d.pyd files
in the wx package and you'll have to use python_d.exe to use them.
The debug and hybrid(release) versions can coexist.
When the setuyp.py command is done you should have fully populated
wxPython and wx packages locally in wxWindows/wxPython/wxPython and
.../wx, with all the extension modules (*.pyd files) located in the
wx package.
9. To run code with the development verison of wxPython, just set the
PYTHONPATH to the wxPython dir in the CVS tree. For example::
set PYTHONPATH=e:\projects\wxWindows\wxPython
cd e:\projects\wxWindows\wxPython
python demo.py

80
wxPython/docs/BUILD.osx.txt Normal file
View File

@@ -0,0 +1,80 @@
Building wxPython on Mac OS X
-----------------------------
These are the steps I have used for building wxPython on Mac OS X 10.x
with the Apple Developer Tools, a.k.a the Darwin version. I assume
that you know your way around a command line and that you know how to
get things from various CVS repositories as needed.
1. "MacPython-OSX" 2.3 is required. If you don't have it already there is a disk image with an
installer package at
http://homepages.cwi.nl/~jack/macpython/download.html
If, for some reason you need to build your own Python, get the
source from www.python.org and follow the instructions in the
Mac/OSX/README file to build and install the Python.framework and
Python tools.
One last thing, make sure that /usr/local/bin is in your PATH
environment variable since that is where the new python and pythonw
commands will be located.
2. In a wxWindows CVS tree make a build directory. (You can also use
a CVS snapshot located in http://wxwindows.org/snapshots/ or the
released wxPythonSrc-*.tr.gz archive.)
cd ~/proj/wxWindows # or wherever you put it
mkdir build
3. Run configure from that build directory.
cd build
../configure --with-mac \
--with-opengl \
--enable-geometry \
--enable-optimise \
--with-libjpeg=builtin \
--with-libpng=builtin \
--with-libtiff=builtin \
If you want to add code that activates various runtime checks and
assertion exceptions then add --enable-debug_flag.
4. Make and install wxMac.
make
sudo make install
5. Build and install wxPython.
cd ../wxPython
python setup.py build install
If you would like to install to someplace besides the Python
site-packages directory (such as to your home directory) then you
can add "--root=<path>" after the "install" command. To use
wxPython like this you'll need to ensure that the directory
containing wxPyrthon is contained in in the PYTHONPATH environment
variable.
6. Test. Just navigate in the Finder to the demo directory and double
click demo.py, or simple.py, or whatever you want to run. Or from
a command line you can run it this way:
cd demo
pythonw demo.py
7. Figure out what's wrong, figure out how to fix it, and then send
the patches to me. <wink>
--Robin

340
wxPython/docs/BUILD.unix.txt Normal file
View File

@@ -0,0 +1,340 @@
Building wxPython on Unix or Unix-like Systems
----------------------------------------------
NOTE: You should probably look at the ../ README.1st.txt file for
directions for how to build wxPython the "new way." This files
describes the "old way" to build on unix-like systems. The difference
is very simple: The new way uses a private copy of wxGTK while the
old way uses either an existing wxGTK that may be installed and used
by other apps, or you can build a wxGTK that will be accessable by
other apps.
NOTE 2: I use a tool called SWIG (http://www.swig.org) to help
generate the C++ sources used in the wxPython extension module.
However you don't need to have SWIG unless you want to modify the *.i
files. I've made several modifications to and older version of SWIG
that are specific to wxPython's needs and so the modified sources are
included in the wx CVS at .../wxPython/wxSWIG. But because of the
size and since most people won't need it my SWIG is not included in
the wxPythonSrc tarball. You'll need to get it from CVS or a CVS
snapshot.
If you need to modify the *.i files for wxPython then you will need to
build wxswig. Change to the .../wxPython/wxSWIG directory and run:
configure
make
(Do not run "make install" as wxswig is run in-place.) You'll then
need to change a flag in the setup.py script as described below so the
wxPython build process will use SWIG if needed.
I use the new Python Distutils tool to build wxPython. It is included
with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then
you'll need to download and install Distutils 1.0 from
http://www.python.org/sigs/distutils-sig/
Okay, now on the the fun stuff...
1. Compile and/or install glib and gtk+
---------------------------------------
A. First of all, check and see if you've already got glib/gtk+ on your
system, all the Linux distributions I know of come with it, at
least as an option. Look for libglib.* and libgtk.* in your system's
standard library directories. You'll also need the headers and
config scripts in order to build things that use glib/gtk. Try
running gtk-config:
gtk-config --version
If you have version 1.2.7 or better then you're all set. Otherwise
either get the pacakges for your unix distribution and install them
or get the sources from www.gtk.org and build and install them.
The best version to get is the latest 1.2.x release as the
wxWindows support for GTK 2.x is still beta-level. (Most tings
work great though, and it looks real nice.)
2. Compile and/or install wxGTK
-------------------------------
A. You can find the sources and RPMs for wxGTK at
http://wxwindows.org/, just follow the download links from the
navigation panel.
Source code for wxGTK is now included with the wxPythonSrc tarball,
and is the recommended way to get released wxGTK source code if you
plan on building both.
You can also check out a current snapshot of the sources from the
CVS server. (Some information about annonymous CVS access is at
http://wxwindows.org/cvs.htm.) The advantage of using CVS is that
you can easily update as soon as the developers check in new
sources or fixes. The advantage of using a released version is
that it usually has had more thorough testing done. You can decide
which method is best for you.
B. You'll usually want to use a version of wxGTK that has the same
version number as the wxPython sources you are using. (Another
advantage of using wxPythonSrc or CVS is that you'll get both at
the same time.)
C. If using the RPMs be sure to get both the wxGTK and wxGTK-devel
RPMs (at a minimum) and then install them as root.
rpm -Uhv wxGTK-2.2.2-0.i386.rpm wxGTK-devel-2.2.2-0.i386.rpm
D. If using the sources (either from the tarball or from CVS) then
configure it like this:
cd wxWindows # or whatever your top-level directory is called
mkdir build
cd build
../configure --with-gtk --enable-geometry
There are gobs and gobs of options for the configure script, run
../configure --help to see them all. I'll describe some that I find
useful here.
If you have OpenGL or compatible libraries installed, then add the
--with-opengl flag.
If you are on Solaris and are using a recent version of GCC, then
you'll probably want to add the --enable-permissive flag so the
compiler won't barf on your broken X11 header files.
To make a debugging version of wxGTK, add the --enable-debug flag.
This sets the -g flag for the compiler and also activates some
special debugging code in wxWindows by defining the __WXDEBUG__
macro. You'll get some extra asserts, failure logging, etc.
If you are using GTK 2.x then you'll want to add --enable-gtk2 and
probably also --enable-unicode.
E. Now just compile and install. You need to use GNU make, so if your
system has something else get GNU make and build and install it and
use it instead of your system's default make command.
make
make install
The last step will probably have to be done as root. Also, if your
system needs anything done to update the dynamic loader for shared
libraries, (such as running ldconfig on Linux) then do it now.
F. You can test your build by changing to one of the directories under
build/samples or build/demos, running make and then running the
executable that is built.
3. Compile and install wxPython
-------------------------------
A. You have the same options (and same advantages/disadvantages) for
getting the wxPython source, either a released snapshot or from
CVS. The released version file is named wxPythonSrc-[version].tar.gz
and is available at http://wxpython.org/download.php. If you want
to use CVS you'll find wxPython in the wxWindows CVS tree (see
above) in the wxWindows/wxPython directory.
B. wxPython is built with the standard Python Distutils tool and
currently includes it's own snapshot of the latest version of
distutils which can also be used with previous versions of Python
On Unix systems Distutils figures out what commands and flags to
use for the compiler and linker by looking in the Makefile that was
used to build Python itself. Most of the time this works okay. If
it doesn't, there doesn't seem to be a way to override the values
that Distutils uses without hacking either Distutils itself, or
Python's Makefile. (NOTE: This has been changed with the
distutilsincluded with Python 2.3 but I havn't yet looked into how
best to utilize this in wxPython...)
While we're on the subject of how Python was built... Since
wxPython is a C++ extension some platforms and/or compilers will
require that the Python executable was linked with the C++ linker
in order for everything to work correctly. If you build and
install Python yourself then this is easy to take care of,
otherwise you may have to mess with binary packages or bribe your
system administrator...
In my case on Solaris wxPython applications would core dump on
exit. The core file indicated that the fault happened after
_exit() was called and the run-time library was trying to execute
cleanup code. After relinking the Python executable the problem
went away. To build Python to link with the C++ linker do this:
cd Python-2.0 # wherever the root of the source tree is
rm python # in case it's still there from an old build
make LINKCC=g++ # or whatever your C++ command is
make install
I recently built Python 2.1.3 and Python 2.2.1 on Solaris and did
not have to resort to this workaround so apparently things are
getting better there. I will leave this note here though in case
there are similar issues elsewhere. However I did run into a
Python build issue that affects the wxPython build when attempting
to use SunCC instead of GNU gcc. See the note below titled
"Building with non-GNU compilers" if you are interested.
C. Change to the root wxPython directory and look at the setup.py
file. This is the script that configures and defines all the
information that Distutils needs to build wxPython. There are some
options near the begining of the script that you may want or need
to change based on your system and what options you have selected
up to this point, (sources from tar.gz or from CVS, etc.) You can
either change these flags directly in setup.py or supply them on
the command-line.
BUILD_GLCANVAS Set to zero if you don't want to build the
Open GL canvas extension module. If you don't
have OpenGL or compatible libraries then you'll
need to set this to zero.
BUILD_OGL Set to zero if you don't want to build the
Object Graphics Library extension module.
BUILD_STC Set to zero if you don't want to build the
wxStyledTextCtrl (the Scintilla wrapper)
extension module.
USE_SWIG If you have edited any of the *.i files you
will need to set this flag to non-zero so SWIG
will be executed to regenerate the wrapper C++
and shadow python files.
etc.
D. To build and install wxPython you simply need to execute the
setup.py script. If you have more than one version of Python
installed, be sure to execute setup.py with the version you want to
build wxPython for. Depending on the permissions on your
site-packages directory you may need to be root to run the install
command.
python setup.py build install
If you need to change any of the build flags that can also be done
on the setup.py command line, like this:
python setup.py BUILD_GLCANVAS=0 build install
If you are using GTK 2.x then you'll want to add these flags:
python setup.py WXPORT=gtk2 UNICODE=1 build install
If you would like to install to someplace besides the Python
site-packages directory (such as to your home directory) then you
can add "--root=<path>" after the "install" command. To use
wxPython like this you'll need to ensure that the directory
containing wxPyrthon is contained in in the PYTHONPATH environment
variable.
E. At this point you should be able to change into the wxPython/demo
directory and run the demo:
python demo.py
F. If you would like to make a test build that doesn't overwrite any
installed version of wxPython you can do so with this command
instead of the install command above:
python setup.py build_ext --inplace
This will build the wxPython package in the local wxPython
directory instead of installing it under your Python installation.
To run using this test version just add the base wxPython source
directory to the PYTHONPATH:
export PYTHONPATH=~/projects/wxWindows/wxPython
# or whatever is required for your shell
cd ~/projects/wxWindows/wxPython/demo
python demo.py
4. Building with non-GNU compilers
----------------------------------
As mentioned above Python's distutils uses whatever compiler Python
was compiled with to compile extension modules. It also appears that
distutils assumes that this compiler can compile C or C++ sources as
distutils makes no differentiation between the two. For builds using
GNU gcc and a few other compilers this is not an issue as they will
determine the type of source from the file extension. For SunCC (and
probably other compilers that came from cfront) it won't work as the C
compiler (cc) is totally separate from the C++ compiler (CC). This
causes distutils to attempt to compile the wxPython sources with the C
compiler, which won't work.
There may be better ways to get around this, but here is the
workaround I devised. I created a script that will execute either cc
or CC based on the file extension given to it. If Python uses this
script for its compiler then it will also be used by extensions built
with distutils and everybody will be more or less happy. Here is a
copy of the script I used. It was a fairly quick rush job so there
are probably issues with it but it worked for me.
#!/bin/bash
#--------------------------------------------------------------
# Try to determine type of file being compiled and then
# launch cc for C sources or CC for C++.
#
args=$@
is_C=
for arg in $args; do
# is the arg a file that exists?
if [ -e $arg ]; then
# does it end in ".c"?
if [ "${arg:${#arg}-2}" == ".c" ]; then
is_C=yes
fi
fi
done
# if the flag wasn't set then assume C++ and execute CC,
# otherwise execute cc.
if [ -z $is_C ]; then
exec CC -w $@
else
exec cc -w $@
fi
#--------------------------------------------------------------
I called it pycc, put it in ${prefix}/bin and set its execute
permission bit.
The next step is to configure and build Python such that it uses pycc
as it's compiler. You can do that by setting CC in your environment
before running configure, like this in bash:
export CC=pycc
configure
After making and installing Python with this configuration you should
be able to build wxPython as described in the steps above.
-----------------
robin@alldunn.com

303
wxPython/docs/BUILD.win32.txt Normal file
View File

@@ -0,0 +1,303 @@
Building wxPython on Win32
--------------------------
Building wxPython for use on win32 systems is a fairly simple process
consisting of just a few steps. However depending on where you get
your sources from and what your desired end result is, there are
several permutations of those steps. At a high level the basic steps
are:
1. Get the sources
2. Build the wxWindows DLL
3. Build and Install wxPython
We'll go into more detail of each of these steps below, but first a
few bits of background information on tools.
I use a tool called SWIG (http://www.swig.org) to help generate the
C++ sources used in the wxPython extension module. However you don't
need to have SWIG unless you want to modify the *.i files. I've made
several modifications to SWIG specific to wxPython's needs and so the
modified sources are included in the wx CVS at .../wxPython/wxSWIG.
But because of the size and since most people won't need it my SWIG is
not included in the wxPythonSrc tarball. You'll need to get it from
CVS or a CVS snapshot.
If you need to modify the *.i files for wxPython then change to the
.../wxPython/wxSWIG directory and run:
nmake -f makefile.vc
Then you'll need to change a flag in the setup.py script as described
below so the wxPython build process will use SWIG if needed.
I use the new Python Distutils tool to build wxPython. It is included
with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then
you'll need to download and install Distutils 1.0 from
http://www.python.org/sigs/distutils-sig/
I use Microsoft Visual C++ 6.0 (5.0 with the service packs should work
also) to compile the wxPython C++ sources. Since I am using Distutils
it should be easier now to build with other win32 compilers such as
the free mingw32 or Borland compilers, but I havn't tried them yet.
If anybody wants to try it I'll take any required patches for the
setup script and for these instructions.
UNICODE
-------
To build the version of wxWindows/wxPython that uses the unicode
version of the Win32 APIs, just follow the steps below with these
changes:
a. You'll need the MSLU runtime DLL and import lib. The former can
be downloaded from Microsoft, the latter is part of the latest
Platform SDK from Microsoft (see msdn.microsoft.com for
details). An alternative implementation of import lib can be
downloaded from http://libunicows.sourceforge.net
b. Add "UNICODE=1 MSLU=1" to the nmake command line when building
wxWindows.
c. Add "UNICODE=1" to the setup.py commandline when building
wxPython.
d. See the notes in CHANGES.txt about unicode.
And now on to the fun stuff...
1. Get the sources
------------------
A. You can either use a tarball with the released version of the
source code for wxWindows/wxPython, or you can get current
development sources from the CVS repository. (Some information
about annonymous CVS access is at the http://wxwindows.org/cvs.htm
site.) The advantage of using CVS is that you can easily update as
soon as the developers check in new sources or fixes. The
advantage of using a released version is that it usually has had
more thorough testing done. You can decide which method is best
for you. The released version file is named
wxPythonSrc-[version].tar.gz and is available from the wxPython
website at http://wxpython.org/download.php. You can use WinZip to
unpack it if you don't have tar and gzip.
B. Once you get the sources be sure to put them in a path without a
space in it (i.e., NOT c:\Program Files\wx) and set an environment
variable named WXWIN to the top level directory. For example:
set WXWIN=c:\wx\wxPythonSrc-2.4.0.4
You'll probably want to add that line to your autoexec.bat or
System Properties depending on the type of system you are on.
C. Change to the %WXWIN%\include\wx\msw directory and copy setup0.h to
setup.h and then edit setup.h. This is how you control which parts
of wxWindows are compiled into or left out of the build, simply by
turning options on or off. I have the following differences from
the default setup0.h in my setup.h, but you can experiment with
other settings if you like:
WXWIN_COMPATIBILITY_2_2 0
wxDIALOG_UNIT_COMPATIBILITY 0
wxUSE_DEBUG_CONTEXT 1
wxUSE_MEMORY_TRACING 1
wxUSE_CMDLINE_PARSER 0
wxUSE_FSVOLUME 0
wxUSE_DIALUP_MANAGER 0
wxUSE_DYNAMIC_LOADER 0
wxUSE_TREELAYOUT 0
wxUSE_MS_HTML_HELP 0
wxUSE_POSTSCRIPT 1
** NEW **
Be sure that wxUSE_GLCANVAS is defined to be 0 as wxPython now
keeps its own copy of the glcanvas sources and expects that it is
not in the main library. This is done to reduce the number of
dependant DLLs on the core library and therefore help reduce
startup time.
2. Build the wxWindows DLL
---------------------------
A. Although MSVC project files are provided I always use the makefiles
to build wxWindows because by default the flags are compatible with
Python, (and I make sure they stay that way.) You would have to
edit the project files a bit to make it work otherwise.
B. There are three different types of wxWindows DLLs that can be
produced by the VC makefile simply by providing a flag on the nmake
command-line, I call the three types DEBUG, FINAL, and HYBRID.
Here are some more details:
DEBUG Specified with "FINAL=0" and produces a DLL named
wxmsw[version]d.dll. This DLL is compiled with full
debugging information and with the __WXDEBUG__ macro set,
which enables some debugging-only code in wxWindows such
as assertions and failure log messages. The /MDd flag is
used which means that it is linked with the debugging
version of the C runtime library and also that you must
use the debugging version of Python, (python_d.exe and
pythonXX_d.dll) which also means that all extensions
loaded by Python should also have the _d in the name.
With this option you can use the MSVC debugger to trace
though the Python interpreter, as well as the code for the
wxPython extension and the wxWindows DLL.
FINAL Specified with "FINAL=1" and produces a DLL named
wxmsw[version].dll. This DLL is compiled with optimizations
turned on and without debugging information and without
__WXDEBUG__. The /MD flag is used which means that you
can use this version with the standard python.exe.
HYBRID Specified with "FINAL=hybrid" and produces a DLL named
wxmsw[version]h.dll. This DLL is almost the same as the
FINAL version except the __WXDEBUG__ is used which means
that you will get extra runtime assertions and validations
from wxWindows. If any of these fail then they are turned
into a Python exception that you can catch and deal with
in your code. This is the version that I use when making
the binary installer for win32.
Since different DLL names and object file directories are used you
can build all three types if you like.
C. Change to the %WXWIN%\src\msw directory and type the following command,
using the value for FINAL that you want:
nmake -f makefile.vc dll FINAL=hybrid
Your machine will then crunch away for possibly a long time,
depending on your hardware, and when it's done you should have a
DLL and some library files in %WXWIN%\lib.
D. You'll either need to add %WXWIN%\lib to the PATH or copy the DLL
file to a directory already on the PATH so the DLL can be found at
runtime. Another option is to copy the DLL to the directory that
the wxPython pacakge is installed to, for example,
c:\Python22\lib\site-packages\wxPython.
E. You can test your build by changing to one of the directories under
%WXWIN%\samples or %WXWIN\demos and typing (using the right FINAL flag):
nmake -f makefile.vc FINAL=hybrid WXUSINGDLL=1
and then executing the resulting .exe file.
3. Build and Install wxPython
-----------------------------
A. As mentioned previouslly, wxPython is built with the standard
Python Distutils tool. If you are using Python 2.0 or later you
are all set, otherwise you need to download and install Distutils
1.0 from http://www.python.org/sigs/distutils-sig/.
B. Change to the root wxPython directory and look at the setup.py
file. This is the script that configures and defines all the
information that Distutils needs to build wxPython. There are some
options near the begining of the script that you may want or need
to change based on what options you have selected up to this point,
(type of DLL built, sources from tar.gz or from CVS, etc.) You can
either change these flags directly in setup.py or supply them on
the command-line.
BUILD_GLCANVAS Set to zero if you don't want to build the
Open GL canvas extension module.
BUILD_OGL Set to zero if you don't want to build the
Object Graphics Library extension module.
BUILD_STC Set to zero if you don't want to build the
wxStyledTextCtrl (the Scintilla wrapper)
extension module.
USE_SWIG If you have edited any of the *.i files you
will need to set this flag to non-zero so SWIG
will be executed to regenerate the wrapper C++
and shadow python files.
etc.
C. To build and install wxPython you simply need to execute the
setup.py script. If you have more than one version of Python
installed, be sure to execute setup.py with the version you want to
build wxPython for.
Depending on what kind of wxWindows DLL you built there are
different command-line parameters you'll want to pass to setup (in
addition to possibly one or more of the above):
FINAL: python setup.py install
DEBUG: python setup.py build --debug install
HYBRID: python setup.py HYBRID=1 install
NOTE: If you get an internal compiler error from MSVC then you
need to edit setup.py and add in the /GX- flag that is normally
commented out. Just search for "GX-" and uncomment it so it is put
into the cflags list.
If you would like to install to someplace besides the Python
site-packages directory (such as to your home directory) then you
can add "--root=<path>" after the "install" command. To use
wxPython like this you'll need to ensure that the directory
containing wxPyrthon is contained in in the PYTHONPATH environment
variable.
D. At this point you should be able to change into the wxPython\demo
directory and run the demo:
python demo.py
E. If you would like to make a test build that doesn't overwrite the
installed version of wxPython you can do so with one of these
commands instead of the install command above:
FINAL: python setup.py build_ext --inplace
DEBUG: python setup.py build_ext --debug --inplace
HYBRID: python setup.py HYBRID=1 build_ext --inplace
This will build the wxPython package in the local wxPython
directory instead of installing it under your Python installation.
To run using this test version just add the base wxPython source
directory to the PYTHONPATH:
set PYTHONPATH=%WXDIR%\wxPython
cd %WXDIR%\wxPython\demo
python demo.py
That's all folks!
-----------------
robin@alldunn.com

1579
wxPython/docs/CHANGES.txt Normal file
View File

File diff suppressed because it is too large Load Diff

284
wxPython/docs/MigrationGuide.html Normal file
View File

@@ -0,0 +1,284 @@
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
<title>wxPython 2.5 Migration Guide</title>
<link rel="stylesheet" href="default.css" type="text/css" />
</head>
<body>
<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 CHANGES.txt 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="module-initialization">
<h1><a name="module-initialization">Module Initialization</a></h1>
<p>The import-startup-bootstrap process employed by wxPython was changed
such that wxWindows and the underlying gui toolkit are <strong>not</strong>
initialized until the wx.App object is created (but before wx.App.OnInit
is called.) This was required because of some changes that were made
to the C++ wxApp class.</p>
<p>There are both benefits and potential problems with this change. The
benefits are that you can import wxPython without requiring access to
a GUI (for checking version numbers, etc.) and that in a
multi-threaded environment the thread that creates the app object will
now be the GUI thread instead of the one that imports wxPython. Some
potential problems are that the C++ side of the &quot;stock-objects&quot;
(wx.BLUE_PEN, wx.TheColourDatabase, etc.) are not initialized until
the wx.App object is created, so you should not use them until after
you have created your wx.App object. (In fact, until I find a better
solution trying to use one of the stock objects before the app is
created will probably result in a crash.)</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>
</div>
<div class="section" id="swig-1-3">
<h1><a name="swig-1-3">SWIG 1.3</a></h1>
<p>wxPython is now using SWIG 1.3.x from CVS (with several of my own
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 &quot;new-style
classes&quot;</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
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
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>
</blockquote>
</div>
<div class="section" id="binding-events">
<h1><a name="binding-events">Binding Events</a></h1>
<p>All of the EVT_* functions are now instances of the wx.PyEventBinder
class. They have a __call__ method so they can still be used as
functions like before, but making them instances adds some
flexibility.</p>
<p>wx.EvtHandler (the base class for wx.Window) now has a Bind method that
makes binding events to windows a little easier. Here is its
definition and docstring:</p>
<pre class="literal-block">
def Bind(self, event, handler, source=None, id=wxID_ANY, id2=wxID_ANY):
&quot;&quot;&quot;
Bind an event to an event handler.
event One of the EVT_* objects that specifies the
type of event to bind.
handler A callable object to be invoked when the event
is delivered to self. Pass None to disconnect an
event handler.
source Sometimes the event originates from a different window
than self, but you still want to catch it in self. (For
example, a button event delivered to a frame.) By
passing the source of the event, the event handling
system is able to differentiate between the same event
type from different controls.
id,id2 Used for menu IDs or for event types that require a
range of IDs
&quot;&quot;&quot;
</pre>
<p>Some examples of its use:</p>
<pre class="literal-block">
self.Bind(wx.EVT_SIZE, self.OnSize)
self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton)
self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT)
</pre>
<p>I hope to be able to remove the need for using IDs even for menu
events too...</p>
<p>If you create your own custom event types and EVT_* functions, and you
want to be able to use them with the Bind method above then you should
change your EVT_* to be an instance of wxPyEventBinder instead of a
function. If you used to have something like this:</p>
<pre class="literal-block">
myCustomEventType = wxNewEventType()
def EVT_MY_CUSTOM_EVENT(win, id, func):
win.Connect(id, -1, myCustomEventType, func)
</pre>
<p>Change it like so:</p>
<pre class="literal-block">
myCustomEventType = wxNewEventType()
EVT_MY_CUSTOM_EVENT = wxPyEventBinder(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>
</div>
<div class="section" id="the-wx-namespace">
<h1><a name="the-wx-namespace">The wx Namespace</a></h1>
<p>The second phase of the wx Namespace Transition has begun. That means
that the real names of the classes and other symbols do not have the
'wx' prefix and the modules are located in a Python package named
wx. There is still a Python package named wxPython with modules
that have the names with the wx prefix for backwards compatibility.
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
</pre>
<p>Don't let the &quot;core&quot; in the name bother you. That and some other
modules are implementation details, and everything that was in the
wxPython.wx before will still be in the wx package namespace after
this change. So from your code you would use it as wx.Window.</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
of the parse tree, which can be up to 20MB and 300K lines in size!
That XML is then run through a little Python script that creates a
file full of SWIG %rename directives that take the wx off of the
names, and also generates the Python compatibility file described
above that puts the wx back on the names. SWIG is then run a second
time to generate the C++ code to implement the extension module, and
uses the %rename directives that were generated in the first step.</p>
<p>Not every name is handled correctly (but the bulk of them are) and so
some work has to be done by hand, especially for the reverse-renamers.
So expect a few flaws here and there until everything gets sorted out.</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 &quot;normal&quot; 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>
<pre class="literal-block">
SetSize(size) # Type A
SetSizeWH(width, height) # Type B
</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 renamed. Now that lots of other
things are also changing in wxPython that 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)
</pre>
<p>If you have code that draws on a DC 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 as 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. For example, if you had this code
before:</p>
<pre class="literal-block">
dc.DrawRectangle(x, y, width, height)
</pre>
<p>You could just change it 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:</p>
<pre class="literal-block">
dc.DrawRectangle(p.x, p.y, s.width, s.height)
</pre>
<p>Then you can just change it like this:</p>
<pre class="literal-block">
dc.DrawRectangle(p, s)
</pre>
</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>
<p>wxPython's setup.py script now expects to use existing libraries for
the contribs (gizmos, stc, xrc, etc.) rather than building local
copies of them. If you build your own copies of wxPython please be
aware that you now need to also build the ogl, stc, xrc, and gizmos
libraries in addition to the main wx lib. [[TODO: update the
BUILD.*.txt files too!]]</p>
<p>The wxPython.h and other header files are now in
.../wxPython/include/wx/wxPython instead of in wxPython/src. You should
include it via the &quot;wx/wxPython/wxPython.h&quot; path and add
.../wxPython/include to your list of include paths. [[TODO: Install
these headers on Linux...]]</p>
<p>You no longer need to call wxClassInfo::CleanUpClasses() and
wxClassInfo::InitializeClasses() in your extensions or when embedding
wxPython.</p>
</div>
<div class="section" id="other-stuff">
<h1><a name="other-stuff">Other Stuff</a></h1>
<p>Instead of over a dozen separate extension modules linked together
into a single extension module, the &quot;core&quot; module is now just a few
extensions that are linked independently, and then merged together
later into the main namespace via Python code.</p>
<p>Because of the above, the &quot;internal&quot; module names have changed, but
you shouldn't have been using them anyway so it shouldn't bother
you. ;-)</p>
</div>
</div>
</body>
</html>

393
wxPython/docs/MigrationGuide.txt Normal file
View File

@@ -0,0 +1,393 @@
============================
wxPython 2.5 Migration Guide
============================
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 CHANGES.txt file like
usual to see info about the not so major changes and other things that
have been added to wxPython.
Module Initialization
---------------------
The import-startup-bootstrap process employed by wxPython was changed
such that wxWindows and the underlying gui toolkit are **not**
initialized until the wx.App object is created (but before wx.App.OnInit
is called.) This was required because of some changes that were made
to the C++ wxApp class.
There are both benefits and potential problems with this change. The
benefits are that you can import wxPython without requiring access to
a GUI (for checking version numbers, etc.) and that in a
multi-threaded environment the thread that creates the app object will
now be the GUI thread instead of the one that imports wxPython. Some
potential problems are that the C++ side of the "stock-objects"
(wx.BLUE_PEN, wx.TheColourDatabase, etc.) are not initialized until
the wx.App object is created, so you should not use them until after
you have created your wx.App object. (In fact, until I find a better
solution trying to use one of the stock objects before the app is
created will probably result in a crash.)
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.)
SWIG 1.3
--------
wxPython is now using SWIG 1.3.x from CVS (with several of my own
customizations added that I hope to get folded back into the main SWIG
distribution.) This has some far reaching ramifications:
All classes derive from object and so all are now "new-style
classes"
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.
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
ClassName_MethodName as before.
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
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).
Binding Events
--------------
All of the EVT_* functions are now instances of the wx.PyEventBinder
class. They have a __call__ method so they can still be used as
functions like before, but making them instances adds some
flexibility.
wx.EvtHandler (the base class for wx.Window) now has a Bind method that
makes binding events to windows a little easier. Here is its
definition and docstring::
def Bind(self, event, handler, source=None, id=wxID_ANY, id2=wxID_ANY):
"""
Bind an event to an event handler.
event One of the EVT_* objects that specifies the
type of event to bind.
handler A callable object to be invoked when the event
is delivered to self. Pass None to disconnect an
event handler.
source Sometimes the event originates from a different window
than self, but you still want to catch it in self. (For
example, a button event delivered to a frame.) By
passing the source of the event, the event handling
system is able to differentiate between the same event
type from different controls.
id,id2 Used for menu IDs or for event types that require a
range of IDs
"""
Some examples of its use::
self.Bind(wx.EVT_SIZE, self.OnSize)
self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton)
self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT)
I hope to be able to remove the need for using IDs even for menu
events too...
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
function. If you used to have something like this::
myCustomEventType = wxNewEventType()
def EVT_MY_CUSTOM_EVENT(win, id, func):
win.Connect(id, -1, myCustomEventType, func)
Change it like so::
myCustomEventType = wxNewEventType()
EVT_MY_CUSTOM_EVENT = wxPyEventBinder(myCustomEventType, 1)
The second parameter is an integer in [0, 1, 2] that specifies the
number of IDs that are needed to be passed to Connect.
The wx Namespace
----------------
The second phase of the wx Namespace Transition has begun. That means
that the real names of the classes and other symbols do not have the
'wx' prefix and the modules are located in a Python package named
wx. There is still a Python package named wxPython with modules
that have the names with the wx prefix for backwards compatibility.
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::
wxWindow = wx.core.Window
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.
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
of the parse tree, which can be up to 20MB and 300K lines in size!
That XML is then run through a little Python script that creates a
file full of SWIG %rename directives that take the wx off of the
names, and also generates the Python compatibility file described
above that puts the wx back on the names. SWIG is then run a second
time to generate the C++ code to implement the extension module, and
uses the %rename directives that were generated in the first step.
Not every name is handled correctly (but the bulk of them are) and so
some work has to be done by hand, especially for the reverse-renamers.
So expect a few flaws here and there until everything gets sorted out.
In summary, the wx package and names without the "wx" prefix are now
the official form of the wxPython classes. For example::
import wx
class MyFrame(wx.Frame):
def __init__(self, parent, title):
wx.Frame.__init__(self, parent, -1, title)
p = wx.Panel(self, -1)
b = wx.Button(p, -1, "Do It", (10,10))
self.Bind(wx.EVT_BUTTON, self.JustDoIt, b)
def JustDoIt(self, evt):
print "It's done!"
app = wx.PySimpleApp()
f = MyFrame(None, "What's up?")
f.Show()
app.MainLoop()
You shouldn't need to migrate all your modules over to use the new
package and names right away as there are modules in place that try to
provide as much backwards compatibility of the names as possible. If
you rewrote the above sample using "from wxPython.wx import *", the
old wxNames, and the old style of event binding it will still work
just fine.
New wx.DC Methods
-----------------
Many of the Draw methods of wx.DC have alternate forms in C++ that take
wxPoint or wxSize parameters (let's call these *Type A*) instead of
the individual x, y, width, height, etc. parameters (and we'll call
these *Type B*). In the rest of the library I normally made the *Type
A* forms of the methods be the default method with the "normal" name,
and had renamed the *Type B* forms of the methods to some similar
name. For example in wx.Window we have these Python methods::
SetSize(size) # Type A
SetSizeWH(width, height) # Type B
For various reasons the new *Type A* methods in wx.DC were never added
and the existing *Type B* 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::
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)
If you have code that draws on a DC you **will** get errors because of
these changes, but it should be easy to fix the code. You can either
change the name of the *Type B* 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
*Type A* method. For example, if you had this code before::
dc.DrawRectangle(x, y, width, height)
You could either continue to use the *Type B* method bu changing the
name to DrawRectabgleXY, or just change it to the new *Type A* by
adding some parentheses like this::
dc.DrawRectangle((x, y), (width, height))
Or if you were already using a point and size::
dc.DrawRectangle(p.x, p.y, s.width, s.height)
Then you can just simplify it like this::
dc.DrawRectangle(p, s)
Building, Extending and Embedding wxPython
------------------------------------------
wxPython's setup.py script now expects to use existing libraries for
the contribs (gizmos, stc, xrc, etc.) rather than building local
copies of them. If you build your own copies of wxPython please be
aware that you now need to also build the ogl, stc, xrc, and gizmos
libraries in addition to the main wx lib. [[TODO: update the
BUILD.*.txt files too!]]
The wxPython.h and other header files are now in
.../wxPython/include/wx/wxPython instead of in wxPython/src. You should
include it via the "wx/wxPython/wxPython.h" path and add
.../wxPython/include to your list of include paths. [[TODO: Install
these headers on Linux...]]
You no longer need to call wxClassInfo::CleanUpClasses() and
wxClassInfo::InitializeClasses() in your extensions or when embedding
wxPython.
Two (or Three!) Phase Create
----------------------------
If you use the Precreate/Create method of instantiating a window, (for
example, to set an extended style flag, or for XRC handlers) then
there is now a new method named PostCreate to help with transplanting
the brain of the prewindow instance into the derived window instance.
For example::
class MyDialog(wx.Dialog):
def __init__(self, parent, ID, title, pos, size, style):
pre = wx.PreDialog()
pre.SetExtraStyle(wx.DIALOG_EX_CONTEXTHELP)
pre.Create(parent, ID, title, pos, size, style)
self.PostCreate(pre)
Sizers
------
The hack allowing the old "option" keyword parameter has been
removed. If you use keyworkd args with wxSizer Add, Insert, or
Prepend then you will need to use the "proportion" name instead of
"option".
When adding a spacer to a sizer you now need to use a wxSize or a
2-integer sequence instead of separate width and height parameters.
The wxGridBagSizer 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.
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.
Other Stuff
-----------
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.
Because of the above, the "internal" module names have changed, but
you shouldn't have been using them anyway so it shouldn't bother
you. ;-)
The wxPython.help module no longer exists and the classes therein are
now part of the core module imported with wxPython.wx or the wx
package.
wxPyDefaultPosition and wxPyDefaultSize are gone. Use the
wxDefaultPosition and wxDefaultSize objects instead.
Similarly, the wxSystemSettings backwards compatibiility aliases for
GetSystemColour, GetSystemFont and GetSystemMetric have also gone into
the bit-bucket. Use GetColour, GetFont and GetMetric instead.

70
wxPython/docs/README.txt Normal file
View File

@@ -0,0 +1,70 @@
wxPython README
---------------
Welcome to the wonderful world of wxPython!
So where do you go from here? The best thing to do is to run the demo
and use its source code to help you learn how to use wxPython. Most
of the classes available are demonstrated there, and you can view the
sources directly in the demo so it is designed to help you learn. If
you are on Windows or OS X then you can run the demo just by double
clicking it's icon. If you are on Linux/Unix then change to the
directory containing the demo and type:
python demo.py
There are also some sample mini applications available for you to run
and to play with as a learning exercise.
The next thing you should do is join the wxPython-users maillist where
you can interact with a community of other users and developers who
are willing to help you learn, answer questions and solve problems.
To join the mail list just go to this web page and follow the
instructions there:
http://wxpython.org/maillist.php
There is also a good set of class reference documentation available
for wxPython, but currently it is geared for the C++ user. This may
be a little daunting at first, but with a little practice you'll
easily be able to "mentally translate" from the C++ shown into Python.
(See http://wiki.wxpython.org/index.cgi/C_2b_2bGuideForwxPythoneers
for a little help on this process.) Not all classes documented are
available in Python, but most of the GUI related classes are.
Other Info
----------
Please also see the following files in this directory:
CHANGES.txt Information about new features, fixes,
etc. in each release.
../README.1st.txt Instructions for building wxGTK and
wxPython on Unix-like platforms the
"new way."
BUILD.unix.txt Instructions for building wxPython on
various Unix-like platforms the "old way."
BUILD.win32.txt Instructions for building wxPython on Windows.
BUILD.osx.txt Instructions for building wxPython on Mac OS X.
licence/* Text of the wxWindows license.
-----------------
Robin Dunn
robin@alldunn.com