Building wxPython 2.6 for Development and Testing

Building wxPython 2.7 for Development and Testing

This file describes how I build wxWidgets and wxPython while doing development and testing, and is meant to help other people that want to do the same thing. I'll assume that you are using either a CVS snapshot from http://wxWidgets.org/snapshots/, a checkout from CVS, or -one of the released wxPython-src-2.6.* tarballs. I'll also assume that +one of the released wxPython-src-2.7.* tarballs. I'll also assume that you know your way around your system, the compiler, etc. and most importantly, that you know what you are doing! ;-)

If you want to also install the version of wxPython you build to be in @@ -28,14 +310,14 @@ may already have installed.

If you want to make changes to any of the *.i files, (SWIG interface definition files,) or to regenerate the extension sources or renamer modules, then you will need an up to date version of SWIG, -plus some patches. Get the sources for version 1.3.24, and then apply +plus some patches. Get the sources for version 1.3.29, and then apply the patches in wxPython/SWIG and then build SWIG like normal. See the README.txt in the wxPython/SWIG dir for details about each patch and also info about those that may already have been applied to the SWIG sources. If you install this build of SWIG to a location that is not on the PATH (so it doesn't interfere with an existing SWIG install for -example) then you can set a setup.py command-line variable named SWIG -to be the full path name of the executable and the wxPython build will +example) then you can use a setup.py command-line option named SWIG +set to the full path name of the executable and the wxPython build will use it. See below for an example.

In the text below I'll use WXDIR with environment variable syntax (either $WXDIR or %WXDIR%) to refer to the top level directory where @@ -53,8 +335,8 @@ installed from one of the standard wxWidgets installers. With the 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.

Building on Unix-like Systems (e.g. Linux and OS X)

These platforms are built almost the same way while in development so I'll combine the descriptions about their build process here. First we will build wxWidgets and install it to an out of the way @@ -71,12 +353,13 @@ before:

cd $WXDIR mkdir bld cd bld -../configure --prefix=/opt/wx/2.6 \ +../configure --prefix=/opt/wx/2.7 \ --with-gtk \ --with-gnomeprint \ --with-opengl \ --enable-debug \ --enable-geometry \ + --enable-graphics_ctx \ --enable-sound --with-sdl \ --enable-mediactrl \ --enable-display \ @@ -84,6 +367,15 @@ cd bld

On OS X of course you'll want to use --with-mac instead of --with-gtk and --with-gnomeprint.

Notice that above I used a prefix option of "/opt/wx/2.7". You can +use whatever path you want, such as a path in your HOME dir or even +one of the standard prefix paths such as /usr or /usr/local if you +like, but using /opt this way lets me easily have multiple versions +and ports of wxWidgets "installed" and makes it easy to switch +between them, without impacting any versions of wxWidgets that may +have been installed via an RPM or whatever. For the rest of the +steps below be sure to also substitute "/opt/wx/2.7" with whatever +prefix you choose for your build.

NOTE: Due to a recent change there is currently a dependency problem in the multilib builds of wxWidgets on OSX, so I have switched to using a monolithic build. That means that all of the @@ -101,23 +393,14 @@ it by changing the --with-gtk flag to specify it like this:

--with-gtk=1 \

To make the wxWidgets build be unicode enabled (strongly -recommended if you are building with GTK2) then add the following. -When wxPython is unicode enabled then all strings that are passed -to wx functions and methods will first be converted to unicode -objects, and any 'strings' returned from wx functions and methods -will actually be unicode objects.:

+recommended unless you are building with GTK1) then add the +following flag. When wxPython is unicode enabled then all strings +that are passed to wx functions and methods will first be converted +to unicode objects, and any 'strings' returned from wx functions +and methods will actually be unicode objects.:

 --enable-unicode \

Notice that I used a prefix of /opt/wx/2.6. You can use whatever -path you want, such as a path in your HOME dir or even one of the -standard prefix paths such as /usr or /usr/local if you like, but -using /opt this way lets me easily have multiple versions and ports -of wxWidgets "installed" and makes it easy to switch between them, -without impacting any versions of wxWidgets that may have been -installed via an RPM or whatever. For the rest of the steps below -be sure to also substitute "/opt/wx/2.6" with whatever prefix you -choose for your build.

If you want to use the image and zlib libraries included with wxWidgets instead of those already installed on your system, (for example, to reduce dependencies on 3rd party libraries) then you @@ -130,16 +413,16 @@ can add these flags to the configure command:

To build and install wxWidgets you could just use the "make" -command but there are other libraries besides the main wxWidgets -libs that also need to be built so again I make a script to do it -all for me so I don't forget anything. This time it is called -".make" (I use the leading "." so when I do rm -r * in my build -dir I don't lose my scripts too.) This is what it looks like:

+command but there are a couple other libraries besides the main +wxWidgets libs that also need to be built so again I make a script +to do it all for me so I don't forget anything. This time it is +called ".make" (I use the leading "." so when I do rm -r * in +my build dir I don't lose my scripts too.) This is what it looks +like:

 make $* \
-    && make -C contrib/src/animate $* \
     && make -C contrib/src/gizmos $* \
-    && make -C contrib/src/stc $* 
+    && make -C contrib/src/stc $*

So you just use .make as if it where make, but don't forget to set the execute bit on .make first!:

@@ -148,16 +431,16 @@ the execute bit on .make first!:

.make install

When it's done you should have an installed set of files under -/opt/wx/2.6 containing just wxWidgets. Now to use this version of -wxWidgets you just need to add /opt/wx/2.6/bin to the PATH and set -LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.6/lib.

+/opt/wx/2.7 containing just wxWidgets. Now to use this version of +wxWidgets you just need to add /opt/wx/2.7/bin to the PATH and set +LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.7/lib.

I also have a script to help me build wxPython and it is checked in to the CVS as wxWidgets/wxPython/b, but you 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.

+you'll probably get stuck. So in this document 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 @@ -167,33 +450,33 @@ INSTALL.txt.

If you have more than one version of Python on your system then be sure to use the version of Python that you want to use when running wxPython programs to run the setup.py commands below. I'll be -using python2.3.

Make sure that the first wx-config found on the PATH is the one you -installed above, and then change to the $WXDIR/wxPython dir and -run the this command:

+using python2.5.

Make sure that the first wx-config found on the PATH is the one +belonging to the wxWidgets that you installed above, and then +change to the $WXDIR/wxPython dir and run the this command:

 cd $WXDIR/wxPython
-python2.3 setup.py build_ext --inplace --debug
+python2.5 setup.py build_ext --inplace --debug

If your new wx-config script is not on the PATH, or there is some other version of it found first, then you can add this to the command line to ensure your new one is used instead:

-WX_CONFIG=/opt/wx/2.6/bin/wx-config
+WX_CONFIG=/opt/wx/2.7/bin/wx-config

By default setup.py will assume that you built wxWidgets to use GTK2. If you built wxWidgets to use GTK 1.2.x then you should add this flag to the command-line:

-WXPORT=gtk 
+WXPORT=gtk

If you would like to do a Unicode enabled build (all strings sent -to or retruned from wx functions are Unicode objects) and your -wxWidgets was built with unicode enabled then add this flag:

Setup.py will assume by default that you are using a unicode build +of wxWidgets. If not then you can use this flag:

-UNICODE=1
+UNICODE=0

If you are wanting to have the source files regenerated with swig, +(only neccessary if you make modifications to the *.i files,) 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:

@@ -203,28 +486,28 @@ USE_SWIG=1 SWIG=/opt/swig/bin/swig
 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.
-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 (*.so files)
-located in the wx package.
+When the setup.py command is done you should have a fully populated
+(but uninstalled) wx package located in your $WXDIR/wxPython/wx
+directory.

To run code with the development version of wxPython, just set the PYTHONPATH to the wxPython dir located in the source tree. For example:

-export LD_LIBRARY_PATH=/opt/wx/2.6/lib
+export LD_LIBRARY_PATH=/opt/wx/2.7/lib
 export PYTHONPATH=$WXDIR/wxPython
 cd $WXDIR/wxPython/demo
-python2.3 demo.py
+python2.5 demo.py

OS X NOTE: You need to use "pythonw" on the command line to run -wxPython applications. This version of the Python executable is -part of the Python Framework and is allowed to interact with the -display. You can also double click on a .py or a .pyw file from -the finder (assuming that the PythonLauncher app is associated with -these file extensions) and it will launch the Framework version of -Python for you. For information about creating Applicaiton Bundles -of your wxPython apps please see the wiki and the mail lists.

OS X NOTE: Depending on your version of OS X and Python you may +need to use "pythonw" on the command line to run wxPython +applications. This version of the Python executable is part of the +Python Framework and is allowed to interact with the display. You +can also double click on a .py or a .pyw file from the finder +(assuming that the PythonLauncher app is associated with these file +extensions) and it will launch the Framework version of Python for +you. For information about creating Applicaiton Bundles of your +wxPython apps please see the wiki and the mail lists.

SOLARIS NOTE: If you get unresolved symbol errors when importing wxPython and you are running on Solaris and building with gcc, then you may be able to work around the problem by uncommenting a bit of @@ -234,27 +517,28 @@ does not automatically add libgcc to the link step.

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 accommodate 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 library is -used. The Python executable that comes from PythonLabs and the -wxPython extensions that I distribute are built with MSVC 6 with all -the Service Packs applied. This policy will change with Python 2.4 -and MSVC 7.1 will be used starting with that version.

+to accommodate that. (And send the patches to me.)

The standard Python 2.3 and earlier are built with MS Visual C 6.0 and +so you must also build with MSVC 6 in order to be used with the stock +python.exe. If you woudl rather use a different version of +VisualStudio 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 library is used. The stock Python +2.4 and 2.5 executables are built with MSVC 7.1, and the same rules +apply to it.

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 -or python23_d.dll. If you don't need to trace through the C/C++ parts +or python25_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.

@@ -277,7 +561,7 @@ differently.

The *.btm files are for 4NT and the others are for bash. They are:

 .make/.make.btm        Builds the main lib and the needed contribs
-.mymake/.mymake.btm    Builds just one lib, use by .make
+.mymake/.mymake.btm    Builds just one lib, used by .make
 .makesetup.mk          A makefile that will copy and edit setup.h
                        as needed for the different types of builds

@@ -298,20 +582,18 @@ copy setup0.h setup.h

Edit %WXDIR%\include\wx\msw\setup.h and change a few settings:

-wxDIALOG_UNIT_COMPATIBILITY    0
-wxUSE_DEBUG_CONTEXT            1
-wxUSE_MEMORY_TRACING           1
+wxUSE_DEBUGREPORT              0
+wxUSE_EXCEPTIONS               0
 wxUSE_DIALUP_MANAGER           0
+wxUSE_GRAPHICS_CONTEXT         1
 wxUSE_GLCANVAS                 1
 wxUSE_POSTSCRIPT               1
-wxUSE_AFM_FOR_POSTSCRIPT       0
-wxUSE_DISPLAY                  1
-wxUSE_DEBUGREPORT              0
+wxUSE_DIB_FOR_BITMAP           1

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:

+changed automatically 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:

 wxUSE_UNICODE                  1
 wxUSE_UNICODE_MSLU             1
@@ -357,11 +639,11 @@ clean up the build:
 executing nmake with a bunch of extra command line parameters.
 The base set are:
 -nmake -f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1
+nmake -f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 USE_GDIPLUS=1
 
 If doing a debug build then add:
 -BUILD=debug 
+BUILD=debug
 
 otherwise add these:
 @@ -372,14 +654,7 @@ DEBUG_FLAG=1 CXXFLAGS=/D__NO_VC_CRTDBG__ WXDEBUGFLAG=h BUILD=release
 UNICODE=1 MSLU=1
 
 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:
--%WXDIR%\contrib\build\animate
-%WXDIR%\contrib\build\gizmos
-%WXDIR%\contrib\build\stc
-
+selection of command-line flags as described above.

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 @@ -398,13 +673,14 @@ build for (if you have more than one on your system) and to match the MONOLITHIC flag with how you built wxWidgets:

 cd %WXDIR%\wxPython
-python setup.py build_ext --inplace MONOLITHIC=1
+python setup.py build_ext --inplace MONOLITHIC=0

-USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe
+USE_SWIG=1 SWIG=e:\\projects\\SWIG-1.2.29\\swig.exe

If you built a Unicode version of wxWidgets and want to also build the Unicode version of wxPython then add this flag:

diff --git a/wxPython/docs/CHANGES.html b/wxPython/docs/CHANGES.html index 65ea7c18a5..47321450eb 100644 --- a/wxPython/docs/CHANGES.html +++ b/wxPython/docs/CHANGES.html @@ -3,15 +3,693 @@ - + Recent Changes for wxPython - +

Recent Changes for wxPython

2.6.2.1

2.7.1.1

18-Oct-2006

The following deprecated items have been removed:

+
+
wx.Bitmap SetQuality and GetQuality methods
+
The wx.GetNumberFromUser function
+
wx.EVT_LIST_GET_INFO and wx.EVT_LIST_SET_INFO
+
wx.BookCtrlSizer and wx.NotebookSizer
+
The PostScript-specific methods of wx.PrintData
+
wx.PrintDialogData SetSetupDialog and GetSetupDialog methods
+
wx.FontMapper SetConfig method
+
wx.html.HtmlSearchStatus.GetContentsItem method
+
wx.html.HtmlHelpData.GetContents, GetContentsCnt, GetIndex, and +GetIndexCnt methods
+
+

wx.EventLoop is now implemented for wxMac.

Added wxPython wrappers for the new wx.Treebook and wx.Toolbook +classes.

wx.DC.BeginDrawing and EndDrawing have been deprecated in the C++ +code, so since they never really did anything before they are now just +empty stubs in wxPython.

Solved a problem that has been around for a very long time in how C++ +methods are virtualized for overriding in derived Python classes. +Previously we couldn't do it for methods that needed to also exist in +the base class wrappers such that they could be called normally. (The +reasons are long and complex, but suffice it to say that it was due to +mixing C++'s dynamic dispatch, and Python's runtime lookup of the +method attributes resulting in endless recursion of function calls.) +Because of this problem I used a hack that I have always hated, and +that is renaming the base class methods with a "base_*" prefix, for +example wx.Printout.base_OnBeginDocument. Now that the problem has +finally been solved I have replaced all the base_Whatever() methods +with the real Whatever() method as well as a simple wrapper named +base_Whatever that is marked as deprecated. So now instead of writing +your overridden methods like this:

+def OnBeginDocument(self, start, end):
+    # do something here
+    return self.base_OnBeginDocument(start, end)
+

You can now call the base class method the normal way, like this:

+def OnBeginDocument(self, start, end):
+    # do something here
+    return Printout.OnBeginDocument(self, start, end)
+

Or like this with super():

+def OnBeginDocument(self, start, end):
+    # do something here
+    return super(MyPrintout, self).OnBeginDocument(start, end)
+

Note that the old way with the "base_*" function still works, but you +will get a DeprecationWarning from calling base_OnBeginDocument. The +classes affected by this are:

+
+
wx.DropSource
+
wx.DropTarget
+
wx.TextDropTarget
+
wx.FileDropTarget
+
wx.PyLog (also added the ability to override Flush)
+
wx.PyApp (also added the ability to override ExitMainLoop)
+
wx.Printout
+
wx.PyPrintPreview
+
wx.PyPreviewFrame
+
wx.PreviewControlBar
+
wx.Process
+
wx.PyControl
+
wx.PyPanel
+
wx.PyScrolledWindow
+
wx.PyWindow
+
wx.Timer
+
wx.grid.PyGridCellRenderer
+
wx.grid.PyGridCellEditor
+
wx.grid.PyGridCellAttrProvider
+
wx.grid.PyGridTableBase
+
wx.html.HtmlWindow
+
wx.wizard.PyWizardPage
+
+

Added the wx.DC.GradientFillConcentric and wx.DC.GradientFillLinear +methods.

wxGTK: wx.ListBox and wx.CheckListBox are now using native GTK2 +widgets.

Added wx.ListBox.HitTest() from patch 1446207

Bumped up to SWIG 1.3.29. This provides some more runtime performance +boosts, gets rid of the dreaded Ptr classes, and some other nice new +things.

Added wx.Window.GetScreenPosition and GetScreenRect which returns the +position of the window in screen coordinates, even if the window is +not a top-level window.

Added GetResourcesDir and GetLocalizedResourcesDir to +wx.StandardPaths.

Added a GetReceivedFormat method to wx.DataObjectComposite. You can +use this to find out what format of data object was recieved from the +source of the clipboard or DnD operation, and then you'll know which +of the component data objects to use to access the data.

Changed how the stock objects (wx.RED, wx.RED_PEN, wx.RED_BRUSH, etc.) +are initialized. They are now created as uninitialized instances +using __new__. Then after the wx.App has been created, but before +OnInit is called, the .this attribute of each obhect is initialized. +This was needed because of some delayed initialization functionality +that was implemented in wxWidgets, but the end result is cleaner for +wxPython as well, and allowed me to remove some ugly code previously +hidden under the covers.

Added wx.StandardPaths.GetDocumentsDir.

Added wx.RendererNative.DrawCheckButton.

wx.ProgressDialog.Update now returns a tuple of two values. The first +is a continue flag (what was returned before) and the second is a skip +flag. If the dialog has the wx.PD_CAN_SKIP flag and if the Skip +button is clicked, then the skip flag is set to True the next time +Update is called.

A DeprecationWarning is now issued when the old wxPython package is +imported. If you are still using the old namespace please convert +your code to use the new wx package instead.

Added wrappers for Julian's new wxRichTextCtrl class, visible in +wxPython as wx.richtext.RichTextCtrl window. It still needs some more +work, but it is a great start.

wx.lib.mixins.listctrl.TextEditMixin: Fixed the double END_LABEL_EDIT +event problem in TextEditMixin by checking if the editor was already +hidden before continuing with the CloseEditor method. Also added code +to OpenEditor to send the BEGIN_LABEL_EDIT event and to not allow the +opening of the editor to continue if the event handler doesn't allow +it.

wx.StaticBoxSizer now keeps better track of the wx.StaticBox, and it +will destroy it if the sizer is destroyed before the parent window is.

Added wx.HyperlinkCtrl.

Added battery and power related functions and events (wxMSW only so +far.) See wx.PowerEvent, wx.GetPowerType and wx.GetBatteryState.

Added wx.ListCtrl.HitTestSubItem which returns the sub-item (i.e. the +column in report mode) that was hit (if any) in addition to the item +and flags.

Added wrappers for wx.ColourPickerCtrl, wx.DirPickerCtrl, +wx.FilePickerCtrl, and wx.FontPickerCtrl.

Patch #1502016 wx.Image.ConvertToGreyscale now retains the alpha +channel.

Added wrappers for the wxAUI classes, in the wx.aui module.

Added the PseudoDC class from Paul Lanier. It provides a way to +record operations on a DC and then play them back later.

Upgraded to Scintilla 1.70 for wx.stc.StyledTextCtrl.

Added CanSetTransparent and SetTransparent methods to the +wx.TopLevelWindow class, with implementations (so far) for wxMSW and +wxMac.

SetDefaultItem() and GetDefaultItem() are now members of +wx.TopLevelWindow, not wx.Panel.

wxGTK: Stock items (icons) will be used for menu items with stock +IDs.

Added wx.lib.combotreebox from Frank Niessink

Added wx.ImageFromBuffer, wx.BitmapFromBuffer and +wx.BitmapFromBufferRGBA factory functions. They enable loading of an +image or bitmap directly from a Python object that implements the +buffer interface, such as strings, arrays, etc.

Added wx.App.IsDisplayAvailable() which can be used to determine if a +GUI can be created in the current environment. (Still need an +implementation for wxMSW...)

The wx.html.HTML_FONT_SIZE_x constants are no longer available as the +default sizes are now calculated at runtime based on the size of the +normal GUI font.

wx.Colour now includes an alpha component, which defaults to +wx.ALPHA_OPAQUE. This is in preparation for allowing various new +alpha blening functionality using wx.Colour objects, such as drawing +with pens and brushes on a wx.DC.

Added wx.NativePixelBuffer, wx.AlphPixelBuffer and related iterator +and accessor classes. They allow platform independent direct access +to the platform specific pixel buffer inside of a wx.Bitmap object.

The beginnings of support for RTL languages has been added, thanks to +a Google SoC project.

Added wx.lib.dragscroller from Riaan Booysen. It provides a helper +class that can used to scroll a wx.ScrolledWindow in response to a +mouse drag.

Applied patch 1551409: Adds support for indeterminate mode gauges.

wxMac: I've turned on the compile option for using the native toolbar +on the Mac now that it supports hosting of controls. If the toolbar +is managed by the frame via either CreateToolBar() or SetToolBar() +then the native toolbar will be used. Additional toolbars, or +toolbars that are not children of the frame, are managed by sizers or +what-not will still use the emulated toolbar because of platform +restrictions in how/where the native toolbar can be used.

Added Python properties for many of the getter/setter methods of wx +classes. In order for the names to be predicatble for somebody +already familiar with wxPython the property names are simply the name +of the getter with the "Get" dropped. For example, wx.Window has a +property named "Size" that maps to GetSize and SetSize. So far there +is only one known name conflict using this naming convention, and that +is wx.KeyEvent.KeyCode, however since KeyCode was formerly a +compatibility alias for GetKeyCode (and has been for a long time) it +was decided to just switch it to a property. If you want to use the +method then change your calls to event.KeyCode() to +event.GetKeyCode(), otherwise you can use it as a property just by +dropping the parentheses.

Updated the C++ code for wx.gizmos.TreeListCtrl from the wxCode +project. This has resulted in some minor API changes, most of which +were worked around in the wrapper code.

Added wx.lib.delayedresult from Oliver Schoenborn.

Added wx.lib.expando, a multi-line textctrl that exands as more lines +are needed.

wx.Image.Scale and Rescale methods now take an extra parameter +specifying type of method to use for resampling the image. It +defaults to the current behavior of just replicating pixels, if +wx.IMAGE_QUALITY_HIGH is passed then it uses bicubic and box averaging +resampling methods for upsampling and downsampling respectively.

Added the wx.lib.buttonpanel module, which is a tweaked version of +Andrea Gavana's FancyButtonPanel module.

Added the wx.lib.flatnotebook module, from Andrea Gavana.

Renamed wx.FutureCall to wx.CallLater so it is named more like +wx.CallAfter. wx.FutureCall is now an empty subclass of wx.CallLater +for compatibility of older code.

Added the wx.lib.customtreectrl the from Andrea Gavana.

Added ChangeSelection to wx.BookCtrl (the base class for wx.Notebook +and other book controls) that is the same as SetSelection but doesn't +send the change events.

Added wx.TextCtrl.ChangeValue() which is the same as SetValue() but +doesn't send the text changed event.

For consistency, all classes having an Ok() method now also have +IsOk(), use of the latter form is preferred although the former hasn't +been deprecated yet

Added the wx.AboutBox() function and wx.AboutDialogInfo class. They +provide a way to show a standard About box for the application, which +will either be a native dialog or a generic one depending on what info +is provided and if it can all be shown with the native dialog.

The code in the animate contrib has been moved into the code wxWidgets +library, and refactored a bit along the way. For wxPython it still +exists in the wx.animate module, but has basically been reduced to two +classes, wx.animate.Animation, and wx.animate.AnimationCtrl. You load +the animated GIF (and hopefully there will be other supported formats +in the near future) in the Animation object, and then give that to the +AnimatedCtrl for display. See the demo for an example. There is also +still a GIFAnimationCtrl class that provides some level of backwards +compatibility with the old implementation.

wxMac: The compile option that turns on the use of CoreGraphics (a.k.a +Quartz) for wxDC is now turned on by default. This means that all +drawing via wxDC is done using the new APIs from apple, instead of the +old Quick Draw API. There are, however, a few places where Quartz and +wxDC don't fit together very well, mainly the lack of support for +logical drawing operations such as XOR, but there is work in progress +to provide other ways to do the same sort of thing that will work with +Quartz and also on the other platforms.

The first parts of a new 2D drawing API has been added with the +wx.GraphicsPath and wx.GraphicsContext classes. They wrap GDI+ on +Windows, Cairo on wxGTK and CoreGraphics on OS X. They allow path-based +drawing with alpha-blending and anti-aliasing, and use a floating +point cooridnate system. Currently they can only target drawing to +windows, but other wx.DC backends are forthcoming. The APIs may +evolve a bit more before they are finalaized with the 2.8 release, but +there is enough there now to get a good feel for how things will work. +There is also a transitional wx.GCDC class that provides the wx.DC API +on top of wx.GraphicsContext. Docs and a demo are still MIA.

Added a wx.AutoBufferedPaintDC that is a subclass of wx.PaintDC on +platforms that do double buffering by default, and a subclass of +wx.BufferedPaintDC on the platforms that don't. You can use this +class to help avoid the overhead of buffering when it is not +needed. There is also a wx.AutoBufferedPaintDCFactory function that +does a little more and actually tests if the window has +double-buffering enabled and then decides whether to return a +wx.PaintDC or wx.BufferedPaintDC. This uses the new +wx.Window.IsDoubleBuffered method.

2.6.3.3

15-July-2006

wx.lib.pubsub updates from Oliver Schoenborn:

fixed the hash problem with non-hashable objects
now supports listeners that use *args as an argument +(listener(*args) was not passing the validity test)
corrected some mistakes in documentation
added some clarifications (hopefully useful for first time +users)
changed the way singleton is implemented since old way prevented +pydoc etc from extracting docs for Publisher

DocView and ActiveGrid IDE updates from Morgan Hua:

New Features: In Tab-View mode, Ctrl-number will take the user to +the numbered tab view. Modified files now show an '*' astrisk in +the view title. Debugger framework can now support PHP debugging. +Not important for python development, but at least that means the +debugger framework is more generalized.

Undeprecated wx.GetNumberFromUser and added wx.NumberEntryDialog.

Made necessaary changes for building wxPython for Python 2.5. There +may still be some issues related to the new Py_ssize_t type and 64-bit +machines, but at least all compile errors and warnings related to it +have been resolved.

2.6.3.2

3-April-2006

Fixed reference leak in wx.gizmos.TreeListCtrl.GetSelections.

wxMSW: Fixed sizing issue with wx.Choice and wx.ComboBox. This change +was implemented by reverting a prior fix for a different problem +(contiuous painting/resizing when a combobox is used as a widget in a +wx.html.HtmlWindow) so a method to fix both problems is still being +investigated.

wxGTK: Fixed potential buffer overrun when pasting from the +clipboard.

Fixed problem in wx.lib.splitter when used on 64-bit platforms. Used +the current length of the list for specifying an append instead of +sys.maxint.

wxMSW: Support added for XP themed owner drawn buttons and bitmap +buttons. For example, if you change the foreground color of a button +it will now be drawn with the XP themed style rather than an ugly +generic button style.

XRCed: Fix for Copy/Paste objects with international characters.

Fixed the equality and inequality operators for some of the basic +data types (wx.Point, wx.Size, wx.Colour, etc.) to no longer raise a +TypeError if the compared object is not compatible, but to just return +a boolean as expected. For example:

+wx.Colour(64,0,64) == 123      ==> False
+

wxMSW: Fixed (again) sizing/positioning issues of calling Realize on +a wx.ToolBar that is not manaaged directly by a frame and that is +already shown.

wxMSW: Fixed wx.Choice/wx.ComboBox so they send events when a new item +is selected only with the keyboard.

2.6.3.0

27-March-2006

Change the wx.ListCtrl InsertStringItem wrapper to use the form that +takes an imageIndex, and set the default to -1. This ensures that on +wxMSW that if there is an image list but they don't specify an image, +the native control doesn't use one anyway.

wxMSW: wx.ListCtrl in report mode is now able to support images in +other columns besides the first one. Simply pass an image index to +SetStringItem. For virtual list controls you can specify the image to +use on the extra columns by overriding OnGetItemColumnImage in your +derived class. It is passed the item number and the column number as +parameters, and the default version simply calls OnGetItemImage for +column zero, or returns -1 for other columns.

Switched to using SWIG 1.3.27 for generating the wrapper code. There +are some small changes needed to SWIG to work around some bugs that +wxPython exposes, and to be able to generate code that matches that +which wxPython is using. If you are building wxPython yourself and +need to modify any of the *.i files or to add your own, then you will +want to be sure to use a matching SWIG. See wxPython/SWIG/README.txt +in the source tarball for details.

wx.Image.Copy, Mirror, and GetSubImage now also do the right thing +with the alpha channel.

wxMSW: Fixed problem in wx.TextCtrl where using SetValue and +wx.TE_RICH2 would cause the control to be shown if it was hidden.

wxMSW: Numpad special keys are now distinguished from normal keys in +key events.

wxMSW: Multiline notebook tab label change now resizes the control +correctly if an extra row is removed or added.

wxMSW: On XP fall back to unthemed wxNotebook if specified orientation +not available in the themed version.

Added wx.Toolbar.GetToolsCount.

Added wx.GridSizer.CalcRowsCols.

Added wx.OutputStream.LastWrite.

wxGTK: EVT_SET_CURSOR is now sent.

wxGTK: Fix RequestMore for idle events.

wxGTK: Implement user dashes for PS and GNOME printing.

wxGTK: Correct update region code. Don't always invalidate the whole +window upon resize. Reenable support for thewx.NO_FULL_REPAINT_ON_RESIZE +flag. Also disable refreshing custom controls when focusing in and out.

wx.lib.pubsub: Publisher is now able to parse a dotted notation string +into a topic tuple. For example: subscribing to "timer.clock.seconds" +is the same as subscribing to ("timer", "clock", "seconds").

Applied patch #1441370: lib.plot - allow passing in wx.Colour()

Added wx.CommandEvent.GetClientData.

Updated wxStyledTextCtrl to use version 1.67 of Scintilla. +NOTE: The STC_LEX_ASP and STC_LEX_PHP lexers have been deprecated, +you should use STC_LEX_HTML instead.

wxSTC: Implemented Fix for SF Bug #1436503. Delay the start of the +DnD operation in case the user just intended to click, not drag.

Updated the analogclock.py module to the new analogclock package from +E. A. Tacao.

Added the wx.lib.mixins.listctrl.CheckListCtrlMixin class from Bruce +Who, which makes it easy to put checkboxes on list control items.

Applied a patch from Christian Kristukat to wx.lib.plot that adds +scrollbars when the plot is zoomed in, and also the ability to grab a +zoomed plot and move it around with a mouse drag.

XRCed updated to allow wxMenuBar to be created inside a wxFrame.

Added wx.StandardPaths.GetDocumentsDir() (patch 1214360)

2.6.2.1

10-Jan-2006

@@ -31,13 +709,12 @@ wx.SplitterWindow class, except it allows more than one split, so it can manage more than two child windows.

Docview and IDE patch from Morgan Hua with fix for bug #1217890 "Closing view crashes Python" plus some new features:

+
 New feature added to the IDE is 'Extensions'.  Under
 Tools|Options|Extensions, you can add calls to external programs.
 For example you can add a "Notepad" extension (under windows) that
 will exec Notepad on the currently open file.  A new "Notepad"
-menu item will appear under the Tools menu.
-

+menu item will appear under the Tools menu.

Some fixes to XRCed to make encoding errors a bit more user friendly.

XRCed changes from Roman Rolinsky:

@@ -180,8 +857,8 @@ ellipses to take (w,h) pair. This is an API change, but should be easy to accommodate, all you need to do is add a parenthesis pair: (...x, y, ...) ---> (...(x,y), ...)

2.6.1.0

4-June-2005

@@ -208,8 +885,8 @@ calls.

wx.FileConfig: fixed DeleteEntry to set the dirty flag properly so the change will get written at the next flush.

2.6.0.1

30-May-2005

@@ -321,8 +998,8 @@ usual.

there is a range of allowed values (so a wx.SpinCtrl is used instead of a wx.TextCtrl.)

2.6.0.0

26-Apr-2005

@@ -399,8 +1076,8 @@ EVT_KEY_UP and EVT_TEXT events from its embedded text control.

2.5.5.1

8-Apr-2005

@@ -468,8 +1145,8 @@ list of top-level windows that currently exist in the application.

folks.

Added the ActiveGrid IDE as a sample application.

2.5.4.1

16-Mar-2005

@@ -702,8 +1379,8 @@ wx.Image.

2.5.3.1

9-Nov-2004

@@ -859,8 +1536,8 @@ it.

wxPython on OSX can now be built in Unicode mode, can support multiple version installs, and comes with an uninstaller script.

2.5.2.8

27-Aug-2004

@@ -891,8 +1568,8 @@ wxCheckListBox.

2.5.2.7

14-Aug-2004

@@ -990,8 +1667,8 @@ in the PyShell:

wxGTK: Applied wxNO_BORDER patch (#1098374) for text control and combo box.

2.5.1.5 (the 'this is not a joke' release)

2-Apr-2004

@@ -1075,8 +1752,8 @@ migrating away from using activexwrapper as well. Please see the MigrationGuide for more details on using the new module.

Floats are allowed again as function parameters where ints are expected.

2.4.2.4

1-Oct-2003

@@ -1088,8 +1765,8 @@ demonstrated in the Threads sample in the demo.

Added wxMaskedNumCtrl.

Added Chris Barker's FloatCanvas.

2.4.1.2

19-Jun-2003

@@ -1143,8 +1820,8 @@ release,) SetItemMinSize can now take a wxSize (or 2-tuple) parameter, and Spacers can be specified with a wxSize (or 2-tuple) parameter

Added wxCursorFromBits.

2.4.0.7

24-Mar-2003

@@ -1165,8 +1842,8 @@ flag to turn it on. In most cases turning it into an exception (the default behavior) is enough. See below in the 2.3.4.1 notes for more details.

2.4.0.6 (a.k.a. the I'm so stupid release)

11-Mar-2003

@@ -1174,8 +1851,8 @@ details.

returned from OnInit. And I promise to be sure I am testing what I think I am testing in the future...

2.4.0.5 (a.k.a. the blame it on Kevin release)

7-Mar-2003

@@ -1183,8 +1860,8 @@ think I am testing in the future...

Updated pycolourchooser.

Updated to 0.9b of PyCrust.

2.4.0.4

7-Mar-2003

@@ -1244,8 +1921,8 @@ doesn't have a standard place for them.

Fixed typemaps for wxGridCellCoordsArray.

Updated to the 0.9a version of PyCrust

2.4.0.2

23-Jan-2003

@@ -1253,8 +1930,8 @@ doesn't have a standard place for them.

Added wxIntCtrl from Will Sadkin.

Added wxPyColourChooser by Michael Gilfix.

2.4.0.1

10-Jan-2003

@@ -1263,15 +1940,15 @@ enhancements.

Added function wrappers for the common dialogs from Kevin Altis. See wxPython/lib/dialogs.py for more details.

2.3.4.2

21-Dec-2002

Various bug fixes.

2.3.4.1

18-Dec-2002

@@ -1328,8 +2005,8 @@ windows when desired.

HTMLHelp viewer does. Changed how the wxPythonDocs tarball is built and added a script to launch the doc viewer.

2.3.3.1

19-Sep-2002

@@ -1474,8 +2151,8 @@ example.

Added wxPython.lib.mixins.rubberband module from Robb Shecter.

Added wxTimeCtrl from Will Sadkin.

2.3.2.1

20-Dec-2001

@@ -1484,8 +2161,8 @@ well as the Python thread state. This time it works on SMP machines without barfing and is also still compatible with Python debuggers.

Added some patches from library contributors.

2.3.2

11-Dec-2001

@@ -1570,8 +2247,8 @@ SendCommand method, but it is still quite powerful. See wxPython/contrib/dllwidget and wxPython/demo/dllwidget for more details.

2.3.1

10-Jul-2001

@@ -1587,8 +2264,8 @@ subclass wxXmlResourceHandler, etc...

Fixed img2py to work correctly with Python 2.1.

Added enhanced wxVTKRenderWindow by Prabhu Ramachandran

2.3.0

22-May-2001

@@ -1687,16 +2364,16 @@ please send it to me for inclusion in this package.

by having smaller functional apps to play with. They can be found in wxPython/samples.

2.2.7

19-Jun-2001

No changes happened in the Python wrappers for this release, only changes and fixes in the wxWindows library.

2.2.5

30-Jan-2001

@@ -1739,8 +2416,8 @@ mouse won't be captured when the event handler is called.

integrated with the demo yet. It allows a wxPython GUI to be an XML-RPC server.

New in 2.2.2

26-Oct-2000

@@ -1779,16 +2456,16 @@ libwxPyHelpers.so on unix systems.

wxStyledTextCtrl to behave better. It's still not as nice as on wxMSW, but at least it's a bit more usable now.

New in 2.2.1

22-Aug-2000

Various tweaks, fixes, missing methods, etc.

Added example use of wxTaskBarIcon to the demo.

New in 2.2.0

17-Jul-2000

@@ -1796,8 +2473,8 @@ wxMSW, but at least it's a bit more usable now.

Added wxFrame.ShowFullScreen for MSW.

Added PyShellWindow to the wxPython.lib package.

New in 2.1.16

12-Jun-2000

@@ -1832,8 +2509,8 @@ OnCloseWindow OnScroll

Added wxSpinCtrl.

New in 2.1.15

25-Apr-2000

@@ -1876,8 +2553,8 @@ can also refer to the Scintilla documentaion at until the docs are done. (The croud murmers contentedly as the tool provider smiles convincingly and removes his flame-proof suit.)

What's new in 2.1.13

3-Feb-2000

@@ -1942,8 +2619,8 @@ package.

than wxMSW! (The feat is accomplished by using the wxTB_DOCKABLE style flag instead of trying to float it ourselves.)

What's new in 2.1.11

13-Nov-1999

@@ -1980,8 +2657,8 @@ Python object in the event handler instead of a new shadow.

wxGTK...

Added an MVC tree control from Bryn Keller to the library.

What's new in 2.1.5

12-Oct-1999

@@ -1989,8 +2666,8 @@ wxGTK...

crept in at the last minute before 2.1.4 was called done. No new major features.

What's new in 2.1.4

7-Oct-1999

@@ -2104,8 +2781,8 @@ bar back into the original parent. (Unfortunately there is currently a bug in wxGTK's wxFrame.SetToolBar so the FloatBar has some problems...)

What's new in 2.1b3

1-Sep-1999

@@ -2140,8 +2817,8 @@ two different versions. wxDC.BlitXY is like what was there before and takes raw coordinants and sizes, and the new wxDC.Blit is for the new interface using wxPoints and a wxSize.

What's new in 2.1b2

6-Aug-1999

@@ -2187,8 +2864,8 @@ for unix systems.

SWIG support routines now compiled separately instead of being bundled in wx.cpp.

What's new in 2.1b1

28-Jun-1999

@@ -2209,8 +2886,8 @@ of windows and sizers. Different types of sizers apply different types of layout algorithms. You saw it here first! These classes are not even in the wxWindows C++ library yet!

What's new in 2.0b9

1-May-1999

@@ -2234,8 +2911,8 @@ wxGIFHandler and wxBMPHandler.

Fixed some problems with how SWIG was wrapping some wxTreeCtrl methods.

What's new in 2.0b8

28-Mar-1999

@@ -2243,24 +2920,24 @@ methods.

Several missing methods from various classes.

Various bug fixes.

What's new in 2.0b7

15-Mar-1999

Added DLG_PNT and DLG_SZE convienience methods to wxWindow class.

Added missing constructor and other methods for wxMenuItem.

What's new in 2.0b6

4-Mar-1999

Just a quickie update to fix the self-installer to be compatible with Python 1.5.2b2's Registry settings.

What's new in 2.0b5

25-Feb-1999

@@ -2281,8 +2958,8 @@ it should just work... More news on this later.

wxRegConfig class.

As usual, some bug fixes, tweaks, etc.

What's new in 0.5.3

30-Jan-1999

@@ -2290,8 +2967,8 @@ wxRegConfig class.

Various cleanup, tweaks, minor additions, etc. to maintain compatibility with the current wxWindows.

What's new in 0.5.0

Changed the import semantics from "from wxPython import *" to "from wxPython.wx import *" This is for people who are worried about namespace pollution, they can use "from wxPython import wx" and then @@ -2304,8 +2981,8 @@ prefix all the wxPython identifiers with "wx."

objects to references to reflect changes in the wxWindows API.

Other assorted fixes and additions.

What's new in 0.4.2

21-Oct-1998

@@ -2318,8 +2995,8 @@ behavior was so different on different platforms.

The dynamicly loaded module on Solaris is still segfaulting, so it must have been a different issue all along...

What's New in 0.4

2-Oct-1998

@@ -2334,8 +3011,8 @@ version segfault shortly after starting up.

Varioius bug fixes, enhancements, etc.

wxPython 0.3

9-Aug-1998

diff --git a/wxPython/docs/CHANGES.txt b/wxPython/docs/CHANGES.txt index 78902d9dec..538c4627ae 100644 --- a/wxPython/docs/CHANGES.txt +++ b/wxPython/docs/CHANGES.txt @@ -3,7 +3,7 @@ Recent Changes for wxPython 2.7.1.1 ------- -* +* 18-Oct-2006 The following deprecated items have been removed: diff --git a/wxPython/docs/INSTALL.html b/wxPython/docs/INSTALL.html index 72ab7c7b0d..9c3570c25b 100644 --- a/wxPython/docs/INSTALL.html +++ b/wxPython/docs/INSTALL.html @@ -3,20 +3,302 @@ - -Installing wxPython 2.6 from Source - + +Installing wxPython 2.7 from Source + -

Installing wxPython 2.6 from Source

Installing wxPython 2.7 from Source

This document will describe the few differences and additions to the content in the BUILD document for installing wxPython built from source. Please follow the intstructions both in this file and in BUILD to perform this task. Where there is overlap the items described here will take precedence for doing installations.

Installing on Unix-like Systems (not OS X)

When building wxWidgets you need to decide if you want it to be a private copy only accessed by wxPython, or if you would like it to @@ -49,7 +331,7 @@ find the wxWidgets shared libraries. You can hard code the library path into the binaries by using the rpath option when configuring wxWidgets. For example:
```
---enable-rpath=/opt/wx/2.6/lib \
+--enable-rpath=/opt/wx/2.7/lib \
 
```
SOLARIS NOTE: The --enable-rpath option may cause problems when using wxGTK on Solaris when compiling wxPython as described below. @@ -69,7 +351,7 @@ into the same bin dir used by Python by using this command, plus whatever WXPORT, UNICODE, etc. settings you used for the initial build step:
```
-python2.3 setup.py install 
+python2.5 setup.py install
 
```
If you would like to install to some place besides the prefix where Python is installed, (such as to your home directory) then you can @@ -81,8 +363,8 @@ contained in the PYTHONPATH environment variable.

Installing on OS X

Installing wxPython on OS X is nearly the same as the Unix instructions above, except for a few small, but important details:

@@ -112,8 +394,8 @@ app to run wxPython apps, otherwise the app will not be able to fully use the GUI display.

Installing on Windows

Build wxWidgets and wxPython as described in BUILD.txt. If you would rather have a version without the code that turns runtime @@ -131,7 +413,7 @@ python setup.py install found at runtime by the extension modules without requiring that they be installed on the PATH:
```
-copy %WXWIN%\lib\vc_dll\wx*h_*.dll c:\Python23\Lib\site-packages\wx
+copy %WXWIN%\\lib\\vc_dll\\wx*h_*.dll c:\\Python25\\Lib\\site-packages\\wx
 
```

diff --git a/wxPython/docs/MigrationGuide.html b/wxPython/docs/MigrationGuide.html index 215018ffa1..8c00b5a60a 100644 --- a/wxPython/docs/MigrationGuide.html +++ b/wxPython/docs/MigrationGuide.html @@ -3,9 +3,291 @@ - + wxPython 2.6 Migration Guide - +

@@ -15,8 +297,8 @@ your programs to those changes. Be sure to also check in the CHANGES file like usual to see info about the not so major changes and other things that have been added to wxPython.

wxName Change

The wxWindows project and library is now known as wxWidgets. Please see here for more details.

This won't really affect wxPython all that much, other than the fact @@ -25,8 +307,8 @@ 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.

Module Initialization

The import-startup-bootstrap process employed by wxPython was changed such that wxWidgets and the underlying gui toolkit are not initialized until the wx.App object is created (but before wx.App.OnInit @@ -51,8 +333,8 @@ 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.

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:

@@ -79,8 +361,8 @@ class type using something like isinstance(obj, wx.FooPtr) you will need to change it to isinstance(obj, wx.Foo).

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 @@ -132,11 +414,11 @@ values:

item = menu.Append(-1, "E&xit", "Terminate the App") self.Bind(wx.EVT_MENU, self.OnExit, item) -2. +2. item = menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App") self.Bind(wx.EVT_MENU, self.OnExit, item) -3. +3. menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App") self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT) @@ -167,8 +449,8 @@ def Unbind(self, event, source=None, id=wx.ID_ANY, id2=wx.ID_ANY): """

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 @@ -225,8 +507,8 @@ 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

[Changed in 2.5.2.x] 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 @@ -240,7 +522,7 @@ FloodFill(self, x, y, colour, style = wx.FLOOD_SURFACE) FoodFillPoint(self, pt, colour, style = wx.FLOOD_SURFACE) GetPixel(self, x,y) -GetPixelPoint(self, pt) +GetPixelPoint(self, pt) DrawLine(self, x1, y1, x2, y2) DrawLinePoint(self, pt1, pt2) @@ -289,7 +571,7 @@ 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, +BlitPointSize(self, destPt, sz, sourceDC, srcPt, rop = wx.COPY, useMask = False, srcPtMask = wxDefaultPosition) @@ -299,8 +581,8 @@ SetClippingRegionAsRegion(self, region) SetClippingRect(self, rect)

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 @@ -339,8 +621,8 @@ are wrapped in the standard Py_(BEGIN|END)_ALLOW_THERADS may result in wx event handlers being called (such as during the call to os.startfile.)

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 @@ -355,8 +637,8 @@ class MyDialog(wx.Dialog): self.PostCreate(pre)

Sizers

The hack allowing the old "option" keyword parameter has been removed. If you use keyword args with wx.Sizer Add, Insert, or Prepend methods then you will need to use the proportion name instead of @@ -473,8 +755,8 @@ This can be done by calling SetBe

- -PlatformInfo + +PlatformInfo Added wx.PlatformInfo which is a tuple containing strings that describe the platform and build options of wxPython. This lets you know more about the build than just the __WXPORT__ value that @@ -495,8 +777,8 @@ way. If there are any other platform/toolkit/build flags that make sense to add to this tuple please let me know. BTW, wx.Platform will probably be deprecated in the future. - -ActiveX + +ActiveX Lindsay Mathieson's newest wxActiveX class has been wrapped into a new extension module called wx.activex. It is very generic and dynamic and should allow hosting of arbitray ActiveX controls within your @@ -585,7 +867,7 @@ new window from being opened by the IE web browser control you can do this in the handler for the iewin.EVT_NewWindow2 event: def OnNewWindow2(self, evt): - evt.Cancel = True + evt.Cancel = True So how do you know what methods, events and properties that an ActiveX control supports? There is a funciton in wx.activex named GetAXInfo @@ -596,8 +878,8 @@ 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. - -PNG Images + +PNG Images 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 @@ -619,8 +901,8 @@ fully transparent. - -OGL is dead! LONG LIVE OGL! + +OGL is dead! LONG LIVE OGL! [Changed in 2.5.2.x] The wx.ogl module was deprecated in version 2.5.2 in favor of the new Python port of the OGL library located at wx.lib.ogl contributed by @@ -664,11 +946,11 @@ class MyDividedShape(ogl.DividedShape): ... def OnSizingEndDragLeft(self, pt, x, y, keys, attch): ogl.DividedShape.OnSizingEndDragLeft(self, pt, x, y, keys, attch) - ... + ... - -Obsolete Modules + +Obsolete Modules 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 @@ -718,8 +1000,8 @@ the objects in these modules only via the wx or wxPython.wx packages: 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. - -wx.TaskBarIcon + +wx.TaskBarIcon [Changed in 2.5.3.x] wx.TaskbarIcon now works on all three platforms, although for wxGTK it depends on support from the Window Manager. On OS X the icon replaces @@ -747,8 +1029,8 @@ wx.Dialogs.) If you don't destroy it then wxWidgets will assume that you want the app to keep running with just the icon in the task bar and the MainLoop will not exit. - -Version Number Change + +Version Number Change [Changed in 2.5.3.x] Starting with 2.5.3.0 the Unicode versions of wxPython will no longer have a 'u' appended to the fourth component of the version number. @@ -761,8 +1043,8 @@ if "unicode" in wx.PlatformInfo: ... - -Multi-Version Installs + +Multi-Version Installs [Changed in 2.5.3.x] Starting with 2.5.3.0 the wx and wxPython package directories will be installed in a subdirectory of the site-packages directory, instead of @@ -803,8 +1085,8 @@ version of wxPython that supports this, but there will be. Please see this wiki page for more details, HowTo's and FAQ's: http://wiki.wxpython.org/index.cgi/MultiVersionInstalls - -Miscellaneous Stuff + +Miscellaneous Stuff wxPyDefaultPosition and wxPyDefaultSize are gone. Use the wxDefaultPosition and wxDefaultSize objects instead. Similarly, the wxSystemSettings backwards compatibiility aliases for diff --git a/wxPython/docs/PyManual.html b/wxPython/docs/PyManual.html index ef13f79413..94783053a0 100644 --- a/wxPython/docs/PyManual.html +++ b/wxPython/docs/PyManual.html @@ -3,12 +3,294 @@ - + The Py Manual - + @@ -30,8 +312,8 @@ 1.5 - -Contents + +Contents Introduction Developer Reference @@ -75,20 +357,20 @@ - -Introduction + +Introduction This document will show you how to use the Py programs and the Py library of Python source code modules. Py is the new name for the project that began as PyCrust. Py is officially part of wxPython, and includes PyCrust, so PyCrust is no longer distributed separately. - -Developer Reference + +Developer Reference Source code documentation for developers is available at: http://www.orbtech.com/www/wx/epydoc/public/wx.py-module.html - -What is Py? + +What is Py? Besides being a delicious dessert, Py is the name for a collection of whimsically-named Python programs and modules that began as the PyCrust project. So Py is really several things: a set of standalone @@ -99,8 +381,8 @@ do something, you might as well do it all the way, right?) Py uses Python and wxPython, so it works equally well on Windows, Linux and Mac OS X. - -PyCrust is dead! Long live Py! + +PyCrust is dead! Long live Py! This project began with a program I created called PyCrust - an interactive, graphical Python shell, developed using the wxPython GUI toolkit. For about two years, PyCrust was hosted on SourceForge. @@ -136,8 +418,8 @@ 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. - -Py standalone programs + +Py standalone programs These are the standalone applications in the Py collection: PyAlaCarte @@ -148,42 +430,42 @@ These modules are the same ones used by all the Py programs. PyWrap - -PyAlaCarte + +PyAlaCarte PyAlaCarte is a Python source code editor. It is designed to have a simple, single-file interface. As a standalone application, it is good for simple, short editing tasks. But it is really meant to be more of an example of how to embed the Py editor into a wxPython application. - -PyAlaMode + +PyAlaMode PyAlaMode is a Python source code editor. - -PyCrust + +PyCrust PyCrust is an interactive, Python shell. But it's more than just a shell. It includes a tabbed notebook containing a namespace tree (PyFilling), and several other things. - -PyFilling + +PyFilling PyFilling is a namespace viewer. It isn't really useful as a standalone program, but it does illustrate how to make use of the underlying filling module. - -PyShell + +PyShell PyShell is an interactive, Python shell. It shares the same base code as PyCrust, but doesn't have any of the extra features that appear in the PyCrust notebook interface. - + PyShell running on Mandrake Linux. - -PyWrap + +PyWrap PyWrap is a runtime utility that lets you run an existing wxPython program with a PyCrust frame at the same time. Inside the PyCrust shell namespace, the local variable app is assigned to your @@ -191,8 +473,8 @@ application instance. In this way you can introspect your entire application within the PyCrust shell, as well as the PyFilling namespace viewer. - -Py modules + +Py modules Py was designed to be modular. That means graphical code is kept separate from non-graphical code, and many of the Py modules can be used by other programs. Likewise, other programs can supply some of @@ -202,8 +484,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. - -Projects using Py + +Projects using Py Conflict Solver Gnumed @@ -215,12 +497,12 @@ its default interpreter. wxGasp - -History of changes + +History of changes This section lists all the changes that have been made to the Py programs and modules, since the beginning. - -0.9.5 (12/23/2005) + +0.9.5 (12/23/2005) Applied a series of enhancments by Franz Steinaeusler, Adi Sieker, and Sebastian Haase, up until their 7-31-2005 version. (Their next version broke some existing functionality, and added some confusing @@ -261,7 +543,7 @@ place that then has to reach all over the place to do anything. Enable editing of the startup python code, which will either be the file pointed to by PYTHONSTARTUP or a file in the config dir if PYTHONSTARTUP is not set in the environment. -Added an option to skip the running of the startup code when + Added an option to skip the running of the startup code when PyShell or PyCrust starts. PyCrust adds a pp(item) function to the shell's namespace that pretty prints the item in the Display tab of the notebook. Added @@ -271,8 +553,8 @@ when popping up the call tip. Added Find and Find-Next functions that use the wx.FindReplaceDialog. - -0.9.4 (1/25/2004 to //2004) + +0.9.4 (1/25/2004 to //2004) Removed wxd decorators in favor of new SWIG-generated docstrings. Removed docs tabs from crust interface: * wxPython Docs @@ -282,13 +564,13 @@ when popping up the call tip. Changed default namespace of Shell to __main__.__dict__, instead of an empty dictionary. - -0.9.3 (9/25/2003 to 1/24/2004) + +0.9.3 (9/25/2003 to 1/24/2004) 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. - -0.9.2 (5/3/2003 to 9/25/2003) + +0.9.2 (5/3/2003 to 9/25/2003) Changed to the new prefix-less "wx" package: import wx @@ -330,8 +612,8 @@ def CanPaste(self): return stc.StyledTextCtrl.CanPaste(self) and self.CanEdit() - -0.9.1 (3/21/2003 to 5/2/2003) + +0.9.1 (3/21/2003 to 5/2/2003) PyCrust is dead! Long live Py! Renamed PyCrust package to py. @@ -365,8 +647,8 @@ base. The current implementation of wxSTC can now handle lists this big. Improved handling of sys.path to mimic the standard Python shell. - -0.9 (2/27/2003 to 3/20/2003) + +0.9 (2/27/2003 to 3/20/2003) Added fontIncrease, fontDecrease, fontDefault signals, receivers and keybindings: @@ -397,8 +679,8 @@ except NameError: Added wxd directory with decoration classes. - -0.8.2 (1/5/2003 to 2/26/2003) + +0.8.2 (1/5/2003 to 2/26/2003) Wrapped sys.ps1, sys.ps2, and sys.ps3 in str(). (Thanks, Kieran Holland.) Fixed minor things found by PyChecker. @@ -432,8 +714,8 @@ func = 3 . More Filling!!! The namespace tree is now dynamically updated. - -0.8.1 (12/20/2002 to 12/25/2002) + +0.8.1 (12/20/2002 to 12/25/2002) Improved keyboard handling with Autocomplete active. You can now use Enter as well as Tab to select an item from the list. Disabled autocomplete for lists of 2000 items or more. The current @@ -444,8 +726,8 @@ coming directly from the source code. (Hmmm. Sounds like someone is doing some decorating. I wonder where that would be helpful? <wink>) Fixed handling of icon. Added images.py file. - -0.8 (10/29/2002 to 12/16/2002) + +0.8 (10/29/2002 to 12/16/2002) Added "help" to startup banner info. Made all wx and stc imports explicit. No more import *. Replaced use of the wx module's true and false with @@ -471,8 +753,8 @@ Platform: linux2 Added time.sleep() in readline() and OnIdle() event handler to free up the CPU. - -0.7.2 (2/22/2002 to 8/27/2002) + +0.7.2 (2/22/2002 to 8/27/2002) Tweaked getAttributeNames() to pick up a few more attributes: '__bases__', '__class__', '__dict__', '__name__', 'func_closure', @@ -509,8 +791,8 @@ to Raul Cota for pointing this out. boxes. Renamed readIn to readline and readRaw to raw_input. - -0.7.1 (12/12/2001 to 2/21/2002) + +0.7.1 (12/12/2001 to 2/21/2002) Fixed OnChar() issues effecting European keyboards, as reported by Jean-Michel Fauth. Fixed introspect.py issue with xmlrpc objects reported by Kevin @@ -536,8 +818,8 @@ to insert from history - Shift+Up and Shift+Down. Better call tips on objects with __call__ methods. Improved call tip positioning calculation. - -0.7 (10/15/2001 to 12/11/2001) + +0.7 (10/15/2001 to 12/11/2001) Changed how command history retrieval functions work. Added Alt-P, Alt-N as keybindings for Retrieve-Previous, Retrieve-Next. Added full support for multi-line commands, similar to IDLE. @@ -560,8 +842,8 @@ package/module name conflicts that kept you from doing __date__ property from all modules. Fixed bug in introspect.getCallTip(), reported by Kevin Altis. - -0.6.1 (9/19/2001 to 10/12/2001) + +0.6.1 (9/19/2001 to 10/12/2001) Changed Shell.run() to always position to the end of existing text, as suggested by Raul Cota. Changed introspect.getAllAttributeNames() to break circular @@ -578,8 +860,8 @@ platform where the font was 2 points larger than what was specified. ZODB objects that are asleep - in a "ghost" state. Otherwise it returns incomplete info. - -0.6 (8/21/2001 to 9/12/2001) + +0.6 (8/21/2001 to 9/12/2001) Added PyFilling.py and filling.py. PyShell.py and PyFilling.py can now be run standalone, as well as PyCrust.py. @@ -599,8 +881,8 @@ sys.path.insert(0, os.curdir) Added support for distutils installations. - -0.5.4 (8/17/2001 to 8/20/2001) + +0.5.4 (8/17/2001 to 8/20/2001) Changed default font size under Linux to: 'size' : 12, @@ -617,15 +899,15 @@ demo. Split PyCrust.py into PyCrust.py and PyShell.py in anticipation of PyFilling.py. - -0.5.3 (8/16/2001) + +0.5.3 (8/16/2001) Added patch to PyCrust.py to fix wxPython bug: wxID_SELECTALL = NewId() # This *should* be defined by wxPython. - -0.5.2 (8/14/2001 to 8/15/2001) + +0.5.2 (8/14/2001 to 8/15/2001) Shortened module names by dropping "PyCrust" as a prefix. Changed version to VERSION in version module. Added Options menu to PyCrust application. @@ -635,8 +917,8 @@ There just wasn't enough non-gui code to justify the separation. Plus, Shell will be much easier for gui toolkits/designers to deal with now. - -0.5.1 (8/10/2001 to 8/14/2001) + +0.5.1 (8/10/2001 to 8/14/2001) Added introspect module. Moved some functionality from PyCrustInterp to introspect. Changed introspect.getRoot() to no longer remove whitespace from @@ -687,32 +969,32 @@ exclude one or the other or both with: >>> shell.editor.autoCompleteExcludeDouble = 1 - -0.5 (8/8/2001) + +0.5 (8/8/2001) Mostly just a final version change before creating a release. - -0.4 (8/4/2001 to 8/7/2001) + +0.4 (8/4/2001 to 8/7/2001) Changed version/revision handling. Fixed bugs. - -0.3 (8/2/2001 to 8/3/2001) + +0.3 (8/2/2001 to 8/3/2001) Removed lots of cruft. Added lots of docstrings. Imported to CVS repository at SourceForge. Added call tips. - -0.2 (7/30/2001 to 8/2/2001) + +0.2 (7/30/2001 to 8/2/2001) Renamed several files. Added command autocompletion. Added menus to PyCrust.py: File, Edit and Help. Added sample applications: PyCrustAlaCarte.py, PyCrustAlaMode.py, and PyCrustMinimus.py. - -0.1 (7/1/2001 to 7/19/2001) + +0.1 (7/1/2001 to 7/19/2001) Added basic syntax coloring much like Boa. Added read-only logging much like IDLE. Can retrieve a previous command by putting the cursor back on that @@ -724,8 +1006,8 @@ response. Home key honors the prompt. Created SourceForge account, but nothing was posted. - -In the beginning, there was pie... (7/1/2001) + +In the beginning, there was pie... (7/1/2001) 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 diff --git a/wxPython/docs/README.html b/wxPython/docs/README.html index 86e0f84d38..cbb71134d9 100644 --- a/wxPython/docs/README.html +++ b/wxPython/docs/README.html @@ -3,14 +3,296 @@ - + - + - -wxPython README + +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 @@ -38,8 +320,8 @@ easily be able to "mentally translate" from the C++ shown into Python. 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 + +Other Info Please also see the following files: diff --git a/wxPython/docs/wxPackage.html b/wxPython/docs/wxPackage.html index 82d666958c..303e1b20fa 100644 --- a/wxPython/docs/wxPackage.html +++ b/wxPython/docs/wxPackage.html @@ -3,13 +3,295 @@ - + The wxPython wx Package - + @@ -33,8 +315,8 @@ 1.4 - -Contents + +Contents Introduction Why change anything? @@ -46,8 +328,8 @@ Where can I find example programs using the new wx syntax? - -Introduction + +Introduction In the begining there was Python, and Python had modules, and Python was good. But after a time Guido looked on Python and saw that Python needed organizational assistance, and so Guido took code from Python's @@ -69,8 +351,8 @@ have concerning the new wx package. Please also take a look at the 2.5 Migration Guide to see notes about other big differences in this release. - -Why change anything? + +Why change anything? This change is being made for a couple of reasons. The first reason is to discourage the use of import *, which is a dangerous technique that can create name conflicts and bloated namespaces. @@ -93,8 +375,8 @@ class Frame(wx.Frame) the same thing (implement a new wx namespace and drop the "wx" prefix) and we want wxPython to lead the way. - -What does the new wx package do? + +What does the new wx package do? As mentioned in the Introduction, wxPython 2.4.1 introduced a way of getting to this new syntax as quickly as possible. It would import the old names (like "wxFrame") from the old package and then create new @@ -108,8 +390,8 @@ populated with modules that simply import the new names and then complicated, but it is mostly automated and so it doesn't cause problems in most cases. - -Will any of this effect my existing code? + +Will any of this effect my existing code? No. Your existing code will continue to work and be supported for some time. It will be up to you to decide when to switch to the new syntax. But all new documentation and code examples will use the new @@ -123,24 +405,24 @@ old code is depending on some of the implemtation details, or if you are using other things that have changed in the API. See the Migration Guide for more details. - -What about all the other modules, like grid, html, and stc? + +What about all the other modules, like grid, html, and stc? There's more to the old wxPython than just the wxPython.wx module. And we've got those extra modules covered as well. Each of those modules (as well as the lib subpackage) has been moved to the new wx package and reverse-renamers have been placed in the wxPython package as needed. - -How do I use this new wx package? + +How do I use this new wx package? The wx package is automatically created when you install wxPython version 2.4.1 or higher. So all you have to do is: import wx - -What are the issues with converting old code to use the new wx package? + +What are the issues with converting old code to use the new wx package? Obviously, you need to change your import statements from: from wxPython import wx @@ -161,8 +443,8 @@ class MyFrame(wx.Frame): In most cases, existing code can be modified with a simple search and replace. - -Where can I find example programs using the new wx syntax? + +Where can I find example programs using the new wx syntax? The wxPython demo application and most of the sample apps have been converted to use the new import wx style of programming with wxPython, so there are lots of examples to look at and to play with. diff --git a/wxPython/docs/wxPythonManual.html b/wxPython/docs/wxPythonManual.html index e7e3ac611f..02459a305b 100644 --- a/wxPython/docs/wxPythonManual.html +++ b/wxPython/docs/wxPythonManual.html @@ -3,12 +3,294 @@ - + The wxPython Manual - + @@ -32,8 +314,8 @@ - -Contents + +Contents Introduction What is wxPython? @@ -93,8 +375,8 @@ License - -Introduction + +Introduction This is a guide to the wxPython GUI toolkit, written by a Python programmer for his fellow Python programmers. It began as a simple translation of the wxWidgets documentation (which is written @@ -108,8 +390,8 @@ beans, dark chocolate, and large denomination currency. Better yet, buy huge quantities of my wxPython book (written with Robin Dunn) and send one to each of your friends, relatives, and coworkers. - -What is wxPython? + +What is wxPython? wxPython is a GUI toolkit for the Python programming language. It allows Python programmers to create programs with a robust, highly functional graphical user interface, simply and easily. It is @@ -126,19 +408,19 @@ or unix-like systems, and Macintosh OS X. Since the language is Python, wxPython programs are simple, easy to write and easy to understand. - -wxPython requirements + +wxPython requirements To make use of wxPython, you currently need one of the following setups. - -MS-Windows + +MS-Windows A 486 or higher PC running MS Windows. At least ?? MB of disk space. - -Linux or Unix + +Linux or Unix Almost any C++ compiler, including GNU C++ (EGCS 1.1.1 or above). Almost any Unix workstation, and one of: GTK+ 1.2, GTK+ 2.0, Motif @@ -146,16 +428,16 @@ setups. At least ?? MB of disk space. - -Mac OS X + +Mac OS X A PowerPC Mac running Mac OS X 10.x. At least ?? MB of disk space. - -What is wxWidgets? + +What is wxWidgets? wxWidgets is a C++ framework providing GUI (Graphical User Interface) and other facilities on more than one platform. Version 2 currently supports all desktop versions of MS Windows, Unix with GTK+, Unix with @@ -169,8 +451,8 @@ Roebling, Vadim Zeitlin, Vaclav Slavik and many others. platforms related to Microsoft Windows, including 16-bit and 32-bit variants, unless otherwise stated. All trademarks are acknowledged. - -Why another cross-platform development tool? + +Why another cross-platform development tool? wxWidgets was developed to provide a cheap and flexible way to maximize investment in GUI application development. While a number of commercial class libraries already existed for cross-platform @@ -244,8 +526,8 @@ the clipboard. PNM, PCX). - -wxPython Overview + +wxPython Overview To set a wxPython application going, you will need to derive an App class and override App.OnInit. An application must have a top-level Frame or Dialog window. Each @@ -291,14 +573,14 @@ PathList. There's a miscellany of operating system and other functions. See also Classes by Category for a list of classes. - -Utilities and libraries supplied with wxPython + +Utilities and libraries supplied with wxPython In addition to the core wxWidgets library, a number of further libraries and utilities are supplied with each distribution. [Need to list these.] - -Creating and deleting wxPython objects + +Creating and deleting wxPython objects [This section needs to be reviewed.] - -App overview + +App overview Classes: wx.App - -Application initialization + +Application initialization The OnInit method defined for a class derived from wx.App will usually create a top window as a bare minimum. OnInit must return a boolean value to indicate whether processing @@ -365,8 +647,8 @@ if __name__ == '__main__': main() - -Application shutdown + +Application shutdown The application normally shuts down when the last of its top level windows is closed. This is normally the expected behaviour and means that it is enough to call Close() in response to the "Exit" menu @@ -385,8 +667,8 @@ created by the time OnExit finishes. [Need examples of objects needing cleanup to keep app from crashing.] - -Sizer overview + +Sizer overview Classes: wx.Sizer, wx.GridSizer, wx.FlexGridSizer, wx.BoxSizer, wx.StaticBoxSizer, wx.NotebookSizer, wx.CreateButtonSizer @@ -425,8 +707,8 @@ individual controls. Editors such as wxDesigner, wxrcedit, XRCed and wxWorkshop create dialogs based exclusively on sizers, practically forcing the user to create platform independent layouts without compromises. - -The idea behind sizers + +The idea behind sizers The layout algorithm used by sizers in wxPython is closely related to layout systems in other GUI toolkits, such as Java's AWT, the GTK toolkit or the Qt toolkit. It is based upon the idea of individual @@ -453,15 +735,15 @@ in a dialog or it fulfils a special task such as wrapping a static box around a dialog item (or another sizer). These sizers will be discussed one by one in the text below. - -Common features + +Common features All sizers are containers, that is, they are used to lay out one dialog item (or several dialog items), which they contain. Such items are sometimes referred to as the children of the sizer. Independent of how the individual sizers lay out their children, all children have certain features in common: - -A minimal size + +A minimal size This minimal size is usually identical to the initial size of the controls and may either be set explicitly in the size field of the control constructor or may be calculated by wxPython, typically by @@ -472,8 +754,8 @@ thus require an explicit size. Some controls can calculate their height, but not their width (e.g. a single line text control): [Need graphics] - -A border + +A border The border is just empty space and is used to separate dialog items in a dialog. This border can either be all around, or at any combination of sides such as only above and below the control. The thickness of @@ -482,8 +764,8 @@ samples show dialogs with only one dialog item (a button) and a border of 0, 5, and 10 pixels around the button: [Need graphics] - -An alignment + +An alignment Often, a dialog item is given more space than its minimal size plus its border. Depending on what flags are used for the respective dialog item, the dialog item can be made to fill out the available space @@ -494,8 +776,8 @@ three buttons in a horizontal box sizer; one button is centred, one is aligned at the top, one is aligned at the bottom: [Need graphics] - -A stretch factor + +A stretch factor If a sizer contains more than one child and it is offered more space than its children and their borders need, the question arises how to distribute the surplus space among the children. For this purpose, a @@ -513,8 +795,8 @@ have a stretch factor of zero and keep their initial width: Within wxDesigner, this stretch factor gets set from the Option menu. - -BoxSizer + +BoxSizer BoxSizer can lay out its children either vertically or horizontally, depending on what flag is being used in its constructor. When using a vertical sizer, each child can be centered, aligned to the right or @@ -527,14 +809,14 @@ horizontally. The following sample shows the same dialog as in the last sample, only the box sizer is a vertical box sizer now: [Need graphics] - -StaticBoxSizer + +StaticBoxSizer StaticBoxSixer is the same as a BoxSizer, but surrounded by a static box. Here is a sample: [Need graphics] - -GridSizer + +GridSizer GridSizer is a two-dimensional sizer. All children are given the same size, which is the minimal size required by the biggest child, in this case the text control in the left bottom border. Either the number of @@ -542,8 +824,8 @@ columns or the number or rows is fixed and the grid sizer will grow in the respectively other orientation if new children are added: [Need graphics] - -FlexGridSizer + +FlexGridSizer Another two-dimensional sizer derived from GridSizer. The width of each column and the height of each row are calculated individually according the minimal requirements from the respectively biggest @@ -553,16 +835,16 @@ it requested. The following sample shows the same dialog as the one above, but using a flex grid sizer: [Need graphics] - -NotebookSizer + +NotebookSizer NotebookSizer can be used with notebooks. It calculates the size of each notebook page and sets the size of the notebook to the size of the biggest page plus some extra space required for the notebook tabs and decorations. [Need graphics] - -Programming with BoxSizer + +Programming with BoxSizer The basic idea behind a BoxSizer is that windows will most often be laid out in rather simple basic geometry, typically in a row or a column or several hierarchies of either. @@ -615,16 +897,16 @@ that the entire behaviour of a sizer and its children can be controlled by the three parameters of the Add() method. [Show code and graphic here.] - -Programming with GridSizer + +Programming with GridSizer GridSizer is a sizer which lays out its children in a two-dimensional table with all table fields having the same size, i.e. the width of each field is the width of the widest child, the height of each field is the height of the tallest child. [Show code and graphic here.] - -Programming with FlexGridSizer + +Programming with FlexGridSizer FlexGridSizer is a sizer which lays out its children in a two-dimensional table with all table fields in one row having the same height and all fields in one column having the same width, but all @@ -632,8 +914,8 @@ rows or all columns are not necessarily the same height or width as in the GridSizer. [Show code and graphic here.] - -Programming with NotebookSizer + +Programming with NotebookSizer NotebookSizer is a specialized sizer to make sizers work in connection with using notebooks. This sizer is different from any other sizer as you must not add any children to it - instead, it queries the notebook @@ -648,15 +930,15 @@ one example showing how to add a notebook page that the notebook sizer is aware of: [Show code and graphic here.] - -Programming with StaticBoxSizer + +Programming with StaticBoxSizer StaticBoxSizer is a sizer derived from BoxSizer but adds a static box around the sizer. Note that this static box has to be created separately. [Show code and graphic here.] - -Dialog.CreateButtonSizer + +Dialog.CreateButtonSizer As a convenience, the Dialog class has a CreateButtonSizer(flags) method that can be used to create a standard button sizer in which standard buttons are displayed. The following flags can be passed to @@ -705,8 +987,8 @@ wx.OK button will be default - -Date and time classes overview + +Date and time classes overview wxPython provides a set of powerful classes to work with dates and times. Some of the supported features of the DateTime class are: @@ -737,8 +1019,8 @@ with them is fast - -All date/time classes at a glance + +All date/time classes at a glance There are 3 main classes: except DateTime itself which represents an absolute moment in time, there are also two classes - TimeSpan and DateSpan which represent the intervals of time. @@ -748,8 +1030,8 @@ date is a holiday or not and DateTimeWorkDays which is a derivation of this class for which (only) Saturdays and Sundays are the holidays. See more about these classes in the discussion of the holidays. - -DateTime characteristics + +DateTime characteristics DateTime stores the time as a signed number of milliseconds since the Epoch which is fixed, by convention, to Jan 1, 1970 - however this is not visible to the class users (in particular, dates prior to the @@ -772,8 +1054,8 @@ country, and even region, dependent). Future versions will probably have Julian calendar support as well and support for other calendars (Maya, Hebrew, Chinese...) is not ruled out. - -Difference between DateSpan and TimeSpan + +Difference between DateSpan and TimeSpan While there is only one logical way to represent an absolute moment in the time (and hence only one DateTime class), there are at least two methods to describe a time interval. @@ -801,8 +1083,8 @@ in the program, you should probably use TimeSpan instead of DateSpan in situations when you do need to understand what 'in a month' means (of course, it is just DateTime.Now() + DateSpan.Month()). - -Date arithmetics + +Date arithmetics Many different operations may be performed with the dates, however not all of them make sense. For example, multiplying a date by a number is an invalid operation, even though multiplying either of the time @@ -838,8 +1120,8 @@ opposite time direction. - -Time zone considerations + +Time zone considerations Although the time is always stored internally in GMT, you will usually work in the local time zone. Because of this, all DateTime constructors and setters which take the broken down date assume that @@ -877,8 +1159,8 @@ job. I.e. you would just write printf("The time is %s in local time zone", dt.FormatTime().c_str()); printf("The time is %s in GMT", dt.FormatTime(wxDateTime::GMT).c_str()); - -Daylight saving time (DST) + +Daylight saving time (DST) DST (a.k.a. 'summer time') handling is always a delicate task which is better left to the operating system which is supposed to be configured by the administrator to behave correctly. Unfortunately, when doing @@ -894,17 +1176,17 @@ the future. The time zone handling methods use these functions too, so they are subject to the same limitations. - -DateTime and Holidays + +DateTime and Holidays [TODO] - -Classes by category + +Classes by category Not done yet. - -ID constants + +ID constants wxPython provides the following predefined ID constants: ID_ABORT ID_ABOUT @@ -964,8 +1246,8 @@ ID_UNDO ID_YES ID_YESTOALL - -Source document + +Source document The source document is named wxPythonManual.txt and can be found by clicking the link at the bottom of this page (assuming you are viewing the html file). It is written using a fantastic formatting convention @@ -973,8 +1255,8 @@ called reStructuredText. The wxPythonManual.html file is created using the Docutils utilities, which can turn reStructuredText documents into html, xml, pdf, and even OpenOffice files. - -Submitting changes to the source document + +Submitting changes to the source document Some items in the source text file look like this: .. This is text from the wxWidgets documentation that needs to be @@ -991,8 +1273,8 @@ to you and will show my gratitude by adding your name to the list of contributors. (Contributors who also send me gifts of coffee, chocolate, or currency will have their names listed in bold.) - -Contributors + +Contributors Individuals who contributed to this documentation (in order by last name): @@ -1003,8 +1285,8 @@ name): Vadim Zeitlin - -License + +License This document began as a translation of the wxWidgets documentation. As such, it adheres to the same license, which is provided here: -- 2.45.2