+<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. ;-) In case you were
+erroneously using them in 2.4, here are the internal extension modules
+that 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">
+<h1><a id="wx-taskbaricon" name="wx-taskbaricon">wx.TaskBarIcon</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>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
+the application's icon on the dock and when you right click on it the
+app's default popup menu is merged with the wx.TaskBarIcon's menu.
+Because of how it is implemented on the Mac using the Dock most of the
+TaskBarIcon events will _not_ be emitted on that platform, but since
+98% of the time you simply want to display an icon and have a popup
+menu it shouldn't be much of a problem. You can still use the other
+events on the other platforms, you'll just want to be sure that you
+can do everything you want via the menu too.</p>
+<p>Since popping up a menu is the most common thing to do with a
+TaskBarIcon the class has some new built in functionality to
+facilitate that. To use the TaskBarIcon in this new way, simply
+derive a new class from TaskBarIcon and implement a CreatePopupMenu
+method that creates and returns the menu. That's all there is to it,
+besides binding event handlers for the menu items of course. Take a
+look at the DemoTaskBarIcon class in the demo/Main.py module for an
+example.</p>
+<p><strong>NOTE</strong>: Unfortunately due to being able to support virtualizing
+CreatePopupMenu the C++ TaskBarIcon instance now holds a reference to
+the Python instance, and so you will need to explicitly Destroy() your
+TaskBarIcon instance when you are done with it. (Like you do with
+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.</p>
+</div>
+<div class="section">
+<h1><a id="version-number-change" name="version-number-change">Version Number Change</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<p>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.
+Please check for the presence of "unicode" in the <cite>wx.PlatformInfo</cite>
+tuple instead. (This tuple of strings has been available since the
+first 2.5 version.) For example:</p>
+<pre class="literal-block">
+if "unicode" in wx.PlatformInfo:
+ # do whatever
+ ...
+</pre>
+</div>
+<div class="section">
+<h1><a id="multi-version-installs" name="multi-version-installs">Multi-Version Installs</a></h1>
+<p><strong>[Changed in 2.5.3.x]</strong></p>
+<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
+directly in site-packages. This is done to help facilitate having
+multiple versions of wxPython installed side-by-side. Why would you
+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
+own development with. Or perhaps you want to be able to test your app
+with several different versions of wxPython to ensure compatibility.
+Before everyone panics, rest asured that if you only install one
+version of wxPython then you should notice no difference in how things
+work.</p>
+<p>In addition to installing wxPython into a "versioned" subdirectory of
+site-packages, a file named <cite>wx.pth</cite> is optionally installed that will
+contain the name of the versioned subdirectory. This will cause that
+subdirectory to be automatically added to the sys.path and so doing an
+"import wx" will find the package in the subdirectory like it would
+have if it was still located directly in site-packages. I say
+"optionally" above because that is how you can control which install
+of wxPython is the default one. Which ever version installs the
+wx.pth file will be the one that is imported with a plain "import wx"
+statement. Of course you can always manipulate that by editing the
+wx.pth file, or by setting PYTHONPATH in the environment, or by the
+method described in the next paragraph.</p>
+<p>Finally, a new module named wxversion.py is installed to the
+site-packages directory. It can be used to manipulate the sys.path at
+runtime so your applications can select which version of wxPython they
+would like to to have imported. You use it like this:</p>
+<pre class="literal-block">
+import wxversion
+wxversion.select("2.4")
+import wx
+</pre>
+<p>Then even though a 2.5 version of wxPython may be the default the
+application that does the above the first time that wx is imported
+will actually get a 2.4 version. <strong>NOTE:</strong> There isn't actually a 2.4
+version of wxPython that supports this, but there will be.</p>
+<p>Please see this wiki page for more details, HowTo's and FAQ's:
+<a class="reference" href="http://wiki.wxpython.org/index.cgi/MultiVersionInstalls">http://wiki.wxpython.org/index.cgi/MultiVersionInstalls</a></p>
+</div>
+<div class="section">
+<h1><a id="miscellaneous-stuff" name="miscellaneous-stuff">Miscellaneous 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
+default) then you need to use the new wx.FULL_REPAINT_ON_RESIZE style
+flag otherwise only the freshly exposed areas of the window will be
+refreshed.</p>
+<p>wxPyTypeCast has been removed. Since we've had the OOR (Original
+Object Return) for a couple years now there should be no need to use
+wxPyTypeCast at all.</p>
+<p>If you use the old wxPython package and wxPython.wx namespace then
+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>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.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
+generates. Since the default conversion fragment was a little too
+strict and didn't generate a very meaningful exception when it failed,
+I decided to use a custom fragment instead, and it turned out that
+it's very easy to allow floats to be converted again just like they
+used to be. So, in a nutshell, any numeric type that can be
+converted to an integer is now legal to be passed to SWIG wrapped
+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.x]</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.x]</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>
+<p><strong>[Changed in 2.5.2.x]</strong> In wx.TextCtrls that have the
+wx.TE_PROCESS_TAB style the TAB key will be treated like an ordinary
+character and will not cause any tab traversal navigation at all. If
+you use this style but would still like to have the normal tab
+traversal take place then you should send your own
+wx.NavigationKeyEvent from the wx.EVT_KEY_DOWN handler. There is a
+new Navigate method in the wx.Window class to help send the event and
+it is used something like this:</p>
+<pre class="literal-block">
+flags = wx.NavigationKeyEvent.IsForward
+if event.ShiftDown():
+ flags = wx.NavigationKeyEvent.IsBackward
+if event.ControlDown():
+ flags |= wx.NavigationKeyEvent.WinChange
+self.Navigate(flags)
+</pre>
projects / wxWidgets.git / blobdiff