Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

WxPython in Action 77

Posted by samzenpus 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 in Action
author Robin Dunn and Noel Rappin
pages 552
publisher Manning
rating 10
reviewer Ron Stephens
ISBN 1-932394-62-1
summary An introduction to the WxPython GUI Framework


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 bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

WxPython in Action More

WxPython in Action

Comments Filter:

  • About time (Score:3, Funny)

    by cagle_.25 ( 715952 ) on Monday July 10, 2006 @04:24PM (#15693525) Journal
    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.

    • Comment removed (Score:4, Informative)

      by account_deleted ( 4530225 ) on Monday July 10, 2006 @04:27PM (#15693549)
      Comment removed based on user account deletion
      • Hmmm...looks like they got a win32 port since I looked last. Thanks!

      • Re:About time (Score:4, Informative)

        by WoLpH ( 699064 ) on Monday July 10, 2006 @04:55PM (#15693744)
        Another (imho pretty good) alternative, PyQT [riverbankcomputing.co.uk].

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

      • And PyGlade (Score:2, Informative)

        by malverian ( 563649 )
        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 document
        • 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.
          • 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 (Score:2, Interesting)

        by LaissezFaire ( 582924 )
        Unfortunately PyGTK is slow and buggy (crashes) on Windows, as the good folks over at http://www.gajim.org/ [gajim.org] have discovered. It makes it less useful cross platform, though on linux it runs well.
      • 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 pow
      • Another alternate to WxPython is Dabo [dabodev.com].
        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.

  • On a related subject... (Score:3, Interesting)

    by RyanFenton ( 230700 ) on Monday July 10, 2006 @04:26PM (#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... (Score:5, Informative)

      by Anonymous Coward on Monday July 10, 2006 @04:34PM (#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.
      • 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... (Score:5, Interesting)

        by Profane MuthaFucka ( 574406 ) <busheatskok@gmail.com> on Monday July 10, 2006 @09:11PM (#15695176) Homepage Journal
        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.
    • You probably want GLUI. http://www.cs.unc.edu/~rademach/glui/ [unc.edu] It's a widget toolkit that runs on top of glut.
    • You might want to take a look at pyFLTK [sourceforge.net], based on the excellent FLTK [fltk.org] (Fast Light Toolkit). FLTK's got very good OpenGL support, and from the pyFLTK Examples [sourceforge.net] page it looks as though pyFLTK supports it as well.
    • I believe PyQt [riverbankcomputing.co.uk] 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 [riverbankcomputing.co.uk]; people there are exceedingly competent.
      Hope this helps, and have fun!

  • The book talks about ... (Score:4, Informative)

    by rabalde ( 86868 ) on Monday July 10, 2006 @04:29PM (#15693567) Homepage
    ... wxPython [wxpython.org], "a blending of the wxWidgets C++ class library [wxwidgets.org] with the Python programming language [python.org]". Please, do not forget to put links on the articles, because the /. effect need'em.

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

    by Ursus Maximus ( 540370 ) on Monday July 10, 2006 @04:36PM (#15693618) Homepage
    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 http://sourceforge.net/projects/waxgui [sourceforge.net]
  • I just wish they had not called the book "strong meat".
  • Gee... I haven't figured out AJAX yet, and this comes along. What's a poor, confused programmer supposed to do?
    • Ignore it mostly, until it becomes relevant to you.
      • 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.
        • 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!
    • erm.

      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 wou
    • Forget Ajax, you'll find regular soap and a sponge work just as well.

      Ah, wait... never mind.

  • Nice, but... (Score:3, Insightful)

    by Angst Badger ( 8636 ) on Monday July 10, 2006 @05:06PM (#15693828)
    ...it 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.

  • 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 wxWidg

    • Over at ShowMeDo.com we have 5 introductory videos [showmedo.com] 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.
  • 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.

    • 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 http://pythoncard.sourceforge.net/ [sourceforge.net]

  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Monday July 10, 2006 @05:27PM (#15693962)
    Comment removed based on user account deletion
    • 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.)

    • 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 yo

    • 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.
    • 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 wxP
  • 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.
  • "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 [wxwidgets.org] are amongst the ugliest OS X UIs I have ever seen.
    • 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
      • "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.
        • 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 desi
  • 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....
  • 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.)

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

      For windows, I use py2exe and have a custom script that makes an innosetup [jrsoftware.org] 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 [pythonmac.org] 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-

  • 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 bu

  • The book is great for beginners (Score:3, Informative)

    by MrBlic ( 27241 ) on Tuesday July 11, 2006 @08:08AM (#15696991) Homepage
    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 [amazon.com] 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 [anthemion.co.uk] 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 [wingware.com] 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 [osafoundation.org], 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.

    -Jim

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close