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.
(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
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
+
+
The wx Namespace
----------------
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.
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.
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.
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.
projects / wxWidgets.git / blobdiff