fix typos
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@30245 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -358,7 +358,7 @@ class MyDialog(wx.Dialog):
|
|||||||
<div class="section" id="sizers">
|
<div class="section" id="sizers">
|
||||||
<h1><a name="sizers">Sizers</a></h1>
|
<h1><a name="sizers">Sizers</a></h1>
|
||||||
<p>The hack allowing the old "option" keyword parameter has been removed.
|
<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
|
If you use keyword args with wx.Sizer Add, Insert, or Prepend methods
|
||||||
then you will need to use the <tt class="literal"><span class="pre">proportion</span></tt> name instead of
|
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>
|
<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
|
<p>When adding a spacer to a sizer you now need to use a wx.Size or a
|
||||||
@@ -393,7 +393,7 @@ flag then when layout was calculated the item's <tt class="literal"><span class=
|
|||||||
would be used to reset the minimal size that the sizer used.</li>
|
would be used to reset the minimal size that the sizer used.</li>
|
||||||
</ul>
|
</ul>
|
||||||
</blockquote>
|
</blockquote>
|
||||||
<p>The main thrust of the new Sizer changes was to make behaviour like
|
<p>The main thrust of the new Sizer changes was to make behavior like
|
||||||
<tt class="literal"><span class="pre">wx.ADJUST_MINSIZE</span></tt> be the default, and also to push the tracking of
|
<tt class="literal"><span class="pre">wx.ADJUST_MINSIZE</span></tt> be the default, and also to push the tracking of
|
||||||
the minimal size to the window itself (since it knows its own needs)
|
the minimal size to the window itself (since it knows its own needs)
|
||||||
instead of having the sizer take care of it. Consequently these
|
instead of having the sizer take care of it. Consequently these
|
||||||
@@ -401,7 +401,7 @@ changes were made:</p>
|
|||||||
<blockquote>
|
<blockquote>
|
||||||
<ul class="simple">
|
<ul class="simple">
|
||||||
<li>The <tt class="literal"><span class="pre">wx.FIXED_MINSIZE</span></tt> flag was added to allow for the old
|
<li>The <tt class="literal"><span class="pre">wx.FIXED_MINSIZE</span></tt> flag was added to allow for the old
|
||||||
behaviour. When this flag is used the size a window has when
|
behavior. When this flag is used the size a window has when
|
||||||
added to the sizer will be treated as its minimal size and it
|
added to the sizer will be treated as its minimal size and it
|
||||||
will not be readjusted on each layout.</li>
|
will not be readjusted on each layout.</li>
|
||||||
<li>The min size stored in <tt class="literal"><span class="pre">wx.Window</span></tt> and settable with
|
<li>The min size stored in <tt class="literal"><span class="pre">wx.Window</span></tt> and settable with
|
||||||
@@ -603,9 +603,7 @@ mask and the rest would be made fully opaque.</p>
|
|||||||
channel and will now only create a mask when all the pixels in the
|
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
|
image are either fully transparent or fully opaque. In addition, the
|
||||||
wx.DC.DrawBitmap and wx.DC.Blit methods are able to correctly blend
|
wx.DC.DrawBitmap and wx.DC.Blit methods are able to correctly blend
|
||||||
the pixels in the image with partially transparent alpha values.
|
the pixels in the image with partially transparent alpha values.</p>
|
||||||
(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
|
<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
|
wx.Mask like you automatically got in 2.4 then you can do one of the
|
||||||
following:</p>
|
following:</p>
|
||||||
@@ -761,9 +759,9 @@ if "unicode" in wx.PlatformInfo:
|
|||||||
<div class="section" id="multi-version-installs">
|
<div class="section" id="multi-version-installs">
|
||||||
<h1><a name="multi-version-installs">Multi-Version Installs</a></h1>
|
<h1><a name="multi-version-installs">Multi-Version Installs</a></h1>
|
||||||
<p><strong>[Changed in 2.5.3.x]</strong></p>
|
<p><strong>[Changed in 2.5.3.x]</strong></p>
|
||||||
<p>Starting with 2.5.3.0 the wx and wxPython pacakge directories will be
|
<p>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
|
installed in a subdirectory of the site-packages directory, instead of
|
||||||
directly in site-pacakges. This is done to help facilitate having
|
directly in site-packages. This is done to help facilitate having
|
||||||
multiple versions of wxPython installed side-by-side. Why would you
|
multiple versions of wxPython installed side-by-side. Why would you
|
||||||
want to do this? One possible scenario is you have an app that
|
want to do this? One possible scenario is you have an app that
|
||||||
requires wxPython 2.4 but you want to use the newest 2.5 to do your
|
requires wxPython 2.4 but you want to use the newest 2.5 to do your
|
||||||
@@ -785,7 +783,7 @@ statement. Of course you can always manipulate that by editing the
|
|||||||
wx.pth file, or by setting PYTHONPATH in the environment, or by the
|
wx.pth file, or by setting PYTHONPATH in the environment, or by the
|
||||||
method described in the next paragraph.</p>
|
method described in the next paragraph.</p>
|
||||||
<p>Finally, a new module named wxversion.py is installed to the
|
<p>Finally, a new module named wxversion.py is installed to the
|
||||||
site-pacakges directory. It can be used to manipulate the sys.path at
|
site-packages directory. It can be used to manipulate the sys.path at
|
||||||
runtime so your applications can select which version of wxPython they
|
runtime so your applications can select which version of wxPython they
|
||||||
would like to to have imported. You use it like this:</p>
|
would like to to have imported. You use it like this:</p>
|
||||||
<pre class="literal-block">
|
<pre class="literal-block">
|
||||||
|
@@ -403,7 +403,7 @@ Sizers
|
|||||||
------
|
------
|
||||||
|
|
||||||
The hack allowing the old "option" keyword parameter has been removed.
|
The hack allowing the old "option" keyword parameter has been removed.
|
||||||
If you use keyword args with w.xSizer Add, Insert, or Prepend methods
|
If you use keyword args with wx.Sizer Add, Insert, or Prepend methods
|
||||||
then you will need to use the ``proportion`` name instead of
|
then you will need to use the ``proportion`` name instead of
|
||||||
``option``. (The ``proportion`` keyword was also allowed in 2.4.2.4.)
|
``option``. (The ``proportion`` keyword was also allowed in 2.4.2.4.)
|
||||||
|
|
||||||
@@ -441,14 +441,14 @@ First a bit about how things used to work:
|
|||||||
flag then when layout was calculated the item's ``GetBestSize``
|
flag then when layout was calculated the item's ``GetBestSize``
|
||||||
would be used to reset the minimal size that the sizer used.
|
would be used to reset the minimal size that the sizer used.
|
||||||
|
|
||||||
The main thrust of the new Sizer changes was to make behaviour like
|
The main thrust of the new Sizer changes was to make behavior like
|
||||||
``wx.ADJUST_MINSIZE`` be the default, and also to push the tracking of
|
``wx.ADJUST_MINSIZE`` be the default, and also to push the tracking of
|
||||||
the minimal size to the window itself (since it knows its own needs)
|
the minimal size to the window itself (since it knows its own needs)
|
||||||
instead of having the sizer take care of it. Consequently these
|
instead of having the sizer take care of it. Consequently these
|
||||||
changes were made:
|
changes were made:
|
||||||
|
|
||||||
* The ``wx.FIXED_MINSIZE`` flag was added to allow for the old
|
* The ``wx.FIXED_MINSIZE`` flag was added to allow for the old
|
||||||
behaviour. When this flag is used the size a window has when
|
behavior. When this flag is used the size a window has when
|
||||||
added to the sizer will be treated as its minimal size and it
|
added to the sizer will be treated as its minimal size and it
|
||||||
will not be readjusted on each layout.
|
will not be readjusted on each layout.
|
||||||
|
|
||||||
@@ -843,9 +843,9 @@ Multi-Version Installs
|
|||||||
|
|
||||||
**[Changed in 2.5.3.x]**
|
**[Changed in 2.5.3.x]**
|
||||||
|
|
||||||
Starting with 2.5.3.0 the wx and wxPython pacakge directories will be
|
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
|
installed in a subdirectory of the site-packages directory, instead of
|
||||||
directly in site-pacakges. This is done to help facilitate having
|
directly in site-packages. This is done to help facilitate having
|
||||||
multiple versions of wxPython installed side-by-side. Why would you
|
multiple versions of wxPython installed side-by-side. Why would you
|
||||||
want to do this? One possible scenario is you have an app that
|
want to do this? One possible scenario is you have an app that
|
||||||
requires wxPython 2.4 but you want to use the newest 2.5 to do your
|
requires wxPython 2.4 but you want to use the newest 2.5 to do your
|
||||||
@@ -869,7 +869,7 @@ wx.pth file, or by setting PYTHONPATH in the environment, or by the
|
|||||||
method described in the next paragraph.
|
method described in the next paragraph.
|
||||||
|
|
||||||
Finally, a new module named wxversion.py is installed to the
|
Finally, a new module named wxversion.py is installed to the
|
||||||
site-pacakges directory. It can be used to manipulate the sys.path at
|
site-packages directory. It can be used to manipulate the sys.path at
|
||||||
runtime so your applications can select which version of wxPython they
|
runtime so your applications can select which version of wxPython they
|
||||||
would like to to have imported. You use it like this::
|
would like to to have imported. You use it like this::
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user