Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

WxPython in Action

samzenpus posted more than 8 years ago | from the snakes-on-a-computer dept.


aceydacey writes ""WxPython in Action" is a new and definitive guide to the popular wxPython GUI framework. WxPython has been growing in popularity by leaps and bounds in recent years but has been hampered by a comparative lack of good, comprehensive documentation, so much so that many people have turned to studying the documentation for the underlying wxWidgets framework, that is written in C++. "WxPython in Action" fills the void by combining a good introduction to the framework with a comprehensive and accessible reference document. At 552 pages, Manning Publications has produced a definitive book." Read the rest of Ron's review.

WxPython is one of the best cross-platform GUI toolkits for the open source Python programming language. It excels in matching the native look and feel of programs on Windows, Linux, and Mac OS X. It is a mature project, being a well-developed wrapper of the underlying wxWidgets C++ toolkit. Another reason for its growing popularity is its very extensive number of widgets, making it a capable and modern tool for making professional-looking GUIs for applications in almost any field of endeavor. It has endured a reputation for having a steep learning curve, and for sometimes being difficult to install and easy to break during upgrades; both of which downsides should be lessened by the publishing of this book.

Written by Robin Dunn, the creator and moving force behind wxPython, and ably assisted by Noel Rappin, this book is definitive, authoritative and well-written. Part 1 fills the role of a good introduction to the toolkit, and Parts 2 and 3 are a thorough reference to the widgets, behavior and usage of the framework.

in Part 1, we learn the inside story behind the beginnings and the history of wxPython's development. We are walked through the creation of simple examples of the core functionality of the framework illustrating how to create and use the basic controls and event loops. Then, we get a more detailed explanation of the wxPython event loop, an introduction to PyCrust (a useful tool for wxPython programmers, essentially an interactive interpreter session, wrapped as a wx widget) a whole chapter on the Model-View-Controller paradigm, and a discourse on good factoring techniques for GUI programs. This is rather general programming knowledge, not necessarily specific to wxPython, and truly expert programmers will probably skip much of this material, but for many, like me, it is very useful, and for many others, it will be a good review of previously known material. The writing style is excellent but one weakness is that the authors return again and again to wxPython evangelism and boosterism, which is regrettable; but this is the only section of the book to suffer from this flaw.

Part 2 gives detailed coverage of each widget, control, frame, dialog, and menu in the toolkit, and this is the meat of the book and will be used and reused as core reference material by many a programmer. This is good stuff, thorough, well researched, and definitive. Next, the authors give an equally good explanation of how to use sizers and grids to layout and control your GUI application. Part 2 fills the previously missing gap in core wxPython documentation and, to folks who need it, is worth its weight in gold.

Part 3, called Advanced wxPython, gives welcome coverage to advanced layout and control issues. This subject of advanced layout is, in my opinion, where the rubber really hits the road in GUI design, and it is appropriate that this is where the authors spend the most time and effort, and with good result. The final chapter breaks new ground by walking the reader through the creation of a multithreaded wxPython application. This is great stuff, and the advanced readers will be left pining for even more on this timely topic of such growing importance. Fortunately, the authors are available online to communicate with users who truly master the material in the book and want to to pursue more advanced usage.

The book is at its best in documenting the core API for expert programmers who are new to wxPython. It is also a good introduction to wxPython for advanced programmers. For moderately experienced programmers, the book is excellent but will be a tough read; probably not to be mastered in a straight read thorough, the book will adequately reward this kind of reader who is dedicated and persistent. For novice programmers, especially those who have little to no previous experience in GUI programming, I believe the book may be beyond their grasp.

So, if you are a serious programmer who wants or needs to use the wxPython GUI toolkit, "wxPython in Action" is a must-have reference book. It is perfect for this kind of reader and will become a well-worn book that will be useful for at least the next five years. It is unlikely that any other book about wxPython will be published that could do a better job, given the authors' unparalleled understanding of the toolkit and the obvious patience, time and care they took in researching, writing, and editing this book. It is not a casual read, but to a serious student of the subject, that is a positive statement. The book is strong meat, a weighty and substantive technical tome.

The book really shines in the many pages devoted to User Interface design and implementation. This is where many programmers need help, and it is gratifying that this book goes into the most detail on this subject. This is very detailed coverage and one is left with a satisfaction that, while not easy reading, it is well worth while. I feel this is the book's strongest point.

I know that it sometimes seems there has been an inflation in the scoring of books, with reviewers giving so many high ratings that one wonders how meaningful those ratings are. This book is not for everybody, and it is not a work of great literature, but given the obvious need for such a work, and the careful and accurate fulfillment of this need by these authors, I feel justified in giving it a rating of ten stars. For the people who really need this book, it is about as good as it could get, and will be a most welcome addition to their technical library.

More material for those learning and using Python can found at my web site Python Learning Resources.

You can purchase WxPython in Action from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×


Sorry! There are no comments related to the filter you selected.

Python. (-1)

Anonymous Coward | more than 8 years ago | (#15693516)

In my wxPants.

About time (2, Funny)

cagle_.25 (715952) | more than 8 years ago | (#15693525)

For those of us stuck using Tkinter because time did not permit digging through the wxPython docs, this will be a welcome addition.

Good review, BTW.

Re:About time (3, Informative)

CRCulver (715279) | more than 8 years ago | (#15693549)

If you don't want to use Tkinter and hate the obtuseness of WxPython, there's always PyGTK [] .

Re:About time (1)

cagle_.25 (715952) | more than 8 years ago | (#15693630)

Hmmm...looks like they got a win32 port since I looked last. Thanks!

Re:About time (4, Informative)

WoLpH (699064) | more than 8 years ago | (#15693744)

Another (imho pretty good) alternative, PyQT [] .

Using the QT widgets it's cross platform (Linux, BSD, Windows, others?) and pretty fast :)

And PyGlade (2, Informative)

malverian (563649) | more than 8 years ago | (#15693904)

Combining PyGtk and PyGlade is one of the most amazing user interface programming experiences I've ever had. That is to say, it's not completely unbearable. My favorite feature by far is that if you have a class (let's call it "InterfaceSignals"), you can call signal_autoconnect(InterfaceSignals) to automagically connect every method in that class to the respective signals defined in your Glade file, due to Pythons wonderfully introspective nature.

Also, unlike wxPython, pyGtk actually has very nice documentation. For reference, here's the signal_autoconnect method I mentioned: l.html#method-gladexml--signal-autoconnect []

Re:And PyGlade (1)

blackpaw (240313) | more than 8 years ago | (#15694111)

You think thats a great features ? bloody hell, auto connection of events to code has been a basic feature of every windows RAD ide for over a decade.

Re:And PyGlade (1)

MikeBabcock (65886) | more than 8 years ago | (#15697517)

Its been a feature through hacks and language extensions.

This is a natural ability of the Python language, not a comment-based hack into your C++ code that breaks when you change whitespace.

And trust me, I've written my share of Visual C++ code in the last 5 years.

PyGTK is not as mature as Visual C++ for example, but it is much nicer to write 90% of your code in. The other 10% you have a lot of time left to work on, so its still nicer in the long run.

Re:About time (2, Interesting)

LaissezFaire (582924) | more than 8 years ago | (#15694017)

Unfortunately PyGTK is slow and buggy (crashes) on Windows, as the good folks over at [] have discovered. It makes it less useful cross platform, though on linux it runs well.

Re:About time (0)

Anonymous Coward | more than 8 years ago | (#15697664)

No it's not. I've been programming pyGtk on Windows full time for 6 Month and it has not crashed once (apart from my own mistakes). Seems like you base your MS Windows GTK experience on Gimp. Pure GTK on Windows is dead stable and it feels faster than on Linux, probably due to not running XWindows. I started using WxPython but things like the Rich text widget cant be trusted on all platforms so I had to switch.

Re:About time (1)

bth0002 (458440) | more than 8 years ago | (#15695999)

This framework is perfection.

I wish I could bundle at least one part or component for it. It is absolute perfection though, I'm not sure if the gui needs work or the plugins. I would wish to work on a component of some sorts. I hope google supports it or microsoft. Compared to xtools it is smooth sailing (anybody have a great pyobjc project to encompass them all).

Man a great mac add on or all of windows would be nifty. Linux should be proud to have something so easy to use yet ultimately incredibly powerful. Long live wxWindows and wxPython. Please please developers of great might and worthiness support this. If not I'll just print the source code and place it in a shrine.

But after all its perfect,wouldn't change a thing. I hope new frameworks can learn from it perhaps. May there be many.

Installing PyGTK for Windows not childs play (0)

Anonymous Coward | more than 8 years ago | (#15696751)

Try installing PyGTK and its dependencies on a Windows machine without going through the sources. It is a minor hell, and easily turns into a recursive one at that (frames opening itself withing its content frame).

I don't mind (Py)GTK at all, but its suckiness to install for the general user is a problem.

Re:About time (1)

OshEcho (971542) | more than 8 years ago | (#15714073)

Another alternate to WxPython is Dabo [] .
From the site: "Dabo is a 3-tier, cross-platform application development framework, written in Python atop the wxPython GUI toolkit."

I find it much more pythonic and easyer to use than WxPython.
Even though Dabo comes with code pertaining to database interaction, the GUI part is completely separated and you can just use the GUI part.

Re:About time (0)

Anonymous Coward | more than 8 years ago | (#15694469)

Well Done Robin.

I've been using wxPython for many years now, and it has been excellent for developing apps on Windows and Linux. Riaan Boyson's Boa Constructor has been invaluable as well.

On a related subject... (2, Interesting)

RyanFenton (230700) | more than 8 years ago | (#15693538)

I've been planning an opengl project with a GUI in it for image editing, using Python for scripting. Would it be possible/plausible to render from from a GUI toolkit like wxPython into a texture to load into opengl, so that the window could be part of a world, rather than enclosing an OpenGL widget into a wxWidgets/wxPython framework?

Ryan Fenton

Re:On a related subject... (5, Informative)

Anonymous Coward | more than 8 years ago | (#15693606)

Not really. Nearly all GUI toolkits allow putting the widgets outside of the GL Canvas, but what you speak of would involve mucking with way too much evil. Essentially you can get the bitmap for any active window in WX, but mapping the event models back and forth would require some extreme skill -- and quite a performance hit. You'd have to manipulate the wx API programatically and do all the mapping translations yourself.

That being said, wxPython rocks. I wrote wxPython code for a living for about a year and came away with a great respect for it. Printers and the like ... they all work. I didn't bother with the socket/thread stuff since Python can do that, but in all it's pretty nice. Layout was a bit annoying, but not nearly as bad as Swing. My advice... write all your code programatically using sizers and don't use the glade-like editor at all.

Re:On a related subject... (1)

Mitchell Mebane (594797) | more than 8 years ago | (#15694098)

I seem to remember reading somewhere that Qt allows you to place widgets on an OpenGL canvas and have them drawn with OpenGL. Not sure about that, though, and I can't find what I though I read, so it may be a false recollection. :/

Re:On a related subject... (5, Interesting)

Profane MuthaFucka (574406) | more than 8 years ago | (#15695176)

Not my experience. I found wxWidgets in general to be full of bugs, to the point where the display errors I was getting were making it impossible to use. For example:

1) fill a tree widget with a few thousand items. You've got lines going everywhere.
2) The latest library upgrade screwed with the layouts so that what formerly used to fill the entire window now filled only the upper left corner.
3) The date widget screws up every time there's a daylight-savings change. If the change happens on April 1st, the date selection widget will display March 30. On April 2nd, it's working again.

That's just three, but I've seen many more. By comparison, I'm very experinced with Swing, QT, MSFC, and Tk, and none of those displayed the kinds of problems that I saw with wxWidgets.

And when I say wxWidgets, I mean the library in general. I've programmed all of the above GUI libs mentioned in multiple languages, and wxWidgets behaved with similar bugginess in wxPython too.

The wxPython API definitely does rock, but there's a lot of bugs. I tried to dig through the code to see what was going on, and I found that to be a huge mess too. I've been through the Qt code, and it's pretty well organized and definitely well written. wxWidgets appeared to be due for a refactoring and cleanup to make it easier to work on.

Re:On a related subject... (0)

Anonymous Coward | more than 8 years ago | (#15696784)

2) The latest library upgrade screwed with the layouts so that what formerly used to fill the entire window now filled only the upper left corner.

I also have this problem. I find if I resize the window it snaps back to a proper layout. I'm only using it to code for myself so I haven't minded too much.

Using .Layout on the Sizer doesn't work to fix the layout. :(

Re:On a related subject... (1)

Azarael (896715) | more than 8 years ago | (#15693840)

You probably want GLUI. [] It's a widget toolkit that runs on top of glut.

Re:On a related subject... (1)

Helmholtz Coil (581131) | more than 8 years ago | (#15694461)

You might want to take a look at pyFLTK [] , based on the excellent FLTK [] (Fast Light Toolkit). FLTK's got very good OpenGL support, and from the pyFLTK Examples [] page it looks as though pyFLTK supports it as well.

Sure. (1)

Balinares (316703) | more than 8 years ago | (#15694527)

I believe PyQt [] will let you render widgets into an OpenGL context without complaint. OpenGL is but one of the rendering backends that it supports. At any rate, you might want to ask on the PyQt mailing-list [] ; people there are exceedingly competent.
Hope this helps, and have fun!

The book talks about ... (4, Informative)

rabalde (86868) | more than 8 years ago | (#15693567)

... wxPython [] , "a blending of the wxWidgets C++ class library [] with the Python programming language [] ". Please, do not forget to put links on the articles, because the /. effect need'em.

Perl (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15693571)

I was going to read this book review, but then I remembered that I like Perl.

Re:Perl (3, Funny)

gregarican (694358) | more than 8 years ago | (#15694262)

Strange. Your comment is short and rather terse, but I can nevertheless read it and comprehend it easily. Are you SURE you like Perl?

Good review, but ... (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15693614)

Yes, the book fixes an important problem with wxPython.

But it does nothing about the other main problem - that wxPython is based on wxWidgets.

Wax is also helpful to wxPython programmers (5, Informative)

Ursus Maximus (540370) | more than 8 years ago | (#15693618)

Wax is a user-friendly layer on top of wxPython. It allows for easier GUI programming in a more "Pythonic" way. It runs on all platforms that support wxPython. It can be found aand downloaded at []

Re:Wax is also helpful to wxPython programmers (4, Funny)

Abcd1234 (188840) | more than 8 years ago | (#15693754)

So... it's an abstraction layer over a wrapper of an abstraction layer to an underlying GUI toolkit? Awesome... :)

even worse.... (1)

Anonymous Coward | more than 8 years ago | (#15693919)

On windows:

Wax sits is on top of wxPython
wxPython sits on top of wxWidgets
wxWidgets sits on top of win32 widgets
win32 widgets sits on top of GDI calls

On linux:

Wax sits is on top of wxPython
wxPython sits on top of wxWidgets
wxWidgets sits on top of QT
QT sits on top of X11 calls

Any chance there's a sourceforge project to put a layer on top of Wax? To make things simpler of course...

wxWidgets linux does NOT use Qt... (3, Informative)

Mitchell Mebane (594797) | more than 8 years ago | (#15694175)

wxWidgets linux does NOT use Qt, it uses GTK. As I understand it, wxWidgets is LGPL and Qt is GPL, and writing a Qt backend would force it to be GPL. :/

Re:wxWidgets linux does NOT use Qt... (3, Informative)

AWhiteFlame (928642) | more than 8 years ago | (#15694339)

wxWidgets is not LGPL. wxWidgets is under the wxWindows (the project was renamed but apparently this wasn't) license.

Re:even worse.... (0)

Anonymous Coward | more than 8 years ago | (#15695542)


s/Qt/GTk :)

Re:even worse.... (0)

Anonymous Coward | more than 8 years ago | (#15697282)

And all that sits on top of machine code. Just write it in machine code for crissake!

good review, but... (1)

GeoVizer (724140) | more than 8 years ago | (#15693643)

I just wish they had not called the book "strong meat".

Python wrappers (-1, Flamebait)

amightywind (691887) | more than 8 years ago | (#15693657)

WxPython has been growing in popularity by leaps and bounds in recent years but has been hampered by a comparative lack of good, comprehensive documentation

That could be said about any of the 100's of shity half-finished Python wrappers that clog my Gentoo system. What a scourge. To anyone who thinks it would be nice to wrapper C/C++ library , don't do it! I would advise anyone who wants to use wXWidgets to do so in C++. The event abstraction is a lot nicer that Qt and the library is just as portable.

Plug-ins (2, Informative)

truthsearch (249536) | more than 8 years ago | (#15693730)

The one place where using the python wrapper for wxWidgets can really pay off is user scripting or plug-ins. If your app's written in python it's quite easy to allow users to write plug-ins to your app in python. Otherwise you'd have to connect your C++ app to the python interpreter to give the same ability.

I used wxPython for a while because I think it's a great alternative to VB. Coming from the VB world it was a big step up with a small learning curve. It's a good way for Windows desktop developers to get into Linux desktop development.

Re:Python wrappers (2, Insightful)

Senzei (791599) | more than 8 years ago | (#15693768)

That could be said about any of the 100's of shity half-finished Python wrappers that clog my Gentoo system. What a scourge. To anyone who thinks it would be nice to wrapper C/C++ library , don't do it! I would advise anyone who wants to use wXWidgets to do so in C++. The event abstraction is a lot nicer that Qt and the library is just as portable.
I guess I am really not following here, but how else are you supposed to handle widgets in python without some kind of wrapper over C/C++? Wouldn't doing all of it yourself be a lot more work for much less benefit than wrapping up an existing library?

Re:Python wrappers (1)

CRCulver (715279) | more than 8 years ago | (#15693860)

That could be said about any of the 100's of shity half-finished Python wrappers that clog my Gentoo system.

My Gentoo system doesn't have any wrappers whose lack of documentation is a big problem. The wrappers that go around GTK2 and the GNOME libraries have an API virtually the same as the C. If you know Python at more than a novice level, you can learn from the C documentation and just adapt it all for Python. What docs specifically were you referring to?

Re:Python wrappers (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15694061)

If you know Python at more than a novice level, you can learn from the C documentation and just adapt it all for Python.

I think if you are moderatedly competent with any language you should be able to do so. I didn't know Python or C/C++ and was easily able to use the wxWidgets docs to create wxPython apps.

As long as the wrapper syntax is logical and consistent in its differences from the underlying library, you really don't need a special function reference for the wrapper.

Another Alphabet Soup... (1)

creimer (824291) | more than 8 years ago | (#15693702)

Gee... I haven't figured out AJAX yet, and this comes along. What's a poor, confused programmer supposed to do?

Re:Another Alphabet Soup... (2, Insightful)

Duhavid (677874) | more than 8 years ago | (#15693766)

Ignore it mostly, until it becomes relevant to you.

Re:Another Alphabet Soup... (1)

creimer (824291) | more than 8 years ago | (#15698401)

That's the problem. At what point should it become relevant without actually missing the boat on something that might be important? Seems like it's a giant conspiracy to introduce new technology and/or programming fads to sell overpriced books.

Re:Another Alphabet Soup... (1)

Duhavid (677874) | more than 8 years ago | (#15699656)

Quite. That is why I put the "mostly" in.

You have to look at these things a bit when they
come up and evaluate relevance.

Maybe some things that are relevant slip.

If you figure out how to solve this problem,
let me know!

Re:Another Alphabet Soup... (1)

moro_666 (414422) | more than 8 years ago | (#15696135)


ditch ajax for a while and learn wx/gtk/qt/tk and if you have extra time, java's awt and swing.

when you have even just touched the surface with the ones noted above, you'll see what's lacking in ajax and what's not and what you should aim towards to get a non-web-compatible source layout for your application. html may leave in some years in favor of something else (yeah sure it won't directly die, but there may come a better or more advanced alternative to networked applications) and it hell as sure wouldn't hurt to be ready for it.

while most ajax sites/docs spend their time in showing 'quick solutions' (spelled `hacks`) and putting first words in sentences in uppercase, they don't even try to teach you the proper design of code itself. and that is where your future resides.

Re:Another Alphabet Soup... (1)

Fred_A (10934) | more than 8 years ago | (#15696767)

Forget Ajax, you'll find regular soap and a sponge work just as well.

Ah, wait... never mind.

Nice, but... (2, Insightful)

Angst Badger (8636) | more than 8 years ago | (#15693828) sure would be great if someone would do this for the other wx language bindings. For something as complex as a widget library, lacking comprehensive documentation renders it all but useless to anyone but folks with lots of time on their hands.

Re:Nice, but... (2, Informative)

paulli (259692) | more than 8 years ago | (#15694035) [] for javascript.

This assumes you are using javascript as a programming language and not hacking out a web page.

Re:Nice, but... (1)

ciw42 (820892) | more than 8 years ago | (#15696341)

Because most of the other bindings I've seen are pretty simple wrappers, and often direct tranlsations of the C++ library, you should just grab yourself a copy of the original wxWidgets book, which has been around now for a year or so: /qid=1152602802/ref=pd_bbs_1/102-8482942-0491367?i e=UTF8 [] .

It's very comprehensive, well written, and even for wxPython, which at times tends to do things a little differently, I was happily using this until a couple of months ago when my copy of the wxPython book reviewed here arrived.

Nice introduction, but still incomplete (2, Insightful)

bigqueso (562944) | more than 8 years ago | (#15693834)

I got this book a few months ago with the hope that it would be a nice introduction and reference. I bought it from the publisher, because I could also get a PDF version. That has been really nice since it makes it easier to look for examples.

The book was a nice introduction to someone who isn't familiar with wxWidgets or wxPython and it reads well. Despite this, I found the book to be lacking as a good reference book. The index is kind of sparse, and I found myself turning more and more to the wxWidgets and wxPython web sites and as a reference for specific widgets. I don't plan on taking my copy back, but I instead use it as just one more avenue for information.

Re:Nice introduction, but still incomplete (0)

Anonymous Coward | more than 8 years ago | (#15694044)

I second that. Having used wxPython for more than a year, I found the book to be of little value. Google is still the best (only?) way to piece together the knowledge needed to get wxPython to do what you want it to do (beyond the simplest examples, that is; once it works, it works great, of course).

That's too bad because I think that Robin Dunn deserves some financial reward for the years of support of wxPython...but this book isn't going to find its way to every wxPythoneer's bookshelf. (But I "voted with my wallet" and bought it anyway.)

Robin, if you're listening, an book with advanced examples, recipes and how-tos would be much appreciated.

Re:Nice introduction, but still incomplete (1)

ianOz (988378) | more than 8 years ago | (#15704185)

Over at we have 5 introductory videos [] for wxPython covering installing, a 'hello world' test, a first application, a menubar and simple event handling. They are each around 10 minutes long and ought to be very useful to anyone new to wx. All of our videos are QuickTime 6 movs, later we'll have Flash too. Most of our videos are for Python and Java, all great for newbies.

check out PythonCard (1)

Eponymous Coward (6097) | more than 8 years ago | (#15693851)

I've been using PythonCard to wrap simple gui's around some of my simple scripts. It is build on top of the wxPython toolkit and makes python-based gui's incredibly simple. Maybe not quite as slick as HyperCard was, but it has definitely hit a sweet spot for me.

Re:check out PythonCard (2)

Ursus Maximus (540370) | more than 8 years ago | (#15694075)

I just want to say that I agree about PythonCard. It is very easy to use and it rivals VB or Delphi in making it easy to draw a simple GUI front end for data entry and such, and yet it is a simple tool with almost no learning curve. I don't know if it would work for every imaginable application, but for most applications it is a real joy to use. PythonCard can be found at []

Save $18.48 by buying the book here! (0)

Anonymous Coward | more than 8 years ago | (#15693955)

Save yourself $18.48 by buying the book here: WxPython in Action [] . And if you use the "secret" discount [] , you can save an extra 1.57%! That's a total savings of $18.97, or 38.57%!

Someday OSS developers will learn (2, Insightful)

MikeRT (947531) | more than 8 years ago | (#15693962)

Most other programmers don't want to have to hunt down and really play around with parts of a toolkit to understand it and use it well. For most people, WxPython would probably be a hobby GUI toolkit. Who wants to spend more time learning the API than making cool little apps or making a serious one with it? Very few.

Yes, yes, I know they are doing this in their spare time too. I'm not complaining. I'm just saying that when people can choose between well-documented free toolkits from big companies or poorly documented open source ones, the former will usually win.

Re:Someday OSS developers will learn (1)

1iar_parad0x (676662) | more than 8 years ago | (#15694023)

I was going to post the same thing, but you beat me to it. Frankly, I got by using MySQL with an OReilly book (I could have skipped that) and the online documentation. Good online documentation can be enough if it's properly written. Organization and presentation are everything and MySQL, in my opinion, does the best job among OSS projects. (Yes, I even think PostgreSQL is the better database.)

Re:Someday OSS developers will learn (0)

Anonymous Coward | more than 8 years ago | (#15694025)

I'm just saying that when people can choose between well-documented free toolkits from big companies or poorly documented open source ones, the former will usually win.

Excellent. Please provide a link to the well-documented free toolkit from a big company that runs on Linux. (No, Java doesn't count.)

Re:Someday OSS developers will learn (2, Informative)

pnot (96038) | more than 8 years ago | (#15694163)

Please provide a link to the well-documented free toolkit from a big company that runs on Linux.

Qt [] from Trolltech [] is Free [] , extremely well-documented [] , and runs on Linux and several Unix flavours [] as well as Mac OS X and Windows.

Re:Someday OSS developers will learn (1)

Doches (761288) | more than 8 years ago | (#15694036)

I disagree. How many "hobbyists" would be willing to shell out the cash for a proprietary toolkit? True, the documentation is likely to be better and you can probably get 'trial' or 'personal' versions for free, but there will come that inevitable moment when said hobbyist says to himself "I've got a pretty cool little app here, maybe I should release it." What's he going to do then? Spend $100 for a QT license* so that he can give the world his free tool?

On a related note; how many hobby developers do you think are writing web applications in Coldfusion? Not many! Why? Because they're all using PHP or Ruby; tools that leave them free to work (and release!) without any financial cost.

Admittedly, these are both bad examples, since QT has been free for most platforms for quite a while, and both PHP and Ruby have excellent documentation. But still, you get my point.

Re:Someday OSS developers will learn (1)

Psiren (6145) | more than 8 years ago | (#15694161)

I'd have to agree there. Several years back I started writing an MUA in GTK. I gave up after a few months and started again using Qt and KDE, since the documentation at the time was far superior. The GTK documentation was absolutely terrible in comparison (they hadn't even finshed documenting GTK v1 before GTK v2 was released), but hopefully it has improved a lot since then. I really have to congratulate Trolltech and the KDE guys though, they've done a fine job.

Re:Someday OSS developers will learn (1)

kollivier (449524) | more than 8 years ago | (#15695149)

Are you saying you've used wxPython and had problems with it, or that you are not using it because it lacks documentation, or something else? I'm curious to know what parts you had problems with.

I went from "playing around" with wxPython to using it full-time to develop a real-world app over a matter of weeks, which really isn't all that bad. There were a few sticking points, but I never found the process all that difficult. You do have to bear with the C++ style arguments in the wxWidgets docs, but the wxPython demo is about the most effectively learning tool I've come across for learning a toolkit. I just wish I could have edited the demo in real time, like you can do now, to help learn the toolkit. :-)

There's also the wxPython Cookbook in the wiki, and the like, which cover a lot of specific topics for wxPython development. Maybe some of this stuff isn't visible enough on the wxPython site?

Awesome (1)

CodemasterMM (943136) | more than 8 years ago | (#15694070)

wxWidgets (for C++ or for Python) is a great GUI toolkit - the learning of it is a bit harsh, though, as there isn't a great booklet of tutorials or how-to's; mostly, you're left to fend for yourself.

Glad to see they're at least making books that'll help you out.

Wx does NOT excel in matching OS X (1)

Beniamino (21297) | more than 8 years ago | (#15694439)

"It excels in matching the native look and feel of programs on Windows, Linux, and Mac OS X."

I strongly disagree with this statement. The OS X example programs here [] are amongst the ugliest OS X UIs I have ever seen.

Re:Wx does NOT excel in matching OS X (2, Insightful)

kollivier (449524) | more than 8 years ago | (#15695022)

Have you run the wxPython demo? Or are a couple random screenshots enough to get you to "strongly disagree" about something? There are still a couple controls that need work on the Mac port, but a vast majority of its controls are 100% native and match native behavior as closely as possible. (In the cases that the OS doesn't just 'give it to us' for free.)

wx, however, is like any other toolkit. It doesn't force you to adhere to HIGs, and unfortunately many Mac ports are from Win/Linux apps, and focus their resources on those ports because, sadly, that's where the users/customers are. A number of wx apps don't even support Mac, not because they can't, but because they simply don't have (enough) users that are interested in the Mac port. As Mac customers and support becomes more important, so too will the number of applications that optimize for Mac, and let me tell you, those that used wx will find they can probably polish their GUI in a matter of days.

And in fact, we're working on cutting the work needed for HIG-compliance on all platforms too. At the wxPython level, we're working on additions to wx controls that are automatically HIG-compliant for Win, OS X and GNOME/GTK. So long as you use this library, your controls will space themselves according to the HIGs. If you're really interested in cross-platform development, I'd strongly encourage you to look at what's out there and then determine if wx is really such a bad choice for getting native Mac LNF.

Re:Wx does NOT excel in matching OS X (1)

Beniamino (21297) | more than 8 years ago | (#15701673)

"are a couple random screenshots enough to get you to "strongly disagree" about something?"

Seems to me those "random screenshots" were chosen to be good examples of what can be done with wx on OS X. They're all dreadful. If you know of better examples, I suggest you add them to the gallery.

Re:Wx does NOT excel in matching OS X (1)

kollivier (449524) | more than 8 years ago | (#15702313)

As I said before, it is a screenshot of what "can be done" on OS X - e.g. what UI elements are available, and what options there are for doing custom-drawn controls/UI elements (such as a whiteboard). It puts a lot into one screenshot, and it's not necessarily an example of how to win an Apple Design Award.

UI design has little to do with the wx toolkit and a lot to do with how an application designer understands, cares about and adopts interface design principles. Tools are tools; they don't do your UI design for you, they simply help you implement that design. For something with a more OS X-style UI, take a look at this: []

However, they're still in the process of working on the application, and as a result there are still a couple minor bugs in their UI; overall, though, it looks quite solid and uses many modern UI conventions.

When you spend a few seconds looking into a toolkit, a lot of things can "seem" a certain way without really being true. wx is being used for modern app design, but that's mostly a result of projects like Firefox which have made a lot of developers start to re-think the importance of a good UI. As a result, there aren't a whole lot of totally finished modern UI apps to show off yet. (The commercial sector jumped on this quickly, of course, but they've got the resources for it.)

Multi-threading is convered Yay (1)

impurist (946776) | more than 8 years ago | (#15694526)

After reading this review I am sold. I just spent a week writing a wxPython app for logging data from an echo sounder on a research boat. The big learning curve was the threading aspects. It appears threading is pretty much an essential part of this kind of GUI programming. Especially if you need to process in the background and still use the GUI. I really enjoyed this experience and have flagged wxPython as my cross platform framework of choice! Now I reckon I am off to buy that book....

Easy path to SETUP.EXE and Mac OS X equivalent? (1)

dstone (191334) | more than 8 years ago | (#15695501)

I've developed some simple WxPython apps on Linux, destined for use on Linux systems that already have WxPython, Python, and other libraries installed. That's easy. So thinking broader now...

If I was to embark on a moderately complex GUI app destined for Mac OS X, Windows, and Linux use (on systems with no previous Python or WxPython), am I asking for a headache or can someone speak from the experience of doing this? (Runtimes, dependencies, SETUP.EXE or whatever is necessary for OS X and Win32, etc.)


Re:Easy path to SETUP.EXE and Mac OS X equivalent? (0)

Anonymous Coward | more than 8 years ago | (#15696325)

MacOS X 10.4 comes with wxPython. wxPython application however must be run with pythonw rather than python on OSX.

For building an application bundle have a look at Platypus (

Re:Easy path to SETUP.EXE and Mac OS X equivalent? (0)

Anonymous Coward | more than 8 years ago | (#15696819)

Yup, although not sure if these will help with distributing to MacOS users...

pyInstaller (
py2exe (
InnoSteup ( ...and just to continue with the PythonCard propaganda, see also this page: []

and here, just to ensure that my web server gets the full benefit of the slashdot effect: []

Re:Easy path to SETUP.EXE and Mac OS X equivalent? (1)

yerM)M (720808) | more than 8 years ago | (#15697168)

Yes. I have a wxPython app that runs on Linux/Windows/Mac, it is located at Slims [] .

For windows, I use py2exe and have a custom script that makes an innosetup [] install file. If you are interested, I can dig up this script for you (I think it should actually be a distutils setup, that would be nice) however, they are trivial to make.

For OSX I use BundleBuilder [] which generates mac bundles and is really, really nice especially since OSX comes with python pre-installed. I even use this script to create non-python bundles.

For linux I use PyInstalelr [] and tarballs [] :) There is really no good consistent linux installer, but I have had some success with PyInstaller.

Good luck!

Re:Easy path to SETUP.EXE and Mac OS X equivalent? (0)

Anonymous Coward | more than 8 years ago | (#15699633)

BundleBuilder is no longer being maintained.

However, Py2App is, and it's an excellent alternative. For the most part, iot "jsut works" and builds a completely self-contianed application bundle, even with a "universal build", that is, one that will run natively on both Intel and PPC macs. []

With Py2App and Py2exe, you've got what you need.

By the way, bitpim has a nice set of scripts for bundling itself up in Linux, Mac and Windows, it's worth checking out that source.


wxPython = wxWidgets = wyoGuide (1)

wysiwia (932559) | more than 8 years ago | (#15696093)

First wxPython is just the Python interpretation of wxWidgets. There are many more bindings for almost any practical language. There's no need to use Python, you can use whatever you like.

Second all the nice features (e.g. cross-platform, native look) are because of wxWidgets which main language is C++. I don't think C++ is the nicest language yet when it comes to design and write a rather full featured and complex application, there's currently no other choice.

Third when you want write not only ordinary but excellent applications you should follow the wyoGuide guidelines (which fit perfectly with wxWidgets). I haven't read the book so I don't know if references and uses wyoGuide but if it doesn't I wouldn't recommend buying it.

O. Wyss

Re:wxPython = wxWidgets = wyoGuide (0)

Anonymous Coward | more than 8 years ago | (#15696876)

wyoGuide = Your self-aggrandizing 'guide' on how to develop applications = big ego!

Fanboy (0)

Anonymous Coward | more than 8 years ago | (#15696846)

I bought this when it was first released. I had done a lot of wxPython work previously, and before that wxWidgets/Windows (the C++ API it wraps), and I was so familiar with wxPython I didnt think I needed to buy the book. I'm glad I did though, because it contains enough little gems to make it worthwhile. And for novices or less experiences developers it is pretty much an essential purchase.

My experience with wxPython has been pretty positive. Sure, I have ran in to a few bugs in the Python API, and some in the underlying C++ that are merely exposed by the Python wrapper, but they have been easy to work around and they were fixed in later versions. Development of wxPython is very active, there are full time developers paid for by the Open Source Applications Foundation [] and lot of people using it both profesionally and at a hobby level.

The applications I have created with it fairly simple - Food File [] (a nutrition database) and Celebrity Magnet [] (an image search engine) - but I wouldnt hesitate to use it for more complex gui projects. In short, I'm a complete fanboy!

Will McGugan (blog) []

The book is great for beginners (2, Informative)

MrBlic (27241) | more than 8 years ago | (#15696991)

Having used wxPython for just a few small projects, and currently one very large one, I found that the book was appropriate for someone who was just getting started. WxWidgets and wxPython can do much more than this book would suggest.

I keep it on my bookshelf next to the wxWidgets book [] and end up reaching for the wxWidgets book more often, even though I'm using wxPython.

I agree with the other poster who suggests that people code GUIs with sizers instead of using the XRC resources, although if you have multiple people on a project, and one or two want to change just the GUI, then the XRC, along with Dialog Blocks [] would be a perfect combination. The trick to making the gui stuff quick even though it's in code is to configure your favorite text editor with snippets or aliases or whatever it calls them to have lots of fill-in the blanks templates for things like a staticText / Edit box row in a dialog. I have a good collection of VisualSlickedit aliases I'd be happy to send to anyone who e-mails me at: jim at maplesong dot com.

wxPython is easy to debug too. I'm coding my application partially in C++ wxWidgets, and driving the complex gui parts in wxPython. I have my wxPython extension dll in a visual studio project, and I point the "when debugging run:" to python itself, with an argument that points to my script. I can set breakpoints in my C++ code, and they are hit when I get to the right place in the wxPython gui. I can simutaneously use Wing IDE [] from Wingware to debug the python code. The trick is the python actually initiates the conversation with the debugger through sockets... the debugger just has to be in 'passive mode' to accept the connection.

Unlike the other posters, I have not run into anything buggy. Everything has been solid, and has made sense, and for the most part worked the first time every time, even mostly on OSX. (I start off on Windows.) The only troule I've had on Linux/GTK is controlling the font size in the HTML windows. (wxWidgets has a simple but fantastically useful lightweight HTML layout widget!)

I'm really hoping that Google comes around to putting some support into wxWidgets & wxPython. It already has great support from Mitch Kaypor and the OSAF [] , and AOL has used it for their communicator, and lots and lots of small shops have used it successfully, as well as several open source projects... Ok, it's doing fine.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?