wxPython/CHANGES.txt

   1 CHANGES.txt for wxPython
   2
   3 ----------------------------------------------------------------------
   4
   5 New in 2.2.2
   6 ------------
   7
   8 Significantly changed how the wxStyledtextCtrl code that wraps
   9 Scintilla is implemented.  Most of it is now automatically generated
  10 from an interface definition file provided by Scintilla.  This means
  11 that it will be much easier to stay in sync with new Scintilla
  12 releases, but also means that some of the method and identifier names
  13 have changed.  See wxPython/demo/data/stc.h for a copy of the C++
  14 interface from which the Python interface is generated.  There is now
  15 some inline documentation in that file that should really help explain
  16 how things work.
  17
  18 I am now using the Python Distutils to build wxPython and to make some
  19 of the distribution files.  (See http://www.python.org/sigs/distutils-sig/)
  20 This means no more messing with my kludgy build.py/Makefile hack,
  21 builds will be more consistent with other Python extensions that also
  22 use Distutils, and will hopefully make wxPython easier to build for
  23 platforms where there have been troubles before.  If you are building
  24 wxPython for Python 1.5.2 or for 1.6, then you will need to get and
  25 install version 1.0 of Distutils from the website above.  If you are
  26 using Python 2.0 then you already have it.
  27
  28 Added wxInputStream and the wxFileSystem family of classes,
  29 contributed by Joerg Baumann.
  30
  31 Added wxProcess and support for it to wxExecute.  wxProcess lets you
  32 get notified when an asyncronous child process terminates, and also to
  33 get input/output streams for the child process's stdout, stderr and
  34 stdin.
  35
  36 Removed the old python sizers.
  37
  38 Added __add__, __sub__ and __cmp__ (equality check only) for wxPoint
  39 and wxRealPoint.
  40
  41 Changed the build to make one big extension module instead of one for
  42 the core and each contrib.  This allowed me to do away with the
  43 libwxPyHelpers.so on unix systems.
  44
  45 Lots of little fixes here and there.
  46
  47 Some hacks on wxGTK to try and make the AutoComplete listbox in the
  48 wxStyledTextCtrl to behave better.  It's still not as nice as on
  49 wxMSW, but at least it's a bit more usable now.
  50
  51
  52
  53
  54 New in 2.2.1
  55 ------------
  56
  57 Various tweaks, fixes, missing methods, etc.
  58
  59 Added example use of wxTaskBarIcon to the demo.
  60
  61
  62
  63 New in 2.2.0
  64 ------------
  65
  66 Added wxLog and friends.
  67
  68 Added wxFrame.ShowFullScreen for MSW.
  69
  70 Added PyShellWindow to the wxPython.lib package.
  71
  72
  73
  74 New in 2.1.16
  75 -------------
  76
  77 Added an attribute named labelDelta to the generic buttons that
  78 specifies how far to offset the label when the button is in the
  79 depressed state.
  80
  81 Added wxTipProvider and friends.  See the demo for an example.
  82
  83 wxGrid can now change the cell highlight colour.
  84
  85 Added wxDragImage.
  86
  87 Fixed printing on wxGTK.
  88
  89 Added wxDateTime, wxTimeSpan, and wxDateSpan to wxPython.utils.
  90
  91 Added wxCalendarCtrl.
  92
  93 WARNING: A while back I asked what should be done about the Magic
  94 Method Names.  (Methods that are automatically turned into event
  95 handlers by virtue of their name.)  The consensus was that it is more
  96 confusing to have them than to try and expand them to have greater
  97 coverage.  I am finally getting around to removing the code that
  98 generates the event binding.  This means that if you are using any of
  99 the following method names without a EVT_* call that you need to
 100 modify your code to add the EVT_* to hook the event to the method.
 101
 102     OnChar
 103     OnSize
 104     OnEraseBackground
 105     OnSysColourChanged
 106     OnInitDialog
 107     OnPaint
 108     OnIdle
 109     OnActivate
 110     OnMenuHighlight
 111     OnCloseWindow
 112     OnScroll
 113
 114 Added wxSpinCtrl.
 115
 116
 117
 118
 119 New in 2.1.15
 120 -------------
 121
 122 Fixed wxTreeCtrl.HitTest to return both the tree item as well as the
 123 flags that clairify where the click was in relation to the item.
 124
 125 Fixed thread state problem in wxTreeCtrl.GetBoundingBox and
 126 GetSelections.
 127
 128 Fixed some problems in OGL.  Also wxShape.SetClientData and
 129 .GetClientData can now deal with Python objects.
 130
 131 Added wxListCtrl.SortItems and changed the demo to show how to use it.
 132
 133 Plugged a memory leak.
 134
 135 Wrapped the new wxGrid and friends.  The old wxGrid class is no longer
 136 available.  There are some incompatibilities, and unfortunately the
 137 new classes are not documented yet, (however the methods are more
 138 consistent with each other now so you may be able to guess pretty
 139 good...)
 140
 141 Updated filebrowsebutton.py and calendar.py with changes from their
 142 authors.  There is now a FileBrowseButtonWithHistory class (what a
 143 mouthful!) and wxCalendar has printing support.
 144
 145 Added ActiveXWrapper to the library, and some good demos of it too.
 146 It works great for embedding a COM (a.k.a OCX, a.k.a ActiveX) control
 147 in a window and calling its methods.  It actually creates a new class
 148 on the fly that derives from wxWindow, the COM CoClass and others
 149 needed to make it all work.  The resulting class can be instantiated
 150 just like wxWindow, used in sizers, etc.  It also responds to all COM
 151 method calls, properties, etc., and if the class or a mix-in has
 152 matching method names, then the COM events will be propogated back to
 153 them.
 154
 155 Created a typemap that allows a string to be used for parameters
 156 expecting a wxColour type.  The string is either a colour name as
 157 defined in the wxColourDatabase, or a colour spec of the form
 158 "#RRGGBB".  See the wxStyledTextCtrl demo for an example.
 159
 160 I almost forgot to mention the wxStyledTextCtrl!  Yes, the
 161 wxStyledTextCtrl is finally in wxPython!!  (And the crowd goes
 162 wild...)   There's no documentaTion yet (the crowd boos and hisses...)
 163 but I've included a very readable source file in the
 164 wxPython/demo/data directory, a couple fairly good examples, and you
 165 can also refer to the Scintilla documentaion at
 166 http://www.scintilla.org/ScintillaDoc.html to help fill in the gaps
 167 until the docs are done.  (The croud murmers contentedly as the tool
 168 provider smiles convincingly and removes his flame-proof suit.)
 169
 170
 171
 172
 173 What's new in 2.1.13
 174 --------------------
 175 Skipped a version number to match what has been released for wxGTK.
 176
 177 Updated wxMVCTree and added a demo for it, also fixed layout on GTK
 178 and some flicker problems.
 179
 180 Added a wrapper class for the Visualization ToolKit (or VTK) in the
 181 wxPython.lib.vtk module.  (http://www.kitware.com/)
 182
 183 Fixed wxTreeCtrl.SetItemImage and GetItemImage to recognise the new
 184 "which" parameter.
 185
 186 Added wxPython.lib.spashscreen from Mike Fletcher.
 187
 188 Added wxPython.lib.filebrowsebutton also from Mike Fletcher.
 189
 190 Renamed wxTreeCtrl.GetParent to GetItemParent to avoid a name clash
 191 with wxWindow.GetParent.
 192
 193 Added wxIntersectRect to compute the intersection of two wxRect's.
 194 It is used like this:
 195
 196    intersect = wxIntersectRect(rect1, rect2)
 197
 198 If r1 and r2 don't intersect then None is returned, otherwise the
 199 rectangle representing the intersection is returned.
 200
 201 Some bug fixes for Clipboard and Drag-n-Drop.
 202
 203 Rotated text!!!  WooHoo!  (See wxDC.DrawRotatedText())
 204
 205 Added a set of Generic Buttons to the library.  These are simple
 206 window classes that look and act like native buttons, but you can have
 207 a bit more control over them.  The bezel width can be set in addition
 208 to colours, fonts, etc.  There is a ToggleButton as well as Bitmap
 209 versions too.  They should also serve as a good example of how to
 210 create your own classes derived from wxControl.
 211
 212 The C++ wxToolBar classes have been redone, and so have the wxPython
 213 wrappers.  There have been slight modifications to some of the methods
 214 but shouldn't impact anybody too much.  I took the opportunity to add
 215 support for setting user data on each toolbar tool.  The new AddTool
 216 methods look like this:
 217
 218         def AddTool(ID,
 219                     bitmap,
 220                     pushedBitmap = wxNullBitmap,
 221                     toggle = FALSE,
 222                     clientData = NULL,
 223                     shortHelpString = "",
 224                     longHelpString = "")
 225
 226         def AddSimpleTool(ID,
 227                           bitmap,
 228                           shortHelpString = "",
 229                           longHelpString = "",
 230                           toggle=FALSE)
 231
 232
 233 There are also coresponding InsertTool and InsertSimpleTool methods
 234 that additionally take an integer position as the first parameter.
 235
 236 Added a wrapper for the new PCX and TIFF ImageHandlers.
 237
 238 wxRect now simulates attributes named left, right, top and bottom.
 239
 240 Removed all non wx stuff from the glcanvas module since DA's PyOpenGL
 241 is better and compatible with the wxGLCanvas.  You can get it at
 242 http://starship.python.net:9673/crew/da/Code/PyOpenGL.
 243
 244 Added some missing EVT_ functions.
 245
 246 Added Dirk Holtwic's editor classes to the wxPython.lib.editor
 247 package.
 248
 249 Changed all the "LIST" parameter names to "choices" to match the docs.
 250
 251 More fixes for the wxFloatBar, and it now works on wxGTK even better
 252 than wxMSW!  (The feat is accomplished by using the wxTB_DOCKABLE
 253 style flag instead of trying to float it ourselves.)
 254
 255
 256
 257
 258 What's new in 2.1.11
 259 --------------------
 260 Skipped a few version numbers so wxMSW, wxGTK and wxPython are all
 261 syncronized.
 262
 263 wxImage.SetData now makes a copy of the image data before giving it to
 264 wxImage.  I mistakenly thought that wxImage would copy the data
 265 itself.
 266
 267 Fixed wxMSW's notebook so the pages get their size set as they are
 268 being added.  This should remove the need for our
 269 wxNotebook.ResizeChildren hack.
 270
 271 wxPanels now support AutoLayout, and wxNotebooks and wxSplitterWindows
 272 no longer tell their children to Layout() themselves.  This will
 273 probably only effect you if you have a wxWindow with AutoLayout inside
 274 a notebook or splitter.  If so, either change it to a wxPanel or add
 275 an EVT_SIZE handler that calls Layout().
 276
 277 Fixed deadlock problem that happened when using threads.
 278
 279 Added new HTML printing classes.
 280
 281 Added wxWindow.GetHandle
 282
 283 Apparently wxMouseEvent.Position has been depreciated in wxWindows as
 284 it is no longer available by default.  You can use GetPositionTuple
 285 (returning a tuple with x,y) instead, or GetPosition (returning a
 286 wxPoint.)
 287
 288 Added wxPostEvent function that allows events to be posted and then
 289 processed later.  This is a thread-safe way to interact with the GUI
 290 thread from other threads.
 291
 292 Added Clipboard and Drag-and-Drop classes.
 293
 294 Added wxFontEnumerator.
 295
 296 Many updates to wxMenu, wxMenuBar.
 297
 298 wxPyEvent and wxPyCommandEvent derived classes now give you the actual
 299 Python object in the event handler instead of a new shadow.
 300
 301 Added a Calendar widget from Lorne White to the library.
 302
 303 Made some fixes to the wxFloatbar.  It still has some troubles on
 304 wxGTK...
 305
 306 Added an MVC tree control from Bryn Keller to the library.
 307
 308
 309
 310
 311 What's new in 2.1.5
 312 -------------------
 313 This is a quick bug-fix release to take care of a few nasties that
 314 crept in at the last minute before 2.1.4 was called done.  No new
 315 major features.
 316
 317
 318
 319 What's new in 2.1.4
 320 --------------------
 321
 322 This release is NOT syncronized with a snapshot release of wxGTK or
 323 wxMSW.  For MSW this isn't much of a problem since you can get the
 324 binaries from the web site.  For other platforms you'll have to build
 325 wxGTK from CVS.  (See http://web.ukonline.co.uk/julian.smart/wxwin/cvs.htm)
 326 To get the same set of sources from CVS that I used, checkout using
 327 the wxPy-2-1-4 tag.
 328
 329 Now back to what's new...
 330
 331 Much more support for event-less callbacks and add-on modules.
 332
 333 Created add-on module with wxOGL classes.
 334
 335 Added wxWindow.GetChildren().  Be careful of this.  It returns a *copy*
 336 of the list of the window's children.  While you are using the list if
 337 anything changes in the real list (a child is deleted, etc.) then the
 338 list you are holding will suddenly have window references to garbage
 339 memory and your app will likely crash.  But if you are careful it works
 340 great!
 341
 342 Added a bunch of new and missing methods to wxTreeCrtl.  The
 343 SortChildren method is now supported, but currently only for the
 344 default sort order.
 345
 346 Added typemaps for wxSize, wxPoint, wxRealPoint, and wxRect that allow
 347 either the actual objects or Python sequence values to be used.  For
 348 example, the following are equivallent:
 349
 350     win = wxWindow(parent, size = wxSize(100, 100))
 351     win = wxWindow(parent, size = (100, 100))
 352
 353 Super-charged the wxHtml module.  You can now create your own tag
 354 handlers and also have access to the parser and cell classes.  There
 355 is a tag handler in the library at wxPython.lib.wxpTag that
 356 understands the WXP tag and is able to place wxPython windows on HTML
 357 pages.  See the demo for an example.
 358
 359 A bunch of the methods of wxMenuBar were previously ifdef'd out for
 360 wxGTK.  Added them back in since the methods exist now.
 361
 362 Wrapped the wxHtmlHelpController and related classes.
 363
 364 Wrapped the C++ versions of wxSizer and friends.  The Python-only
 365 versions are still in the library, but depreciated.  (You will get a
 366 warning message if you try to use them, but the warning can be
 367 disabled.) The usage of the C++ versions is slightly different, and
 368 the functionality of wxBorderSizer is now part of wxBoxSizer.  I have
 369 added a few methods to wxSizer to try and make the transition as
 370 smooth as possible, I combined all Add methods into a single method
 371 that handles all cases, added an AddMany method, etc.  One step I did
 372 not take was to make the default value of flag in the Add method be
 373 wxGROW.  This would have made it more backward compatible, but less
 374 portable to and from wxWin C++ code.  Please see the docs and demo for
 375 further details.
 376
 377 Added wxPyEvent and wxPyCommandEvent classes, derived from wxEvent and
 378 wxCommandEvent.  Each of them has SetPyData and GetPyData methods that
 379 accept or return a single Python object.  You can use these classes
 380 directly or derive from them to create your own types of event objects
 381 that can pass through the wxWindows event system without loosing their
 382 Python parts (as long as they are stored with SetPyData.)  Stay tuned
 383 for more info and examples in future releases.
 384
 385 Added wxPython.lib.grids as an example of how to derive a new sizer
 386 from the C++ sizers.  In this module you will find wxGridSizer and
 387 wxFlexGridSizer.  wxGridSizer arrainges its items in a grid in which
 388 all the widths and heights are the same.  wxFlexgridSizer allows
 389 different widths and heights, and you can also specify rows and/or
 390 columns that are growable.  See the demo for a couple examples for how
 391 to use them.
 392
 393 Added the wxValidator class, and created a class named wxPyValidator
 394 that should be used for the base class of any Python validators.  See
 395 the demo for an example.  Please note that you MUST implement a Clone
 396 method in your validator classes because of the way some things work
 397 in the underlying C++ library.  I did not add wxTextValidator because
 398 of some issues of how it transfers data to and from a wxString, which
 399 in wxPython is automatically translated to and from Python strings, so
 400 there would never be a concrete wxString that would hang around long
 401 enough for the validator to do its job.  On the other hand, it should
 402 be real easy to duplicate the functionality of wxTextValidator in a
 403 pure Python class derived from wxPyValidator.
 404
 405 I've finally added a feature that has been on my list for close to two
 406 years!  Ever wondered what that zero is for when you create your app
 407 object?  Well now you can leave it out or explicitly set it to a true
 408 value.  This value now controls what is to be done with sys.stdout and
 409 sys.stderr.  A false value leaves them alone, and a true value sets
 410 them to an instance of wxPyOnDemandOutputWindow.  (On windows the
 411 default is true, on unix platforms the default is false.)  This class
 412 creates a frame containing a wxTextCtrl as soon as anything is written
 413 to sys.stdout or sys.stderr.  If you close the window it will come
 414 back again the next time something is written.  (You can call
 415 app.RestoreStdio to turn this off.)  If you would rather that the stdio be
 416 redirected to a file, you can provide a second parameter to your app
 417 object's constructor that is a filename.  If you want to use your own
 418 class instead of wxPyOnDemandOutputWindow you can either implement
 419 RedirectStdio() in you app class or change the value of
 420 wxApp.outputWindowClass like this:
 421
 422     class MyApp(wxApp):
 423         outputWindowClass = MyClass
 424
 425         def OnInit(self):
 426             frame = MyFrame()
 427             self.SetTopWindow(frame)
 428             return true
 429
 430 Please see the implementation of wxPyOnDemandOutputWindow and wxApp in
 431 wx.py for more details.  A few words of caution:  if you are running
 432 your app in a debugger, changing sys.stdout and sys.stderr is likely
 433 to really screw things up.
 434
 435 Added wxCaret.  Unfortunately it's author has still not documented it
 436 in the wxWindows docs...
 437
 438 Some new 3rd party contributions in wxPython.lib.  PyShell, in
 439 shell.py is an interesting implementaion of an interactive Python
 440 shell in wxWindows.  floatbar.py has a class derived from wxToolBar
 441 that can sense mouse drags and then reparent itself into another
 442 frame. Moving the new frame close to where it came from puts the tool
 443 bar back into the original parent.  (Unfortunately there is currently
 444 a bug in wxGTK's wxFrame.SetToolBar so the FloatBar has some
 445 problems...)
 446
 447
 448
 449
 450 What's new in 2.1b3
 451 --------------------
 452
 453 This release is syncronized with release 2.1 snapshot 9 of wxWindows.
 454
 455 Switched to using SWIG from CVS (see http://swig.cs.uchicago.edu/cvs.html)
 456 for some of the new features and such.  Also they have encorporated my
 457 patches so there is really no reason to stick with the current (very
 458 old) release...  This version of SWIG gives the following new
 459 features:
 460
 461     1. Keyword arguments.  You no longer have to specify all the
 462        parameters with defaults to a method just to specify a
 463        non-default value on the end.  You can now do this instead:
 464
 465           win = wxWindow(parent, -1, style = mystyle)
 466
 467     2. There is now an an equivalence between Python's None and C++'s
 468        NULL.  This means that any methods that might return NULL will
 469        now return None and you can use none where wxWindows might be
 470        expecting NULL.  This makes things much more snake-ish.
 471
 472
 473 There is a new build system based on a new Python program instead of
 474 raw makefiles.  Now wxPython builds are virtually the same on MSW or
 475 Unix systems.  See the end of this file for new build instructions and
 476 see distrib/build.py for more details.
 477
 478 wxDC.Bilt now includes the useMask parameter, and has been split into
 479 two different versions.  wxDC.BlitXY is like what was there before and
 480 takes raw coordinants and sizes, and the new wxDC.Blit is for the new
 481 interface using wxPoints and a wxSize.
 482
 483
 484
 485
 486
 487 What's new in 2.1b2
 488 --------------------
 489
 490 Added the missing wxWindow.GetUpdateRegion() method.
 491
 492 Made a new change in SWIG (update your patches everybody) that
 493 provides a fix for global shadow objects that get an exception in
 494 their __del__ when their extension module has already been deleted.
 495 It was only a 1 line change in .../SWIG/Modules/pycpp.cxx at about
 496 line 496 if you want to do it by hand.
 497
 498 It is now possible to run through MainLoop more than once in any one
 499 process.  The cleanup that used to happen as MainLoop completed (and
 500 prevented it from running again) has been delayed until the wxc module
 501 is being unloaded by Python.
 502
 503 I fixed a bunch of stuff in the C++ version of wxGrid so it wouldn't
 504 make wxPython look bad.
 505
 506 wxWindow.PopupMenu() now takes a wxPoint instead of  x,y.  Added
 507 wxWindow.PopupMenuXY to be consistent with some other methods.
 508
 509 Added wxGrid.SetEditInPlace and wxGrid.GetEditInPlace.
 510
 511 You can now provide your own app.MainLoop method.  See
 512 wxPython/demo/demoMainLoop.py for an example and some explaination.
 513
 514 Got the in-place-edit for the wxTreeCtrl fixed and added some demo
 515 code to show how to use it.
 516
 517 Put the wxIcon constructor back in for GTK as it now has one that
 518 matches MSW's.
 519
 520 Added wxGrid.GetCells
 521
 522 Added wxSystemSettings static methods as functions with names like
 523 wxSystemSettings_GetSystemColour.
 524
 525 Removed wxPyMenu since using menu callbacks have been depreciated in
 526 wxWindows.  Use wxMenu and events instead.
 527
 528 Added alternate wxBitmap constructor (for MSW only) as
 529       wxBitmapFromData(data, type, width, height, depth = 1)
 530
 531 Added a helper function named wxPyTypeCast that can convert shadow
 532 objects of one type into shadow objects of another type.  (Like doing
 533 a down-cast.)  See the implementation in wx.py for some docs.
 534
 535 Fixed wxImage GetData and SetData to properly use String objects for
 536 data transfer.
 537
 538 Added access methods to wxGridEvent.
 539
 540 New Makefile/Setup files supporting multiple dynamic extension modules
 541 for unix systems.
 542
 543 Fixes for the wxGLCanvas demo to work around a strange bug in gtk.
 544
 545 SWIG support routines now compiled separately instead of being bundled
 546 in wx.cpp.
 547
 548
 549
 550
 551
 552 What's new in 2.1b1
 553 --------------------
 554 Fixed wxComboBox.SetSelection so that it actually sets the selected
 555 item.  (Actually just removed it from wxPython and let it default to
 556 wxChoice.SetSelection which was already doing the right thing.)
 557
 558 Added the Printing Framework.
 559
 560 Switched back to using the wxWindows DLL for the pre-built Win32
 561 version.  The problem was needing to reinitialize static class info
 562 data after loading each extension module.
 563
 564 Lots of little tweaks and additions to reflect changes to various
 565 wxWindows classes.
 566
 567 Fixed a bug with attaching objects to tree items.  Actually was a
 568 symptom of a larger problem with not obtaining the interpreter lock
 569 when doing any Py_DECREFs.
 570
 571 wxSizer and friends.  Sizers are layout tools that manage a colection
 572 of windows and sizers.  Different types of sizers apply different
 573 types of layout algorithms.  You saw it here first!  These classes are
 574 not even in the wxWindows C++ library yet!
 575
 576
 577
 578 What's new in 2.0b9
 579 -------------------
 580 Bug fix for ListCtrl in test4.py (Was a missing file...  DSM!)
 581
 582 Bug fix for occassional GPF on Win32 systems upon termination of a
 583 wxPython application.
 584
 585 Added wxListBox.GetSelections returning selections as a Tuple.
 586
 587 Added a wxTreeItemData that is able to hold any Python object and be
 588 associated with items in a wxTreeCtrl.  Added test pytree.py to show
 589 this feature off.
 590
 591 Added wxSafeYield function.
 592
 593 OpenGL Canvas can be optionally compiled in to wxPython.
 594
 595 Awesome new Demo Framework for showing off wxPython and for learning
 596 how it all works.
 597
 598 The pre-built Win32 version is no longer distributing the wxWindows
 599 DLL.  It is statically linked with the wxWindows library instead.
 600
 601 Added a couple missing items from the docs.
 602
 603 Added wxImage, wxImageHandler, wxPNGHandler, wxJPEGHandler,
 604 wxGIFHandler and wxBMPHandler.
 605
 606 Added new methods to wxTextCtrl.
 607
 608 Fixed some problems with how SWIG was wrapping some wxTreeCtrl
 609 methods.
 610
 611
 612
 613 What's new in 2.0b8
 614 -------------------
 615 Support for using Python threads in wxPython apps.
 616
 617 Several missing methods from various classes.
 618
 619 Various bug fixes.
 620
 621
 622
 623 What's new in 2.0b7
 624 -------------------
 625 Added DLG_PNT and DLG_SZE convienience methods to wxWindow class.
 626
 627 Added missing constructor and other methods for wxMenuItem.
 628
 629
 630
 631 What's new in 2.0b6
 632 -------------------
 633 Just a quickie update to fix the self-installer to be compatible with
 634 Python 1.5.2b2's Registry settings.
 635
 636
 637 What's new in 2.0b5
 638 -------------------
 639 Well obviously the numbering scheme has changed.  I did this to
 640 reflect the fact that this truly is the second major revision of
 641 wxPython, (well the third actually if you count the one I did for
 642 wxWindows 1.68 and then threw away...) and also that it is associated
 643 with the 2.0 version of wxWindows.
 644
 645 I have finally started documenting wxPython.  There are several pages
 646 in the wxWindows documentation tree specifically about wxPython, and I
 647 have added notes within the class references about where and how wxPython
 648 diverges from wxWindows.
 649
 650 Added wxWindow_FromHWND(hWnd) for wxMSW to construct a wxWindow from a
 651 window handle.  If you can get the window handle into the python code,
 652 it should just work...  More news on this later.
 653
 654 Added wxImageList, wxToolTip.
 655
 656 Re-enabled wxConfig.DeleteAll() since it is reportedly fixed for the
 657 wxRegConfig class.
 658
 659 As usual, some bug fixes, tweaks, etc.
 660
 661
 662
 663 What's new in 0.5.3
 664 -------------------
 665 Added wxSashWindow, wxSashEvent, wxLayoutAlgorithm, etc.
 666
 667 Various cleanup, tweaks, minor additions, etc. to maintain
 668 compatibility with the current wxWindows.
 669
 670
 671
 672 What's new in 0.5.0
 673 -------------------
 674 Changed the import semantics from "from wxPython import *" to "from
 675 wxPython.wx import *"  This is for people who are worried about
 676 namespace pollution, they can use "from wxPython import wx" and then
 677 prefix all the wxPython identifiers with "wx."
 678
 679 Added wxTaskbarIcon for wxMSW.
 680
 681 Made the events work for wxGrid.
 682
 683 Added wxConfig.
 684
 685 Added wxMiniFrame for wxGTK.
 686
 687 Changed many of the args and return values that were pointers to gdi
 688 objects to references to reflect changes in the wxWindows API.
 689
 690 Other assorted fixes and additions.
 691
 692
 693
 694
 695 What's new in 0.4.2
 696 -------------------
 697
 698 wxPython on wxGTK works!!!  Both dynamic and static on Linux and
 699 static on Solaris have been tested.  Many thanks go to Harm
 700 <H.v.d.Heijden@phys.tue.nl> for his astute detective work on tracking
 701 down a nasty DECREF bug.  Okay so I have to confess that it was just a
 702 DSM (Dumb Stupid Mistake) on my part but it was nasty none the less
 703 because the behavior was so different on different platforms.
 704
 705 The dynamicly loaded module on Solaris is still segfaulting, so it
 706 must have been a different issue all along...
 707
 708
 709
 710 What's New in 0.4
 711 -----------------
 712
 713 1. Worked on wxGTK compatibility.  It is partially working.  On a
 714 Solaris/Sparc box wxPython is working but only when it is statically
 715 linked with the Python interpreter.  When built as a dyamically loaded
 716 extension module, things start acting weirdly and it soon seg-faults.
 717 And on Linux both the statically linked and the dynamically linked
 718 version segfault shortly after starting up.
 719
 720 2. Added Toolbar, StatusBar and SplitterWindow classes.
 721
 722 3. Varioius bug fixes, enhancements, etc.
 723
 724 ----------------------------------------------------------------------