1 CHANGES.txt for wxPython
3 ----------------------------------------------------------------------
7 Updated wxMVCTree and added a demo for it, also fixed layout on GTK
8 and some flicker problems.
10 Added a wrapper class for the Visualization ToolKit (or VTK) in the
11 wxPython.lib.vtk module. (http://www.kitware.com/)
13 Fixed wxTreeCtrl.SetItemImage and GetItemImage to recognise the new
16 Added wxPython.lib.spashscreen from Mike Fletcher.
18 Added wxPython.lib.filebrowsebutton also from Mike Fletcher.
20 Renamed wxTreeCtrl.GetParent to GetItemParent to avoid a name clash
21 with wxWindow.GetParent.
23 Added wxIntersectRect to compute the intersection of two wxRect's.
26 intersect = wxIntersectRect(rect1, rect2)
28 If r1 and r2 don't intersect then None is returned, otherwise the
29 rectangle representing the intersection is returned.
31 Some bug fixes for Clipboard and Drag-n-Drop.
33 Rotated text!!! WooHoo! (See wxDC.DrawRotatedText())
35 Added a set of Generic Buttons to the library. These are simple
36 window classes that look and act like native buttons, but you can have
37 a bit more control over them. The bezel width can be set in addition
38 to colours, fonts, etc. There is a ToggleButton as well as Bitmap
41 The C++ wxToolBar classes have been redone, and so have the wxPython
42 wrappers. There have been slight modifications to some of the methods
43 but shouldn't impact anybody too much. I took the opportunity to add
44 support for setting user data on each toolbar tool. The new AddTool
45 methods look like this:
49 pushedBitmap = wxNullBitmap,
62 There are also coresponding InsertTool and InsertSimpleTool methods
63 that additionally take an integer position as the first parameter.
65 Added a wrapper for the PCX and TIFF ImageHandlers.
67 wxRect now simulates attributes named left, right, top and bottom.
69 Removed all non wx stuff from the glcanvas module since DA's PyOpenGL
70 is better and compatible with the wxGLCanvas. You can get it at
71 http://starship.python.net:9673/crew/da/Code/PyOpenGL.
73 Added some missing EVT_ functions.
75 Added Dirk Holtwic's editor classes to the wxPython.lib.editor
83 Skipped a few version numbers so wxMSW, wxGTK and wxPython are all
86 wxImage.SetData now makes a copy of the image data before giving it to
87 wxImage. I mistakenly thought that wxImage would copy the data
90 Fixed wxMSW's notebook so the pages get their size set as they are
91 being added. This should remove the need for our
92 wxNotebook.ResizeChildren hack.
94 wxPanels now support AutoLayout, and wxNotebooks and wxSplitterWindows
95 no longer tell their children to Layout() themselves. This will
96 probably only effect you if you have a wxWindow with AutoLayout inside
97 a notebook or splitter. If so, either change it to a wxPanel or add
98 an EVT_SIZE handler that calls Layout().
100 Fixed deadlock problem that happened when using threads.
102 Added new HTML printing classes.
104 Added wxWindow.GetHandle
106 Apparently wxMouseEvent.Position has been depreciated in wxWindows as
107 it is no longer available by default. You can use GetPositionTuple
108 (returning a tuple with x,y) instead, or GetPosition (returning a
111 Added wxPostEvent function that allows events to be posted and then
112 processed later. This is a thread-safe way to interact with the GUI
113 thread from other threads.
115 Added Clipboard and Drag-and-Drop classes.
117 Added wxFontEnumerator.
119 Many updates to wxMenu, wxMenuBar.
121 wxPyEvent and wxPyCommandEvent derived classes now give you the actual
122 Python object in the event handler instead of a new shadow.
124 Added a Calendar widget from Lorne White to the library.
126 Made some fixes to the wxFloatbar. It still has some troubles on
129 Added an MVC tree control from Bryn Keller to the library.
136 This is a quick bug-fix release to take care of a few nasties that
137 crept in at the last minute before 2.1.4 was called done. No new
145 This release is NOT syncronized with a snapshot release of wxGTK or
146 wxMSW. For MSW this isn't much of a problem since you can get the
147 binaries from the web site. For other platforms you'll have to build
148 wxGTK from CVS. (See http://web.ukonline.co.uk/julian.smart/wxwin/cvs.htm)
149 To get the same set of sources from CVS that I used, checkout using
152 Now back to what's new...
154 Much more support for event-less callbacks and add-on modules.
156 Created add-on module with wxOGL classes.
158 Added wxWindow.GetChildren(). Be careful of this. It returns a *copy*
159 of the list of the window's children. While you are using the list if
160 anything changes in the real list (a child is deleted, etc.) then the
161 list you are holding will suddenly have window references to garbage
162 memory and your app will likely crash. But if you are careful it works
165 Added a bunch of new and missing methods to wxTreeCrtl. The
166 SortChildren method is now supported, but currently only for the
169 Added typemaps for wxSize, wxPoint, wxRealPoint, and wxRect that allow
170 either the actual objects or Python sequence values to be used. For
171 example, the following are equivallent:
173 win = wxWindow(parent, size = wxSize(100, 100))
174 win = wxWindow(parent, size = (100, 100))
176 Super-charged the wxHtml module. You can now create your own tag
177 handlers and also have access to the parser and cell classes. There
178 is a tag handler in the library at wxPython.lib.wxpTag that
179 understands the WXP tag and is able to place wxPython windows on HTML
180 pages. See the demo for an example.
182 A bunch of the methods of wxMenuBar were previously ifdef'd out for
183 wxGTK. Added them back in since the methods exist now.
185 Wrapped the wxHtmlHelpController and related classes.
187 Wrapped the C++ versions of wxSizer and friends. The Python-only
188 versions are still in the library, but depreciated. (You will get a
189 warning message if you try to use them, but the warning can be
190 disabled.) The usage of the C++ versions is slightly different, and
191 the functionality of wxBorderSizer is now part of wxBoxSizer. I have
192 added a few methods to wxSizer to try and make the transition as
193 smooth as possible, I combined all Add methods into a single method
194 that handles all cases, added an AddMany method, etc. One step I did
195 not take was to make the default value of flag in the Add method be
196 wxGROW. This would have made it more backward compatible, but less
197 portable to and from wxWin C++ code. Please see the docs and demo for
200 Added wxPyEvent and wxPyCommandEvent classes, derived from wxEvent and
201 wxCommandEvent. Each of them has SetPyData and GetPyData methods that
202 accept or return a single Python object. You can use these classes
203 directly or derive from them to create your own types of event objects
204 that can pass through the wxWindows event system without loosing their
205 Python parts (as long as they are stored with SetPyData.) Stay tuned
206 for more info and examples in future releases.
208 Added wxPython.lib.grids as an example of how to derive a new sizer
209 from the C++ sizers. In this module you will find wxGridSizer and
210 wxFlexGridSizer. wxGridSizer arrainges its items in a grid in which
211 all the widths and heights are the same. wxFlexgridSizer allows
212 different widths and heights, and you can also specify rows and/or
213 columns that are growable. See the demo for a couple examples for how
216 Added the wxValidator class, and created a class named wxPyValidator
217 that should be used for the base class of any Python validators. See
218 the demo for an example. Please note that you MUST implement a Clone
219 method in your validator classes because of the way some things work
220 in the underlying C++ library. I did not add wxTextValidator because
221 of some issues of how it transfers data to and from a wxString, which
222 in wxPython is automatically translated to and from Python strings, so
223 there would never be a concrete wxString that would hang around long
224 enough for the validator to do its job. On the other hand, it should
225 be real easy to duplicate the functionality of wxTextValidator in a
226 pure Python class derived from wxPyValidator.
228 I've finally added a feature that has been on my list for close to two
229 years! Ever wondered what that zero is for when you create your app
230 object? Well now you can leave it out or explicitly set it to a true
231 value. This value now controls what is to be done with sys.stdout and
232 sys.stderr. A false value leaves them alone, and a true value sets
233 them to an instance of wxPyOnDemandOutputWindow. (On windows the
234 default is true, on unix platforms the default is false.) This class
235 creates a frame containing a wxTextCtrl as soon as anything is written
236 to sys.stdout or sys.stderr. If you close the window it will come
237 back again the next time something is written. (You can call
238 app.RestoreStdio to turn this off.) If you would rather that the stdio be
239 redirected to a file, you can provide a second parameter to your app
240 object's constructor that is a filename. If you want to use your own
241 class instead of wxPyOnDemandOutputWindow you can either implement
242 RedirectStdio() in you app class or change the value of
243 wxApp.outputWindowClass like this:
246 outputWindowClass = MyClass
250 self.SetTopWindow(frame)
253 Please see the implementation of wxPyOnDemandOutputWindow and wxApp in
254 wx.py for more details. A few words of caution: if you are running
255 your app in a debugger, changing sys.stdout and sys.stderr is likely
256 to really screw things up.
258 Added wxCaret. Unfortunately it's author has still not documented it
259 in the wxWindows docs...
261 Some new 3rd party contributions in wxPython.lib. PyShell, in
262 shell.py is an interesting implementaion of an interactive Python
263 shell in wxWindows. floatbar.py has a class derived from wxToolBar
264 that can sense mouse drags and then reparent itself into another
265 frame. Moving the new frame close to where it came from puts the tool
266 bar back into the original parent. (Unfortunately there is currently
267 a bug in wxGTK's wxFrame.SetToolBar so the FloatBar has some
276 This release is syncronized with release 2.1 snapshot 9 of wxWindows.
278 Switched to using SWIG from CVS (see http://swig.cs.uchicago.edu/cvs.html)
279 for some of the new features and such. Also they have encorporated my
280 patches so there is really no reason to stick with the current (very
281 old) release... This version of SWIG gives the following new
284 1. Keyword arguments. You no longer have to specify all the
285 parameters with defaults to a method just to specify a
286 non-default value on the end. You can now do this instead:
288 win = wxWindow(parent, -1, style = mystyle)
290 2. There is now an an equivalence between Python's None and C++'s
291 NULL. This means that any methods that might return NULL will
292 now return None and you can use none where wxWindows might be
293 expecting NULL. This makes things much more snake-ish.
296 There is a new build system based on a new Python program instead of
297 raw makefiles. Now wxPython builds are virtually the same on MSW or
298 Unix systems. See the end of this file for new build instructions and
299 see distrib/build.py for more details.
301 wxDC.Bilt now includes the useMask parameter, and has been split into
302 two different versions. wxDC.BlitXY is like what was there before and
303 takes raw coordinants and sizes, and the new wxDC.Blit is for the new
304 interface using wxPoints and a wxSize.
313 Added the missing wxWindow.GetUpdateRegion() method.
315 Made a new change in SWIG (update your patches everybody) that
316 provides a fix for global shadow objects that get an exception in
317 their __del__ when their extension module has already been deleted.
318 It was only a 1 line change in .../SWIG/Modules/pycpp.cxx at about
319 line 496 if you want to do it by hand.
321 It is now possible to run through MainLoop more than once in any one
322 process. The cleanup that used to happen as MainLoop completed (and
323 prevented it from running again) has been delayed until the wxc module
324 is being unloaded by Python.
326 I fixed a bunch of stuff in the C++ version of wxGrid so it wouldn't
327 make wxPython look bad.
329 wxWindow.PopupMenu() now takes a wxPoint instead of x,y. Added
330 wxWindow.PopupMenuXY to be consistent with some other methods.
332 Added wxGrid.SetEditInPlace and wxGrid.GetEditInPlace.
334 You can now provide your own app.MainLoop method. See
335 wxPython/demo/demoMainLoop.py for an example and some explaination.
337 Got the in-place-edit for the wxTreeCtrl fixed and added some demo
338 code to show how to use it.
340 Put the wxIcon constructor back in for GTK as it now has one that
343 Added wxGrid.GetCells
345 Added wxSystemSettings static methods as functions with names like
346 wxSystemSettings_GetSystemColour.
348 Removed wxPyMenu since using menu callbacks have been depreciated in
349 wxWindows. Use wxMenu and events instead.
351 Added alternate wxBitmap constructor (for MSW only) as
352 wxBitmapFromData(data, type, width, height, depth = 1)
354 Added a helper function named wxPyTypeCast that can convert shadow
355 objects of one type into shadow objects of another type. (Like doing
356 a down-cast.) See the implementation in wx.py for some docs.
358 Fixed wxImage GetData and SetData to properly use String objects for
361 Added access methods to wxGridEvent.
363 New Makefile/Setup files supporting multiple dynamic extension modules
366 Fixes for the wxGLCanvas demo to work around a strange bug in gtk.
368 SWIG support routines now compiled separately instead of being bundled
377 Fixed wxComboBox.SetSelection so that it actually sets the selected
378 item. (Actually just removed it from wxPython and let it default to
379 wxChoice.SetSelection which was already doing the right thing.)
381 Added the Printing Framework.
383 Switched back to using the wxWindows DLL for the pre-built Win32
384 version. The problem was needing to reinitialize static class info
385 data after loading each extension module.
387 Lots of little tweaks and additions to reflect changes to various
390 Fixed a bug with attaching objects to tree items. Actually was a
391 symptom of a larger problem with not obtaining the interpreter lock
392 when doing any Py_DECREFs.
394 wxSizer and friends. Sizers are layout tools that manage a colection
395 of windows and sizers. Different types of sizers apply different
396 types of layout algorithms. You saw it here first! These classes are
397 not even in the wxWindows C++ library yet!
403 Bug fix for ListCtrl in test4.py (Was a missing file... DSM!)
405 Bug fix for occassional GPF on Win32 systems upon termination of a
406 wxPython application.
408 Added wxListBox.GetSelections returning selections as a Tuple.
410 Added a wxTreeItemData that is able to hold any Python object and be
411 associated with items in a wxTreeCtrl. Added test pytree.py to show
414 Added wxSafeYield function.
416 OpenGL Canvas can be optionally compiled in to wxPython.
418 Awesome new Demo Framework for showing off wxPython and for learning
421 The pre-built Win32 version is no longer distributing the wxWindows
422 DLL. It is statically linked with the wxWindows library instead.
424 Added a couple missing items from the docs.
426 Added wxImage, wxImageHandler, wxPNGHandler, wxJPEGHandler,
427 wxGIFHandler and wxBMPHandler.
429 Added new methods to wxTextCtrl.
431 Fixed some problems with how SWIG was wrapping some wxTreeCtrl
438 Support for using Python threads in wxPython apps.
440 Several missing methods from various classes.
448 Added DLG_PNT and DLG_SZE convienience methods to wxWindow class.
450 Added missing constructor and other methods for wxMenuItem.
456 Just a quickie update to fix the self-installer to be compatible with
457 Python 1.5.2b2's Registry settings.
462 Well obviously the numbering scheme has changed. I did this to
463 reflect the fact that this truly is the second major revision of
464 wxPython, (well the third actually if you count the one I did for
465 wxWindows 1.68 and then threw away...) and also that it is associated
466 with the 2.0 version of wxWindows.
468 I have finally started documenting wxPython. There are several pages
469 in the wxWindows documentation tree specifically about wxPython, and I
470 have added notes within the class references about where and how wxPython
471 diverges from wxWindows.
473 Added wxWindow_FromHWND(hWnd) for wxMSW to construct a wxWindow from a
474 window handle. If you can get the window handle into the python code,
475 it should just work... More news on this later.
477 Added wxImageList, wxToolTip.
479 Re-enabled wxConfig.DeleteAll() since it is reportedly fixed for the
482 As usual, some bug fixes, tweaks, etc.
488 Added wxSashWindow, wxSashEvent, wxLayoutAlgorithm, etc.
490 Various cleanup, tweaks, minor additions, etc. to maintain
491 compatibility with the current wxWindows.
497 Changed the import semantics from "from wxPython import *" to "from
498 wxPython.wx import *" This is for people who are worried about
499 namespace pollution, they can use "from wxPython import wx" and then
500 prefix all the wxPython identifiers with "wx."
502 Added wxTaskbarIcon for wxMSW.
504 Made the events work for wxGrid.
508 Added wxMiniFrame for wxGTK.
510 Changed many of the args and return values that were pointers to gdi
511 objects to references to reflect changes in the wxWindows API.
513 Other assorted fixes and additions.
521 wxPython on wxGTK works!!! Both dynamic and static on Linux and
522 static on Solaris have been tested. Many thanks go to Harm
523 <H.v.d.Heijden@phys.tue.nl> for his astute detective work on tracking
524 down a nasty DECREF bug. Okay so I have to confess that it was just a
525 DSM (Dumb Stupid Mistake) on my part but it was nasty none the less
526 because the behavior was so different on different platforms.
528 The dynamicly loaded module on Solaris is still segfaulting, so it
529 must have been a different issue all along...
536 1. Worked on wxGTK compatibility. It is partially working. On a
537 Solaris/Sparc box wxPython is working but only when it is statically
538 linked with the Python interpreter. When built as a dyamically loaded
539 extension module, things start acting weirdly and it soon seg-faults.
540 And on Linux both the statically linked and the dynamically linked
541 version segfault shortly after starting up.
543 2. Added Toolbar, StatusBar and SplitterWindow classes.
545 3. Varioius bug fixes, enhancements, etc.
547 ----------------------------------------------------------------------