Regenned the ReST docs
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@27702 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
@@ -11,17 +11,17 @@
|
||||
<div class="document" id="wxpython-2-5-migration-guide">
|
||||
<h1 class="title">wxPython 2.5 Migration Guide</h1>
|
||||
<p>This document will help explain some of the major changes in wxPython
|
||||
2.5 and let you know what you need to do to adapt your programs to
|
||||
those changes. Be sure to also check in the <a class="reference" href="CHANGES.html">CHANGES</a> file like
|
||||
usual to see info about the not so major changes and other things that
|
||||
have been added to wxPython.</p>
|
||||
2.5 since the 2.4 series and let you know what you need to do to adapt
|
||||
your programs to those changes. Be sure to also check in the <a class="reference" href="CHANGES.html">CHANGES</a>
|
||||
file like usual to see info about the not so major changes and other
|
||||
things that have been added to wxPython.</p>
|
||||
<div class="section" id="wxname-change">
|
||||
<h1><a name="wxname-change">wxName Change</a></h1>
|
||||
<p>The <strong>wxWindows</strong> project and library is now known as
|
||||
<strong>wxWidgets</strong>. Please see <a class="reference" href="http://www.wxwidgets.org/name.htm">here</a> for more details.</p>
|
||||
<p>This won't really affect wxPython all that much, other than the fact
|
||||
that the wxwindows.org domain name will be changing to wxwidgets.org,
|
||||
so mail list, CVS, and etc. addresses will be changing. We're going
|
||||
that the wxwindows.org domain name has changed to wxwidgets.org,
|
||||
so mail list, CVS, and etc. addresses have also changed. We're going
|
||||
to try and smooth the transition as much as possible, but I wanted you
|
||||
all to be aware of this change if you run into any issues.</p>
|
||||
</div>
|
||||
@@ -46,6 +46,10 @@ yet.</p>
|
||||
<p>Also, you will probably not be able to do any kind of GUI or bitmap
|
||||
operation unless you first have created an app object, (even on
|
||||
Windows where most anything was possible before.)</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> All the Window and GDI (pen, bitmap, etc.)
|
||||
class constructors and also many toplevel functions and static methods
|
||||
will now check that a wx.App object has already been created and will
|
||||
raise a wx.PyNoAppError exception if not.</p>
|
||||
</div>
|
||||
<div class="section" id="swig-1-3">
|
||||
<h1><a name="swig-1-3">SWIG 1.3</a></h1>
|
||||
@@ -54,23 +58,25 @@ customizations added that I hope to get folded back into the main SWIG
|
||||
distribution.) This has some far reaching ramifications:</p>
|
||||
<blockquote>
|
||||
<p>All classes derive from object and so all are now "new-style
|
||||
classes"</p>
|
||||
classes." This also allows you to use mixin classes that are
|
||||
new-style and to use properties, staticmethod, etc.</p>
|
||||
<p>Public data members of the C++ classes are wrapped as Python
|
||||
properties using property() instead of using __getattr__/__setattr__
|
||||
like before. Normally you shouldn't notice any difference, but if
|
||||
you were previously doing something with __getattr__/__setattr__
|
||||
in derived classes then you may have to adjust things.</p>
|
||||
<p>Static C++ methods are wrapped using the staticmethod()
|
||||
feature of Python and so are accessible as ClassName.MethodName
|
||||
as expected. They are still available as top level functions
|
||||
properties using property() instead of using
|
||||
__getattr__/__setattr__ hacks like before. Normally you shouldn't
|
||||
notice any difference, but if you were previously doing something
|
||||
with __getattr__/__setattr__ in derived classes then you may have
|
||||
to adjust things.</p>
|
||||
<p>Static C++ methods are wrapped using the staticmethod() feature of
|
||||
Python and so are accessible as ClassName.MethodName as expected.
|
||||
They are still also available as top level functions named like
|
||||
ClassName_MethodName as before.</p>
|
||||
<p>The relationship between the wxFoo and wxFooPtr classes have
|
||||
changed for the better. Specifically, all instances that you see
|
||||
will be wxFoo even if they are created internally using wxFooPtr,
|
||||
because wxFooPtr.__init__ will change the instance's __class__ as
|
||||
will be wx.Foo even if they are created internally using wx.FooPtr,
|
||||
because wx.FooPtr.__init__ will change the instance's __class__ as
|
||||
part of the initialization. If you have any code that checks
|
||||
class type using something like isinstance(obj, wxFooPtr) you will
|
||||
need to change it to isinstance(obj, wxFoo).</p>
|
||||
class type using something like isinstance(obj, wx.FooPtr) you will
|
||||
need to change it to isinstance(obj, wx.Foo).</p>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="binding-events">
|
||||
@@ -136,7 +142,7 @@ values:</p>
|
||||
</pre>
|
||||
<p>If you create your own custom event types and EVT_* functions, and you
|
||||
want to be able to use them with the Bind method above then you should
|
||||
change your EVT_* to be an instance of wxPyEventBinder instead of a
|
||||
change your EVT_* to be an instance of wx.PyEventBinder instead of a
|
||||
function. For example, if you used to have something like this:</p>
|
||||
<pre class="literal-block">
|
||||
myCustomEventType = wxNewEventType()
|
||||
@@ -150,6 +156,16 @@ EVT_MY_CUSTOM_EVENT = wx.PyEventBinder(myCustomEventType, 1)
|
||||
</pre>
|
||||
<p>The second parameter is an integer in [0, 1, 2] that specifies the
|
||||
number of IDs that are needed to be passed to Connect.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> There is also an Unbind method added to
|
||||
wx.EvtHandler that can be used to disconenct event handlers. It looks
|
||||
like this:</p>
|
||||
<pre class="literal-block">
|
||||
def Unbind(self, event, source=None, id=wx.ID_ANY, id2=wx.ID_ANY):
|
||||
"""
|
||||
Disconencts the event handler binding for event from self.
|
||||
Returns True if successful.
|
||||
"""
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="the-wx-namespace">
|
||||
<h1><a name="the-wx-namespace">The wx Namespace</a></h1>
|
||||
@@ -162,12 +178,13 @@ Instead of dynamically changing the names at module load time like in
|
||||
2.4, the compatibility modules are generated at build time and contain
|
||||
assignment statements like this:</p>
|
||||
<pre class="literal-block">
|
||||
wxWindow = wx.core.Window
|
||||
wxWindow = wx._core.Window
|
||||
</pre>
|
||||
<p>Don't let the "core" in the name bother you. That and some other
|
||||
<p>Don't let the "_core" in the name bother you. That and some other
|
||||
modules are implementation details, and everything that was in the
|
||||
wxPython.wx module before will still be in the wx package namespace
|
||||
after this change. So from your code you would use it as wx.Window.</p>
|
||||
after this change. So from your code you would use it as wx.Window or
|
||||
wxWindow if you import from the wxPython.wx module.</p>
|
||||
<p>A few notes about how all of this was accomplished might be
|
||||
interesting... SWIG is now run twice for each module that it is
|
||||
generating code for. The first time it outputs an XML representaion
|
||||
@@ -210,119 +227,77 @@ just fine.</p>
|
||||
</div>
|
||||
<div class="section" id="new-wx-dc-methods">
|
||||
<h1><a name="new-wx-dc-methods">New wx.DC Methods</a></h1>
|
||||
<p>Many of the Draw methods of wx.DC have alternate forms in C++ that take
|
||||
wxPoint or wxSize parameters (let's call these <em>Type A</em>) instead of
|
||||
the individual x, y, width, height, etc. parameters (and we'll call
|
||||
these <em>Type B</em>). In the rest of the library I normally made the <em>Type
|
||||
A</em> forms of the methods be the default method with the "normal" name,
|
||||
and had renamed the <em>Type B</em> forms of the methods to some similar
|
||||
name. For example in wx.Window we have these Python methods:</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> In wxPython 2.5.1.5 there was a new
|
||||
implementation of the wx.DC Draw and other methods that broke
|
||||
backwards compatibility in the name of consistency. That change has
|
||||
been reverted and the wx.DC Draw methods with 2.4 compatible
|
||||
signatures have been restored. In addition a new set of methods have
|
||||
been added that take wx.Point and/or wx.Size parameters instead of
|
||||
separate integer parameters. The Draw and etc. methods now available
|
||||
in the wx.DC class are:</p>
|
||||
<pre class="literal-block">
|
||||
SetSize(size) # Type A
|
||||
SetSizeWH(width, height) # Type B
|
||||
FloodFill(self, x, y, colour, style = wx.FLOOD_SURFACE)
|
||||
FoodFillPoint(self, pt, colour, style = wx.FLOOD_SURFACE)
|
||||
|
||||
GetPixel(self, x,y)
|
||||
GetPixelPoint(self, pt)
|
||||
|
||||
DrawLine(self, x1, y1, x2, y2)
|
||||
DrawLinePoint(self, pt1, pt2)
|
||||
|
||||
CrossHair(self, x, y)
|
||||
CrossHairPoint(self, pt)
|
||||
|
||||
DrawArc(self, x1, y1, x2, y2, xc, yc)
|
||||
DrawArcPoint(self, pt1, pt2, centre)
|
||||
|
||||
DrawCheckMark(self, x, y, width, height)
|
||||
DrawCheckMarkRect(self, rect)
|
||||
|
||||
DrawEllipticArc(self, x, y, w, h, sa, ea)
|
||||
DrawEllipticArcPointSize(self, pt, sz, sa, ea)
|
||||
|
||||
DrawPoint(self, x, y)
|
||||
DrawPointPoint(self, pt)
|
||||
|
||||
DrawRectangle(self, x, y, width, height)
|
||||
DrawRectangleRect(self, rect)
|
||||
DrawRectanglePointSize(self, pt, sz)
|
||||
|
||||
DrawRoundedRectangle(self, x, y, width, height, radius)
|
||||
DrawRoundedRectangleRect(self, r, radius)
|
||||
DrawRoundedRectanglePointSize(self, pt, sz, radius)
|
||||
|
||||
DrawCircle(self, x, y, radius)
|
||||
DrawCirclePoint(self, pt, radius)
|
||||
|
||||
DrawEllipse(self, x, y, width, height)
|
||||
DrawEllipseRect(self, rect)
|
||||
DrawEllipsePointSize(self, pt, sz)
|
||||
|
||||
DrawIcon(self, icon, x, y)
|
||||
DrawIconPoint(self, icon, pt)
|
||||
|
||||
DrawBitmap(self, bmp, x, y, useMask = False)
|
||||
DrawBitmapPoint(self, bmp, pt, useMask = False)
|
||||
|
||||
DrawText(self, text, x, y)
|
||||
DrawTextPoint(self, text, pt)
|
||||
|
||||
DrawRotatedText(self, text, x, y, angle)
|
||||
DrawRotatedTextPoint(self, text, pt, angle)
|
||||
|
||||
bool Blit(self, xdest, ydest, width, height, sourceDC, xsrc, ysrc,
|
||||
rop = wx.COPY, useMask = False, xsrcMask = -1, ysrcMask = -1)
|
||||
BlitPointSize(self, destPt, sz, sourceDC, srcPt, rop = wx.COPY,
|
||||
useMask = False, srcPtMask = wxDefaultPosition)
|
||||
|
||||
|
||||
SetClippingRegion(self, x, y, width, height)
|
||||
SetClippingRegionPointSize(self, pt, sz)
|
||||
SetClippingRegionAsRegion(self, region)
|
||||
SetClippingRect(self, rect)
|
||||
</pre>
|
||||
<p>For various reasons the new <em>Type A</em> methods in wx.DC were never added
|
||||
and the existing <em>Type B</em> methods were never renamed. Now that lots
|
||||
of other things are also changing in wxPython it has been decided that
|
||||
it is a good time to also do the method renaming in wx.DC too in order
|
||||
to be consistent with the rest of the library. The methods in wx.DC
|
||||
that are affected are listed here:</p>
|
||||
<pre class="literal-block">
|
||||
FloodFillXY(x, y, colour, style = wx.FLOOD_SURFACE)
|
||||
FloodFill(point, colour, style = wx.FLOOD_SURFACE)
|
||||
|
||||
GetPixelXY(x, y)
|
||||
GetPixel(point)
|
||||
|
||||
DrawLineXY(x1, y1, x2, y2)
|
||||
DrawLine(point1, point2)
|
||||
|
||||
CrossHairXY(x, y)
|
||||
CrossHair(point)
|
||||
|
||||
DrawArcXY(x1, y1, x2, y2, xc, yc)
|
||||
DrawArc(point1, point2, center)
|
||||
|
||||
DrawCheckMarkXY(x, y, width, height)
|
||||
DrawCheckMark(rect)
|
||||
|
||||
DrawEllipticArcXY(x, y, w, h, start_angle, end_angle)
|
||||
DrawEllipticArc(point, size, start_angle, end_angle)
|
||||
|
||||
DrawPointXY(x, y)
|
||||
DrawPoint(point)
|
||||
|
||||
DrawRectangleXY(x, y, width, height)
|
||||
DrawRectangle(point, size)
|
||||
DrawRectangleRect(rect)
|
||||
|
||||
DrawRoundedRectangleXY(x, y, width, height, radius)
|
||||
DrawRoundedRectangle(point, size, radius)
|
||||
DrawRoundedRectangleRect(rect, radius)
|
||||
|
||||
DrawCircleXY(x, y, radius)
|
||||
DrawCircle(point, radius)
|
||||
|
||||
DrawEllipseXY(x, y, width, height)
|
||||
DrawEllipse(point, size)
|
||||
DrawEllipseRect(rect)
|
||||
|
||||
DrawIconXY(icon, x, y)
|
||||
DrawIcon(icon, point)
|
||||
|
||||
DrawBitmapXY(bmp, x, y, useMask = FALSE)
|
||||
DrawBitmap(bmp, point, useMask = FALSE)
|
||||
|
||||
DrawTextXY(text, x, y)
|
||||
DrawText(text, point)
|
||||
|
||||
DrawRotatedTextXY(text, x, y, angle)
|
||||
DrawRotatedText(text, point, angle)
|
||||
|
||||
|
||||
BlitXY(xdest, ydest, width, height, sourceDC, xsrc, ysrc,
|
||||
rop = wxCOPY, useMask = FALSE, xsrcMask = -1, ysrcMask = -1)
|
||||
Blit(destPt, size, sourceDC, srcPt,
|
||||
rop = wxCOPY, useMask = FALSE, srcPtMask = wx.DefaultPosition)
|
||||
|
||||
SetClippingRegionXY(x, y, width, height)
|
||||
SetClippingRegion(point, size)
|
||||
SetClippingRect(rect)
|
||||
SetClippingRegionAsRegion(region);
|
||||
</pre>
|
||||
<p>If you have code that draws on a DC and you are using the new wx
|
||||
namespace then you <strong>will</strong> get errors because of these changes, but
|
||||
it should be easy to fix the code. You can either change the name of
|
||||
the <em>Type B</em> method called to the names shown above, or just add
|
||||
parentheses around the parameters as needed to turn them into tuples
|
||||
and let the SWIG typemaps turn them into the wx.Point or wx.Size
|
||||
object that is expected. Then you will be calling the new <em>Type A</em>
|
||||
method. For example, if you had this code before:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle(x, y, width, height)
|
||||
</pre>
|
||||
<p>You could either continue to use the <em>Type B</em> method by changing the
|
||||
name to DrawRectangleXY, or just change it to the new <em>Type A</em> by
|
||||
adding some parentheses like this:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle((x, y), (width, height))
|
||||
</pre>
|
||||
<p>Or if you were already using a point and size like this:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle(p.x, p.y, s.width, s.height)
|
||||
</pre>
|
||||
<p>Then you can just simplify it like this:</p>
|
||||
<pre class="literal-block">
|
||||
dc.DrawRectangle(p, s)
|
||||
</pre>
|
||||
<p>Now before you start yelling and screaming at me for breaking all your
|
||||
code, take note that up above I said, "...using the new wx namespace..."
|
||||
That's because if you are still importing from wxPython.wx then there
|
||||
are some classes defined there with Draw and etc. methods that have
|
||||
2.4 compatible signatures. However if/when the old wxPython.wx
|
||||
namespace is removed then these classes will be removed too so you
|
||||
should plan on migrating to the new namespace and new DC Draw methods
|
||||
before that time.</p>
|
||||
</div>
|
||||
<div class="section" id="building-extending-and-embedding-wxpython">
|
||||
<h1><a name="building-extending-and-embedding-wxpython">Building, Extending and Embedding wxPython</a></h1>
|
||||
@@ -384,15 +359,49 @@ class MyDialog(wx.Dialog):
|
||||
<h1><a name="sizers">Sizers</a></h1>
|
||||
<p>The hack allowing the old "option" keyword parameter has been removed.
|
||||
If you use keyword args with w.xSizer Add, Insert, or Prepend methods
|
||||
then you will need to use the <tt class="literal"><span class="pre">proportion</span></tt> name instead of <tt class="literal"><span class="pre">option</span></tt>.</p>
|
||||
then you will need to use the <tt class="literal"><span class="pre">proportion</span></tt> name instead of
|
||||
<tt class="literal"><span class="pre">option</span></tt>. (The <tt class="literal"><span class="pre">proportion</span></tt> keyword was also allowed in 2.4.2.4.)</p>
|
||||
<p>When adding a spacer to a sizer you now need to use a wx.Size or a
|
||||
2-integer sequence instead of separate width and height parameters.</p>
|
||||
2-integer sequence instead of separate width and height parameters.
|
||||
This was optionally allowed in 2.4, but now it is required. This
|
||||
allows for more consistency in how you add the various types of items
|
||||
to a sizer. The first parameter defines the item (instead of the
|
||||
possibily first two, depending on if you are doing a spacer or not,)
|
||||
and that item can either be a window, a sizer or a spacer (which can
|
||||
be a sequence or a wx.Size.) Removing the option for separate width
|
||||
and height parameters greatly simplified the wrapper code.</p>
|
||||
<p>The wx.GridBagSizer class (very similar to the RowColSizer in the
|
||||
library) has been added to C++ and wrapped for wxPython. It can also
|
||||
be used from XRC.</p>
|
||||
<p>You should not use AddWindow, AddSizer, AddSpacer (and similar for
|
||||
Insert, Prepend, and etc.) methods any longer. Just use Add and the
|
||||
wrappers will figure out what to do.</p>
|
||||
wrappers will figure out what to do. <strong>[Changed in 2.5.2.0]</strong>
|
||||
AddWindow, AddSize, AddSpacer and etc. will now issue a
|
||||
DeprecationWarning.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> wx.ADJUST_MINSIZE is now the default
|
||||
behaviour for window items in sizers. This means that the item's
|
||||
GetMinSize and/or GetBestSize will be called when calculating layout
|
||||
and the return value from that will be used for the minimum size used
|
||||
by the sizer. The wx.FIXED_MINSIZE flag was added that will cause the
|
||||
sizer to use the old behaviour in that it will <em>not</em> call the window's
|
||||
methods to determine the new best size, instead the minsize that the
|
||||
window had when added to the sizer (or the size the window was created
|
||||
with) will always be used.</p>
|
||||
<p>Related to the above, when controls and some other window types are
|
||||
created either the size passed to the constructor, or their "best
|
||||
size" if an explicit size was not passed in, is set as the window's
|
||||
minimal size. For non top-level windows that hasn't meant much in the
|
||||
past, but now the sizers are sensitive to the window's minimal size.
|
||||
The key point to understand here is that it is no longer the window's
|
||||
size it has when added to the sizer that matters, but its minimal
|
||||
size. So you might have some issues to iron out if you create a
|
||||
control without a size and then set its size to something before
|
||||
adding it to the sizer. Since it's minimal size is probably not the
|
||||
size you set then the sizer will appear to be misbehaving. The fix is
|
||||
to either set the size when calling the window's constructor, or to
|
||||
reset the min size by calling SetSizeHints. You can call SetSizeHints
|
||||
at anytime to change the minsize of a window, just call the sizer's
|
||||
Layout method to redistribute the controls as needed.</p>
|
||||
</div>
|
||||
<div class="section" id="platforminfo">
|
||||
<h1><a name="platforminfo">PlatformInfo</a></h1>
|
||||
@@ -517,22 +526,141 @@ output appended as a comment to the modules produced by the
|
||||
genaxmodule tool. Beyond that you'll need to consult the docs
|
||||
provided by the makers of the ActiveX control that you are using.</p>
|
||||
</div>
|
||||
<div class="section" id="other-stuff">
|
||||
<h1><a name="other-stuff">Other Stuff</a></h1>
|
||||
<div class="section" id="png-images">
|
||||
<h1><a name="png-images">PNG Images</a></h1>
|
||||
<p>Prior to 2.5 the PNG image handler would convert all alpha channel
|
||||
information to a mask when the image was loaded. Pixels that were
|
||||
more than halfway transparent would be made fully transparent by the
|
||||
mask and the rest would be made fully opaque.</p>
|
||||
<p>In 2.5 the image handler has been updated to preserve the alpha
|
||||
channel and will now only create a mask when all the pixels in the
|
||||
image are either fully transparent or fully opaque. In addition, the
|
||||
wx.DC.DrawBitmap and wx.DC.Blit methods are able to correctly blend
|
||||
the pixels in the image with partially transparent alpha values.
|
||||
(Currently only on MSW and Mac, if anybody knows how to do it for GTK
|
||||
then please submit a patch!)</p>
|
||||
<p>If you are using a PNG with an alpha channel but you need to have a
|
||||
wx.Mask like you automatically got in 2.4 then you can do one of the
|
||||
following:</p>
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>Edit the image and make all the partially transparent pixels be
|
||||
fully transparent.</li>
|
||||
<li>Use a different image type.</li>
|
||||
<li>Set a mask based on colour after you load the image.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="ogl-is-dead-long-live-ogl">
|
||||
<h1><a name="ogl-is-dead-long-live-ogl">OGL is dead! LONG LIVE OGL!</a></h1>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong></p>
|
||||
<p>The wx.ogl module has been deprecated in favor of the new Python port
|
||||
of the OGL library located at wx.lib.ogl contributed by Pierre Hj<48>lm.
|
||||
This will hopefully greatly extend the life of OGL within wxPython by
|
||||
making it more easily maintainable and less prone to getting rusty as
|
||||
there seems to be less and less interest in maintaining the C++
|
||||
version.</p>
|
||||
<p>There are only a few known compatibility issues at this time. First
|
||||
is the location of OGL. The deprecated version is located in the
|
||||
wx.ogl module, and the new version is in the wx.lib.ogl package. So
|
||||
this just means that to start using the new version you need to adjust
|
||||
your imports. So if your code currently has something like this:</p>
|
||||
<pre class="literal-block">
|
||||
import wx
|
||||
import wx.ogl as ogl
|
||||
</pre>
|
||||
<p>Then just change it to this:</p>
|
||||
<pre class="literal-block">
|
||||
import wx
|
||||
import wx.lib.ogl as ogl
|
||||
</pre>
|
||||
<p>The other compatibility issue deals with removing a wart in the
|
||||
original API that was necessary in order to allow overloaded methods
|
||||
in derived classes to call the same method in the base class when
|
||||
using the old SWIG. Instead dedaling with the wart you can now just
|
||||
call the base class method like you woudl for any other Python class.
|
||||
For example, if you had to do something like this previously:</p>
|
||||
<pre class="literal-block">
|
||||
class MyDividedShape(ogl.DividedShape):
|
||||
...
|
||||
def OnSizingEndDragLeft(self, pt, x, y, keys, attch):
|
||||
self.base_OnSizingEndDragLeft(pt, x, y, keys, attch)
|
||||
...
|
||||
</pre>
|
||||
<p>You will need to change it to be like this:</p>
|
||||
<pre class="literal-block">
|
||||
class MyDividedShape(ogl.DividedShape):
|
||||
...
|
||||
def OnSizingEndDragLeft(self, pt, x, y, keys, attch):
|
||||
ogl.DividedShape.OnSizingEndDragLeft(self, pt, x, y, keys, attch)
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="obsolete-modules">
|
||||
<h1><a name="obsolete-modules">Obsolete Modules</a></h1>
|
||||
<p>Instead of over a dozen separate extension modules linked together
|
||||
into a single extension module, the "core" module is now just a few
|
||||
extensions that are linked independently, and then merged together
|
||||
later into the main namespace via Python code.</p>
|
||||
<p>Because of the above and also because of the way the new SWIG works,
|
||||
the "internal" module names have changed, but you shouldn't have been
|
||||
using them anyway so it shouldn't bother you. ;-)</p>
|
||||
using them anyway so it shouldn't bother you. ;-) In case you were
|
||||
erroneously using them in 2.4, here are the internal extension modules
|
||||
no longer exist:</p>
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>clip_dnd</li>
|
||||
<li>cmndlgs</li>
|
||||
<li>controls</li>
|
||||
<li>controls2</li>
|
||||
<li>events</li>
|
||||
<li>filesys</li>
|
||||
<li>fonts</li>
|
||||
<li>frames</li>
|
||||
<li>gdi</li>
|
||||
<li>image</li>
|
||||
<li>mdi</li>
|
||||
<li>misc</li>
|
||||
<li>misc2</li>
|
||||
<li>printfw</li>
|
||||
<li>sizers</li>
|
||||
<li>stattool</li>
|
||||
<li>streams</li>
|
||||
<li>utils</li>
|
||||
<li>windows</li>
|
||||
<li>windows2</li>
|
||||
<li>windows3</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p>They have been replaced by the following, but please remember that
|
||||
these are just "implementation details" and you should really be using
|
||||
the objects in these modules only via the wx or wxPython.wx packages:</p>
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>_core</li>
|
||||
<li>_gdi</li>
|
||||
<li>_windows</li>
|
||||
<li>_controls</li>
|
||||
<li>_misc</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p>The help module no longer exists and the classes therein are now part
|
||||
of the core module imported with wxPython.wx or the wx package.</p>
|
||||
</div>
|
||||
<div class="section" id="other-stuff">
|
||||
<h1><a name="other-stuff">Other Stuff</a></h1>
|
||||
<p>wxPyDefaultPosition and wxPyDefaultSize are gone. Use the
|
||||
wxDefaultPosition and wxDefaultSize objects instead.</p>
|
||||
<p>Similarly, the wxSystemSettings backwards compatibiility aliases for
|
||||
GetSystemColour, GetSystemFont and GetSystemMetric have also gone into
|
||||
the bit-bucket. Use GetColour, GetFont and GetMetric instead.</p>
|
||||
<p>Use the Python True/False constants instead of the true, TRUE, false,
|
||||
FALSE that used to be provided with wxPython.</p>
|
||||
<p>Use None instead of the ancient and should have been removed a long
|
||||
time ago wx.NULL alias.</p>
|
||||
<p>wx.TreeCtrl.GetFirstChild no longer needs to be passed the cookie
|
||||
variable as the 2nd parameter. It still returns it though, for use
|
||||
with GetNextChild.</p>
|
||||
<p>The wx.NO_FULL_REPAINT_ON_RESIZE style is now the default style for
|
||||
all windows. The name still exists for compatibility, but it is set
|
||||
to zero. If you want to disable the setting (so it matches the old
|
||||
@@ -546,22 +674,22 @@ wxPyTypeCast at all.</p>
|
||||
there are compatibility aliases for much of the above items.</p>
|
||||
<p>The wxWave class has been renamed to wxSound, and now has a slightly
|
||||
different API.</p>
|
||||
<p>wx.TaskbarIcon works on wxGTK-based platforms now, however you have to
|
||||
manage it a little bit more than you did before. Basically, the app
|
||||
will treat it like a top-level frame in that if the wx.TaskBarIcon
|
||||
still exists when all the frames are closed then the app will still
|
||||
not exit. You need to ensure that the wx.TaskBarIcon is destroyed
|
||||
when your last Frame is closed. For wxPython apps it is usually
|
||||
enough if your main frame object holds the only reference to the
|
||||
wx.TaskBarIcon, then when the frame is closed Python reference
|
||||
counting takes care of the rest.</p>
|
||||
<p>wx.TaskbarIcon works on wxGTK-based platforms (for some window
|
||||
managers,) however you have to manage it a little bit more than you
|
||||
did before. Basically, the app will treat it like a top-level frame
|
||||
in that if the wx.TaskBarIcon still exists when all the frames are
|
||||
closed then the app will still not exit. You need to ensure that the
|
||||
wx.TaskBarIcon is destroyed when your last Frame is closed. For
|
||||
wxPython apps it is usually enough if your main frame object holds the
|
||||
only reference to the wx.TaskBarIcon, then when the frame is closed
|
||||
Python reference counting takes care of the rest.</p>
|
||||
<p>Before Python 2.3 it was possible to pass a floating point object as a
|
||||
parameter to a function that expected an integer, and the
|
||||
PyArg_ParseTuple family of functions would automatically convert to
|
||||
integer by truncating the fractional portion of the number. With
|
||||
Python 2.3 that behavior was deprecated and a deprecation warning is
|
||||
raised when you pass a floating point value, (for example, calling
|
||||
wx.DC.DrawLineXY with floats for the position and size,) and lots of
|
||||
wx.DC.DrawLine with floats for the position and size,) and lots of
|
||||
developers using wxPython had to scramble to change their code to call
|
||||
int() before calling wxPython methods. Recent changes in SWIG have
|
||||
moved the conversion out of PyArg_ParseTuple to custom code that SWIG
|
||||
@@ -575,6 +703,13 @@ functions in wxPython for parameters that are expecting an integer.
|
||||
If the object is not already an integer then it will be asked to
|
||||
convert itself to one. A similar conversion fragment is in place for
|
||||
parameters that expect floating point values.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> The MaskedEditCtrl modules have been moved
|
||||
to their own sub-package, wx.lib.masked. See the docstrings and demo
|
||||
for changes in capabilities, usage, etc.</p>
|
||||
<p><strong>[Changed in 2.5.2.0]</strong> wx.MaskColour constructor has been deprecated
|
||||
and will raise a DeprecationWarning if used. The main wx.Mask
|
||||
constructor has been modified to be compatible with wx.MaskColour so
|
||||
you should use it instead.</p>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
|
||||
Reference in New Issue
Block a user