wxPython doc updates

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@3551 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

docs/latex/wx/dc.tex

@@ -53,8 +53,8 @@ released for each drawing operation.
 \membersection{wxDC::Blit}\label{wxdcblit}
 
 \func{bool}{Blit}{\param{long}{ xdest}, \param{long}{ ydest}, \param{long}{ width}, \param{long}{ height},
-  \param{wxDC* }{source}, \param{long}{ xsrc}, \param{long}{ ysrc}, \param{int}{ logicalFunc},
+  \param{wxDC* }{source}, \param{long}{ xsrc}, \param{long}{ ysrc}, \param{int}{ logicalFunc = wxCOPY},
-  \param{bool }{useMask}}
+  \param{bool }{useMask = FALSE}}
 
 Copy from a source DC to this DC, specifying the destination
 coordinates, size of area to copy, source DC, source coordinates, and
@@ -104,7 +104,7 @@ There is partial support for Blit in wxPostScriptDC, under X.
 
 See \helpref{wxMemoryDC}{wxmemorydc} for typical usage.
 
-wxheading{See also}
+\wxheading{See also}
 
 \helpref{wxMemoryDC}{wxmemorydc}, \helpref{wxBitmap}{wxbitmap}, \helpref{wxMask}{wxmask}
 

docs/latex/wx/manual.tex

@@ -25,7 +25,7 @@
 %\special{!/@scaleunit 1 def}
 \parskip=10pt
 \parindent=0pt
-\title{User Manual for wxWindows 2.1: a portable C++ GUI toolkit}
+\title{wxWindows 2.1: a portable C++ GUI toolkit}
 \winhelponly{\author{by Julian Smart et al
 %\winhelponly{\\$$\image{1cm;0cm}{wxwin.wmf}$$}
 }}

docs/latex/wx/mask.tex

@@ -33,11 +33,16 @@ Default constructor.
 
 Constructs a mask from a monochrome bitmap.
 
+\pythonnote{This is the default constructor for wxMask in wxPython.}
+
 \func{}{wxMask}{\param{const wxBitmap\& }{bitmap}, \param{const wxColour\& }{colour}}
 
 Constructs a mask from a bitmap and a colour that indicates the background. Not
 yet implemented for GTK.
 
+\pythonnote{wxPython has an alternate wxMask constructor matching this
+form called \tt{wxMaskColour}.}
+
 \func{}{wxMask}{\param{const wxBitmap\& }{bitmap}, \param{int}{ index}}
 
 Constructs a mask from a bitmap and a palette index that indicates the background. Not

docs/latex/wx/wxPython.tex

@@ -122,91 +122,83 @@ for a listing of a few of them.
 \section{Building wxPython}\label{wxpbuild}
 
 I used SWIG (\urlref{http://www.swig.org}{http://www.swig.org}) to
-create the source code for the extension module.  This enabled me to
+to create the source code for the
-only have to deal with a small amount of code and only have to bother
+extension module.  This enabled me to only have to deal with a small
-with the exceptional issues.  SWIG takes care of the rest and
+amount of code and only have to bother with the exceptional issues.
-generates all the repetative code for me.  You don't need SWIG to
+SWIG takes care of the rest and generates all the repetative code for
-build the extension module as all the generated C++ code is included
+me.  You don't need SWIG to build the extension module as all the
-under the src directory.  If you try to build wxPython and get errors
+generated C++ code is included under the src directory.
-because SWIG is missing, then simply touch the .cpp and .py files so
-make won't attempt to build them from the .i files.
 
 I added a few minor features to SWIG to control some of the code
-generation.  If you want to play around with this the patches are in
+generation.  If you want to play around with this you will need to get
-wxPython/SWIG.patches and they should be applied to the 1.1p5 version
+a recent version of SWIG from their CVS or from a daily build.  See
-of SWIG.  These new patches are documented at
+\urlref{http://www.swig.org/}{http://www.swig.org/} for details.
-\urlref{this site}{http://starship.skyport.net/crew/robind/python/\#swig},
-and they should also end up in the 1.2 version of SWIG.
 
 wxPython is organized as a Python package.  This means that the
 directory containing the results of the build process should be a
-subdirectory of a directory on the \tt{PYTHONPATH}, (and preferably
+subdirectory of a directory on the \tt{PYTHONPATH}.  (And preferably should
-should be named wxPython.)  You can control where the build process
+be named wxPython.)  You can control where the build process will dump
-will dump wxPython by setting the \tt{TARGETDIR} makefile variable.
+wxPython by setting the \tt{TARGETDIR} variable for the build utility, (see
-The default is \tt{\$(WXWIN)/utils/wxPython}.  If you leave it here
+below.)
-then you should add \tt{\$(WXWIN)/utils} to your \tt{PYTHONPATH}.
-However, you may prefer to use something that is already on your
-\tt{PYTHONPATH}, such as the \tt{site-packages} directory on Unix
-systems.
-
-\wxheading{Win32}
-
-These instructions assume that you have Microsoft Visual C++ 5.0 or
-6.0, that you have installed the command-line tools, and that the
-appropriate environment variables are set for these tools.  You should
-also have Python 1.5.1 installed, and wxWindows installed and built as
-specified below.
 
 \begin{enumerate}\itemsep=0pt
-\item Build wxWindows with \tt{wxUSE_RESOURCE_LOADING_IN_MSW} set to 1 in
+\item Build wxWindows as described in its BuildCVS.txt file.  For *nix
-\tt{include/wx/msw/setup.h} so icons can be loaded dynamically.  While
+   systems I run configure with these flags:
-there, make sure \tt{wxUSE_OWNER_DRAWN} is also set to 1.
+
+\begin{verbatim}
+                --with-gtk
+                --with-libjpeg
+                --without-odbc
+                --enable-unicode=no
+                --enable-threads=yes
+                --enable-socket=yes
+                --enable-static=no
+                --enable-shared=yes
+                --disable-std_iostreams
+\end{verbatim}
+
+   You can use whatever flags you want, but I know these work.
+
+   For Win32 systems I use Visual C++ 6.0, but 5.0 should work also.  The
+   build utility currently does not support any other win32 compilers.
+
+\item At this point you may want to make an alias or symlink, script,
+   batch file, whatever on the PATH that invokes
+   \tt{\$(WXWIN)/utils/wxPython/distrib/build.py} to help simplify matters
+   somewhat.  For example, on my win32 system I have a file named
+   \tt{build}.bat in a directory on the PATH that contains:
+
+   \tt{python \%WXWIN/utils/wxPython/distrib/build.py \%1 \%2 \%3 \%4 \%5 \%6}
+
+
 \item Change into the \tt{\$(WXWIN)/utils/wxPython/src} directory.
-\item Edit makefile.vc and specify where your python installation is at.
+
-You may also want to fiddle with the \tt{TARGETDIR} variable as described
+\item Type "\tt{build -b}" to build wxPython and "\tt{build -i}" to
-above.
+install it, or \"\tt{build -bi}\" to do both steps at once.
-\item Run \tt{nmake -f makefile.vc}
+
-\item If it builds successfully, congratulations!  Move on to the next
+   The build.py script actually generates a Makefile based on what it
-step.  If not then you can try mailing the wxwin-developers list for
+   finds on your system and information found in the build.cfg file.
-help.  Also, I will always have a pre-built win32 version of this extension module at
+   If you have troubles building or you want it built or installed in
-\urlref{http://alldunn.com/wxPython}{http://alldunn.com/wxPython}.
+   a different way, take a look at the docstring in build.py.  You are
+   able to to override many configuration options in a file named
+   build.local.
+
+\item To build and install the add-on modules, change to the appropriate
+   directory under \tt{\$(WXWIN)/utils/wxPython/modules} and run the build
+   utility again.
+
 \item Change to the \tt{\$(WXWIN)/utils/wxPython/demo} directory.
-\item Try executing the demo program.  Note that some of the demos print
-diagnositc or test info to standard output, so they will require the
-console version of python.  For example:
 
-\tt{python demo.py}
-
-To run them without requiring a console, you can use the \tt{pythonw.exe}
-version of Python either from the command line or from a shortcut.
-\end{enumerate}
-
-\wxheading{Unix}
-
-These directions assume that you have already successfully built
-wxWindows for GTK, and installed Python 1.5.1 or later.  If you build Python
-yourself, you will get everything installed that you need simply by
-doing \bftt{make install}.  If you get Python from an RPM or other
-pre-packaged source then there will probably be a separate package
-with the development libraries, etc. that you will need to install.
-
-
-\begin{enumerate}\itemsep=0pt
-\item Change into the \tt{\$(WXWIN)/utils/wxPython/src} directory.
-\item Edit \tt{Setup.in} and ensure that the flags, directories, and toolkit
-options are correct, (hopefully this will be done by \tt{configure}
-soon.)  See the above commentary about \tt{TARGETDIR}.  There are a
-few sample Setup.in.[platform] files provided.
-\item Run this command to generate a makefile:
-
-\tt{make -f Makefile.pre.in boot}
-
-\item Once you have the \tt{Makefile}, run \bftt{make} to build and then
-\bftt{make install} to install the wxPython extension module.
-\item Change to the \tt{\$(WXWIN)/utils/wxPython/demo} directory.
 \item Try executing the demo program.  For example:
 
-\tt{python demo.py}
+    \tt{python demo.py}
+
+To run it without requiring a console on win32, you can use the
+\tt{pythonw.exe} version of Python either from the command line or from a
+shortcut.
+
+
+
 \end{enumerate}
 
 
@@ -314,7 +306,7 @@ it by issuing this command:
 \begin{enumerate}\itemsep=0pt
 \item At line 2 the wxPython classes, constants, and etc. are imported
 into the current module's namespace.  If you prefer to reduce
-namespace polution you can use "\tt{from wxPython import wx}" and
+namespace pollution you can use "\tt{from wxPython import wx}" and
 then access all the wxPython identifiers through the wx module, for
 example, "\tt{wx.wxFrame}".
 \item At line 13 the frame's sizing and moving events are connected to