X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/4942342c3e1788e1b92bf9e3c522cfa8a8a5c905..b887061dd1d7b3a49a111513309b1bb5c308537c:/wxPython/docs/MigrationGuide.txt diff --git a/wxPython/docs/MigrationGuide.txt b/wxPython/docs/MigrationGuide.txt index bb274019e0..c469b3808f 100644 --- a/wxPython/docs/MigrationGuide.txt +++ b/wxPython/docs/MigrationGuide.txt @@ -9,12 +9,27 @@ 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. + +.. _here: http://www.wxwindows.org/name.htm + +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 +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 wxWindows and the underlying gui toolkit are **not** +such that wxWidgets and the underlying gui toolkit are **not** initialized until the wx.App object is created (but before wx.App.OnInit is called.) This was required because of some changes that were made to the C++ wxApp class. @@ -28,7 +43,7 @@ potential problems are that the C++ side of the "stock-objects" (wx.BLUE_PEN, wx.TheColourDatabase, etc.) are not initialized until the wx.App object is created, so you should not use them until after you have created your wx.App object. If you do then an exception will -be raised telling you that the C++ object has not bene initialized +be raised telling you that the C++ object has not been initialized yet. Also, you will probably not be able to do any kind of GUI or bitmap @@ -107,11 +122,32 @@ Some examples of its use:: self.Bind(wx.EVT_SIZE, self.OnSize) self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton) - self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT) - -I hope to be able to remove the need for using IDs even for menu -events too... + self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT) + + +The wx.Menu methods that add items to a wx.Menu have been modified +such that they return a reference to the wx.MenuItem that was created. +Additionally menu items and toolbar items have been modified to +automatically generate a new ID if -1 is given, similar to using -1 +with window classess. This means that you can create menu or toolbar +items and event bindings without having to predefine a unique menu ID, +although you still can use IDs just like before if you want. For +example, these are all equivallent other than their specific ID +values:: + 1. + item = menu.Append(-1, "E&xit", "Terminate the App") + self.Bind(wx.EVT_MENU, self.OnExit, item) + + 2. + item = menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App") + self.Bind(wx.EVT_MENU, self.OnExit, item) + + 3. + menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App") + self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT) + + 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 @@ -132,6 +168,8 @@ number of IDs that are needed to be passed to Connect. + + The wx Namespace ---------------- @@ -312,7 +350,7 @@ 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 plam on migrating to the new namespace and new DC Draw methods +should plan on migrating to the new namespace and new DC Draw methods before that time. @@ -361,10 +399,9 @@ For example:: Sizers ------ -The hack allowing the old "option" keyword parameter has been -removed. If you use keyworkd args with wxSizer Add, Insert, or -Prepend then you will need to use the "proportion" name instead of -"option". +The hack allowing the old "option" keyword parameter has been removed. +If you use keyworkd args with wxSizer Add, Insert, or Prepend methods +then you will need to use the "proportion" name instead of "option". When adding a spacer to a sizer you now need to use a wxSize or a 2-integer sequence instead of separate width and height parameters. @@ -387,13 +424,12 @@ 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. -Because of the above, the "internal" module names have changed, but -you shouldn't have been using them anyway so it shouldn't bother -you. ;-) +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. ;-) -The wxPython.help module no longer exists and the classes therein are -now part of the core module imported with wxPython.wx or the wx -package. +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. wxPyDefaultPosition and wxPyDefaultSize are gone. Use the wxDefaultPosition and wxDefaultSize objects instead. @@ -414,3 +450,8 @@ 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. +If you use the old wxPython package and wxPython.wx namespace then +there are compatibility aliases for much of the above items. + +The wxWave class has been renamed to wxSound, and now has a slightly +different API.