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