]>
Commit | Line | Data |
---|---|---|
1 | wxPython README | |
2 | --------------- | |
3 | ||
4 | Welcome to the wonderful world of wxPython! | |
5 | ||
6 | Once you have installed the wxPython extension module, you can try it | |
7 | out by going to the [install dir]\wxPython\demo directory and typing: | |
8 | ||
9 | python demo.py | |
10 | ||
11 | There are also some other sample files there for you to play with and | |
12 | learn from. | |
13 | ||
14 | If you selected to install the documentation then point your browser | |
15 | to [install dir]\wxPython\docs\index.htm and you will then be looking | |
16 | at the docs for wxWindows. For the most part you can use the C++ docs | |
17 | as most classes and methods are used identically. Where there are | |
18 | differences they are documented with a "wxPython Note." | |
19 | ||
20 | On Win32 systems the binary self-installer creates a program group on | |
21 | the Start Menu that contains a link to running the demo and a link to | |
22 | the help file. To help you save disk space I'm now using Microsoft's | |
23 | HTML Help format. If your system doesn't know what to do with the help | |
24 | file, you can install the HTML Help Viewer as part of IE 4+, NT | |
25 | Service Pack 4+, or the HTML Workshop at | |
26 | ||
27 | http://msdn.microsoft.com/workshop/author/htmlhelp/download.asp. | |
28 | ||
29 | ||
30 | ||
31 | Getting Help | |
32 | ------------ | |
33 | ||
34 | Since wxPython is a blending of multiple technologies, help comes from | |
35 | multiple sources. See the http://alldunn.com/wxPython for details on | |
36 | various sources of help, but probably the best source is the | |
37 | wxPython-users mail list. You can view the archive or subscribe by | |
38 | going to | |
39 | ||
40 | http://starship.python.net/mailman/listinfo/wxpython-users | |
41 | ||
42 | Or you can send mail directly to the list using this address: | |
43 | ||
44 | wxpython-users@starship.python.net | |
45 | ||
46 | ---------------------------------------------------------------------- | |
47 | ||
48 | What's new in 2.1b2 | |
49 | -------------------- | |
50 | ||
51 | Added the missing wxWindow.GetUpdateRegion() method. | |
52 | ||
53 | Made a new change in SWIG (update your patches everybody) that | |
54 | provides a fix for global shadow objects that get an exception in | |
55 | their __del__ when their extension module has already been deleted. | |
56 | It was only a 1 line change in .../SWIG/Modules/pycpp.cxx at about | |
57 | line 496 if you want to do it by hand. | |
58 | ||
59 | It is now possible to run through MainLoop more than once in any one | |
60 | process. The cleanup that used to happen as MainLoop completed (and | |
61 | prevented it from running again) has been delayed until the wxc module | |
62 | is being unloaded by Python. | |
63 | ||
64 | I fixed a bunch of stuff in the C++ version of wxGrid so it wouldn't | |
65 | make wxPython look bad. | |
66 | ||
67 | wxWindow.PopupMenu() now takes a wxPoint instead of x,y. Added | |
68 | wxWindow.PopupMenuXY to be consistent with some other methods. | |
69 | ||
70 | Added wxGrid.SetEditInPlace and wxGrid.GetEditInPlace. | |
71 | ||
72 | You can now provide your own app.MainLoop method. See | |
73 | wxPython/demo/demoMainLoop.py for an example and some explaination. | |
74 | ||
75 | Got the in-place-edit for the wxTreeCtrl fixed and added some demo | |
76 | code to show how to use it. | |
77 | ||
78 | Put the wxIcon constructor back in for GTK as it now has one that | |
79 | matches MSW's. | |
80 | ||
81 | Added wxGrid.GetCells | |
82 | ||
83 | Added wxSystemSettings static methods as functions with names like | |
84 | wxSystemSettings_GetSystemColour. | |
85 | ||
86 | Removed wxPyMenu since using menu callbacks have been depreciated in | |
87 | wxWindows. Use wxMenu and events instead. | |
88 | ||
89 | Added alternate wxBitmap constructor (for MSW only) as | |
90 | wxBitmapFromData(data, type, width, height, depth = 1) | |
91 | ||
92 | Added a helper function named wxPyTypeCast that can convert shadow | |
93 | objects of one type into shadow objects of another type. (Like doing | |
94 | a down-cast.) See the implementation in wx.py for some docs. | |
95 | ||
96 | Fixed wxImage GetData and SetData to properly use String objects for | |
97 | data transfer. | |
98 | ||
99 | Added access methods to wxGridEvent. | |
100 | ||
101 | New Makefile/Setup files supporting multiple dynamic extension modules | |
102 | for unix systems. | |
103 | ||
104 | Fixes for the wxGLCanvas demo to work around a strange bug in gtk. | |
105 | ||
106 | SWIG support routines now compiled separately instead of being bundled | |
107 | in wx.cpp. | |
108 | ||
109 | ||
110 | ||
111 | ||
112 | What's new in 2.1b1 | |
113 | -------------------- | |
114 | Fixed wxComboBox.SetSelection so that it actually sets the selected | |
115 | item. (Actually just removed it from wxPython and let it default to | |
116 | wxChoice.SetSelection which was already doing the right thing.) | |
117 | ||
118 | Added the Printing Framework. | |
119 | ||
120 | Switched back to using the wxWindows DLL for the pre-built Win32 | |
121 | version. The problem was needing to reinitialize static class info | |
122 | data after loading each extension module. | |
123 | ||
124 | Lots of little tweaks and additions to reflect changes to various | |
125 | wxWindows classes. | |
126 | ||
127 | Fixed a bug with attaching objects to tree items. Actually was a | |
128 | symptom of a larger problem with not obtaining the interpreter lock | |
129 | when doing any Py_DECREFs. | |
130 | ||
131 | wxSizer and friends. Sizers are layout tools that manage a colection | |
132 | of windows and sizers. Different types of sizers apply different | |
133 | types of layout algorithms. You saw it here first! These classes are | |
134 | not even in the wxWindows C++ library yet! | |
135 | ||
136 | ||
137 | ||
138 | What's new in 2.0b9 | |
139 | ------------------- | |
140 | Bug fix for ListCtrl in test4.py (Was a missing file... DSM!) | |
141 | ||
142 | Bug fix for occassional GPF on Win32 systems upon termination of a | |
143 | wxPython application. | |
144 | ||
145 | Added wxListBox.GetSelections returning selections as a Tuple. | |
146 | ||
147 | Added a wxTreeItemData that is able to hold any Python object and be | |
148 | associated with items in a wxTreeCtrl. Added test pytree.py to show | |
149 | this feature off. | |
150 | ||
151 | Added wxSafeYield function. | |
152 | ||
153 | OpenGL Canvas can be optionally compiled in to wxPython. | |
154 | ||
155 | Awesome new Demo Framework for showing off wxPython and for learning | |
156 | how it all works. | |
157 | ||
158 | The pre-built Win32 version is no longer distributing the wxWindows | |
159 | DLL. It is statically linked with the wxWindows library instead. | |
160 | ||
161 | Added a couple missing items from the docs. | |
162 | ||
163 | Added wxImage, wxImageHandler, wxPNGHandler, wxJPEGHandler, | |
164 | wxGIFHandler and wxBMPHandler. | |
165 | ||
166 | Added new methods to wxTextCtrl. | |
167 | ||
168 | Fixed some problems with how SWIG was wrapping some wxTreeCtrl | |
169 | methods. | |
170 | ||
171 | ||
172 | ||
173 | What's new in 2.0b8 | |
174 | ------------------- | |
175 | Support for using Python threads in wxPython apps. | |
176 | ||
177 | Several missing methods from various classes. | |
178 | ||
179 | Various bug fixes. | |
180 | ||
181 | ||
182 | ||
183 | What's new in 2.0b7 | |
184 | ------------------- | |
185 | Added DLG_PNT and DLG_SZE convienience methods to wxWindow class. | |
186 | ||
187 | Added missing constructor and other methods for wxMenuItem. | |
188 | ||
189 | ||
190 | ||
191 | What's new in 2.0b6 | |
192 | ------------------- | |
193 | Just a quickie update to fix the self-installer to be compatible with | |
194 | Python 1.5.2b2's Registry settings. | |
195 | ||
196 | ||
197 | What's new in 2.0b5 | |
198 | ------------------- | |
199 | Well obviously the numbering scheme has changed. I did this to | |
200 | reflect the fact that this truly is the second major revision of | |
201 | wxPython, (well the third actually if you count the one I did for | |
202 | wxWindows 1.68 and then threw away...) and also that it is associated | |
203 | with the 2.0 version of wxWindows. | |
204 | ||
205 | I have finally started documenting wxPython. There are several pages | |
206 | in the wxWindows documentation tree specifically about wxPython, and I | |
207 | have added notes within the class references about where and how wxPython | |
208 | diverges from wxWindows. | |
209 | ||
210 | Added wxWindow_FromHWND(hWnd) for wxMSW to construct a wxWindow from a | |
211 | window handle. If you can get the window handle into the python code, | |
212 | it should just work... More news on this later. | |
213 | ||
214 | Added wxImageList, wxToolTip. | |
215 | ||
216 | Re-enabled wxConfig.DeleteAll() since it is reportedly fixed for the | |
217 | wxRegConfig class. | |
218 | ||
219 | As usual, some bug fixes, tweaks, etc. | |
220 | ||
221 | ||
222 | ||
223 | What's new in 0.5.3 | |
224 | ------------------- | |
225 | Added wxSashWindow, wxSashEvent, wxLayoutAlgorithm, etc. | |
226 | ||
227 | Various cleanup, tweaks, minor additions, etc. to maintain | |
228 | compatibility with the current wxWindows. | |
229 | ||
230 | ||
231 | ||
232 | What's new in 0.5.0 | |
233 | ------------------- | |
234 | Changed the import semantics from "from wxPython import *" to "from | |
235 | wxPython.wx import *" This is for people who are worried about | |
236 | namespace pollution, they can use "from wxPython import wx" and then | |
237 | prefix all the wxPython identifiers with "wx." | |
238 | ||
239 | Added wxTaskbarIcon for wxMSW. | |
240 | ||
241 | Made the events work for wxGrid. | |
242 | ||
243 | Added wxConfig. | |
244 | ||
245 | Added wxMiniFrame for wxGTK. | |
246 | ||
247 | Changed many of the args and return values that were pointers to gdi | |
248 | objects to references to reflect changes in the wxWindows API. | |
249 | ||
250 | Other assorted fixes and additions. | |
251 | ||
252 | ||
253 | ||
254 | ||
255 | What's new in 0.4.2 | |
256 | ------------------- | |
257 | ||
258 | wxPython on wxGTK works!!! Both dynamic and static on Linux and | |
259 | static on Solaris have been tested. Many thanks go to Harm | |
260 | <H.v.d.Heijden@phys.tue.nl> for his astute detective work on tracking | |
261 | down a nasty DECREF bug. Okay so I have to confess that it was just a | |
262 | DSM (Dumb Stupid Mistake) on my part but it was nasty none the less | |
263 | because the behavior was so different on different platforms. | |
264 | ||
265 | The dynamicly loaded module on Solaris is still segfaulting, so it | |
266 | must have been a different issue all along... | |
267 | ||
268 | ||
269 | ||
270 | What's New in 0.4 | |
271 | ----------------- | |
272 | ||
273 | 1. Worked on wxGTK compatibility. It is partially working. On a | |
274 | Solaris/Sparc box wxPython is working but only when it is statically | |
275 | linked with the Python interpreter. When built as a dyamically loaded | |
276 | extension module, things start acting weirdly and it soon seg-faults. | |
277 | And on Linux both the statically linked and the dynamically linked | |
278 | version segfault shortly after starting up. | |
279 | ||
280 | 2. Added Toolbar, StatusBar and SplitterWindow classes. | |
281 | ||
282 | 3. Varioius bug fixes, enhancements, etc. | |
283 | ||
284 | ---------------------------------------------------------------------- | |
285 | ||
286 | ||
287 | ||
288 | Build Instructions | |
289 | ------------------ | |
290 | I used SWIG (http://www.swig.org) to create the source code for the | |
291 | extension module. This enabled me to only have to deal with a small | |
292 | amount of code and only have to bother with the exceptional issues. | |
293 | SWIG takes care of the rest and generates all the repetative code for | |
294 | me. You don't need SWIG to build the extension module as all the | |
295 | generated C++ code is included under the src directory. | |
296 | ||
297 | I added a few minor features to SWIG to control some of the code | |
298 | generation. If you want to playaround with this the patches are in | |
299 | wxPython/SWIG.patches and they should be applied to the 1.1p5 version | |
300 | of SWIG. These new patches are documented at | |
301 | http://starship.skyport.net/crew/robind/#swig, and they should also | |
302 | end up in the 1.2 version of SWIG. | |
303 | ||
304 | wxPython is organized as a Python package. This means that the | |
305 | directory containing the results of the build process should be a | |
306 | subdirectory of a directory on the PYTHONPATH. (And preferably should | |
307 | be named wxPython.) You can control where the build process will dump | |
308 | wxPython by setting the TARGETDIR makefile variable. The default is | |
309 | $(WXWIN)/utils/wxPython, where this README.txt is located. If you | |
310 | leave it here then you should add $(WXWIN)/utils to your PYTHONPATH. | |
311 | However, you may prefer to use something that is already on your | |
312 | PYTHONPATH, such as the site-packages directory on Unix systems. | |
313 | ||
314 | ||
315 | Win32 | |
316 | ----- | |
317 | ||
318 | 1. Build wxWindows with wxUSE_RESOURCE_LOADING_IN_MSW set to 1 in | |
319 | include/wx/msw/setup.h so icons can be loaded dynamically. While | |
320 | there, make sure wxUSE_OWNER_DRAWN is also set to 1. | |
321 | ||
322 | 2. Change into the $(WXWIN)/utils/wxPython/src directory. | |
323 | ||
324 | 3. Edit makefile.vc and specify where your python installation is at. | |
325 | You may also want to fiddle with the TARGETDIR variable as described | |
326 | above. | |
327 | ||
328 | 4. Run nmake -f makefile.vc | |
329 | ||
330 | 5. If it builds successfully, congratulations! Move on to the next | |
331 | step. If not then you can try mailing me for help. Also, I will | |
332 | always have a pre-built win32 version of this extension module at | |
333 | http://alldunn.com/wxPython/. | |
334 | ||
335 | 6. Change to the $(WXWIN)/utils/wxPython/demo directory. | |
336 | ||
337 | 7. Try executing the demo program. For example: | |
338 | ||
339 | python demo.py | |
340 | ||
341 | To run it without requiring a console, you can use the pythonw.exe | |
342 | version of Python either from the command line or from a shortcut. | |
343 | ||
344 | ||
345 | ||
346 | Unix | |
347 | ---- | |
348 | 0. I configure wxWindows like this, YMMV: | |
349 | ||
350 | ./configure --with-gtk --disable-shared --enable-threads --disable-unicode | |
351 | ||
352 | 1. Change into the $(WXWIN)/utils/wxPython/src directory. | |
353 | ||
354 | 2. Edit Setup.in and ensure that the flags, directories, and toolkit | |
355 | options are correct. See the above commentary about TARGETDIR. There | |
356 | are a few sample Setup.in.[platform] files provided. | |
357 | ||
358 | 3. Run this command to generate a makefile: | |
359 | ||
360 | make -f Makefile.pre.in boot | |
361 | ||
362 | 4. Run these commands to build and then install the wxPython extension | |
363 | module: | |
364 | ||
365 | make | |
366 | make install | |
367 | ||
368 | ||
369 | 5. Change to the $(WXWIN)/utils/wxPython/demo directory. | |
370 | ||
371 | 6. Try executing the demo program. For example: | |
372 | ||
373 | python demo.py | |
374 | ||
375 | ---------------- | |
376 | Robin Dunn | |
377 | robin@alldunn.com | |
378 | ||
379 | ||
380 |