As they say, all good things must come to an end. However no matter how much you expect the inevitable, it's still a bit of a downer when it does happen.

The Open Source Applications Foundation has been sponsoring my work on wxPython for about 5 years now. I spend about half of my time working on Chandler, supporting the other OSAF engineers with wxPython questions or problems, or in working on specific needs that OSAF has in wxWidgets or wxPython itself. I'm free to spend the other half of my time working on wxWidgets or wxPython in whatever way I want. Typically I use a big chunk of this time supporting the wxPython community, answering questions on the mail lists, tracking down bugs that people report, etc. but I also work on other features or long-term goals for wxPython that may not necessarily line up with some immediate need that Chandler has. It's been a real good deal for everybody involved. I've been able to get paid for working on my favorite hobby, the Chandler project has gotten the support and expertise that they needed, the wxPython community has also had a large block of my time and attention, and wxPython itself has had many improvements and enhancements that I likely would not have had time for otherwise.

This week OSAF announced a restructuring and downsizing of the Chandler team. They want to shift the focus more towards gaining more users and, since it is an Open Source project, the building up of a volunteer developer community. The other goal behind the transition is a desire to stretch out the remaining funding until the project can find a way to become self-sustaining. As you've probably guessed by now, I was not one of the worker bees kept in the hive. I've got a few weeks left on my contract and then I'll be making my own transition to something else. Although I've known this was coming, I didn't expect it until the end of this year, so it's still a bit of a disappointment.

So what does this mean for wxPython? Hopefully nothing, other than some reduction in the time I am able to spend focused on wxPython. It would be great to be able to find someone willing to support my working on wxPython part time like OSAF did, but it's probably pretty unlikely that that particular lightning will strike in the same place twice. On the other hand, I expect that my next gig will be something that at least uses wxPython so there will be some opportunities for some of that work to roll down to wxPython and the community. Of course, on the gripping hand, if you or somebody you know would be interested in sponsoring at least part-time work on wxPython, please do contact me.

Update: This news was noticed by the New York Times.

I've just released the new 2.8.7.1 build of wxPython. This release has had some bugs fixed, some minor patches applied, and also incorporates the Google Summer of Code 2007 version of XRCed, and adds the Editra source code editor. More details can be found in the changes list. wxPython source and binaries for Windows, Mac OS X and Fedora can be downloaded from the download page. Binaries for Debian and Ubuntu i386 and amd64 architectures are available in the wxWidgets APT repository, see this wiki page for details.

NOTE: On Mac OS X 10.5 (Leopard) the Python 2.5 binaries of wxPython expect to be used with the user-installed version of MacPython, not the Apple installed version. A fix for this issue is being worked on for the next release. In the meantime you can either install MacPython 2.5.1 and adjust your paths so that that Python is used, or you can stick with Apple's Python and the wxPython 2.8.4.0 that comes with Leopard.

Happy Hacking!

Last week on wxPython-users a user wrote about a particular GUI class and said that, "it looks really awful." Trying to get more details from the person about what is so bad about it only resulted in some confusion because he seems to really like the class and listed some nice features when asked, "in what way is it awful?" Well, as you can probably guess, it turns out that English is not his native language and he intended to say that the GUI class in question filled him with awe, or in other words, that it is "really awesome."

This got me to thinking about something that has probably crossed every computer scientist's mind at one time or another: It's too bad that our spoken and written word can't be passed through something like a syntax check, preprocessor, lint, or a compiler. Just think how many problems could be caught before the communications arrived at the listener's auditory or visual interface! If we could communicate person to person using something that is as clean and as structured as a programming language like Python then I think that there would be a lot less confusion in the world. If our spoken word would fail to compile if it is incorrectly spoken, and if it failed to run if the assumptions it was built upon were incorrect, or were not fully specified then when what is spoken does successfully execute then there would be a much higher level of comprehension at the receiving end, and a high level of trust that what was received was exactly what was intended to be said. Using a structured communication mechanism like a programming language would also allow for clear and unambiguous responses or acknowledgments that what was said was received by the listener, and understood.

There would still be bugs of course, since nobody is perfect. But I expect that if you look at the number of times that what you speak or write is misunderstood or misinterpreted, or even just ignored, and compare that to the number of bugs in your software that have made it out to the customers, then I think that for almost all of us there would be a huge difference in those numbers. So what do you think, can Python 4000 be a spoken language?

For most of the time that I was actively using CVS (about a decade or so) if I wasn't using the command line interface then I most likely was using the pcl-cvs module for Emacs. It has a very good integration with emacs, with a dired-like listing of the files in the workspace that need some sort of attention. (They're modified, need updated, or etc.) It also apparently had very little overhead as the response time was always about as snappy as you could get with CVS, and when you're dealing with a source code repository with over 11,000 files in it every little bit counts. I tried a few other CVS-front ends over the years, but none of them seemed to suit me and my work habits very well. They either assumed too much or were too restrictive, in other words they got in my way more than they helped me to do my job.

A couple years ago OSAF switched from CVS to Subversion, and although I had played around with it a bit before this was my first real effort at using it. I love the advancements that SVN gives over and above what CVS can do, but I was very disappointed to find that the Emacs module for SVN (psvn.el) basically sucks. Although it provides an interface similar to pcl-cvs, it is very slow, often taking much longer to do something than it would take doing it from the command line, and it can sometimes block normal Emacs usage for a few seconds at a time while it churns at 100% CPU. So I looked at some other Free alternatives and didn't find anything that I liked. They were all either as slow or slower than the Emacs module, or they had the same problems that the CVS GUIs I had looked at had. So I gave up and used subversion from the command-line most of the time.

Now that wxWidgets has also switched to Subversion I started looking around for other solutions again... To my surprise I found that PySVN's WorkBench tool was a good fit for me. It's very fast at doing SVN operations, and it doesn't get in the way of how I work. I think I had dismissed it before mainly because it seems to be primarily intended as a test case and proof of concept for the PySVN Python extension module. So I started using WorkBench more and more and liked it more and more, but I also started noticing things that I didn't like as much, and some things that I thought could be done better, mostly UI and usability types of things. This brings me to the point of this article: WorkBench is Open Source so I could tweak it to my heart's content. And since it is written in Python and uses wxPython for the UI it is very easy for me to do so. And so that's what I've been doing off and on for the past couple months, and I have to say that it has turned out very well. Yesterday I submitted a big patch to the PySVN project, and although there are a few more things I would like to do to it, I am very happy with what I have done so far. And all of this is due to the Open Source nature of the project. Open Source allows me to make the tool be what I need it to be, and so I did it because I can.

wxPython 2.8.6.0 has been released. Details are found here, and the download page is here.

An interesting thing about this release is that I made the build, uploaded about a gig's worth of installers and packages, and everything else that goes into making a release, all while being out of town and away from the machines doing all the work. I was able to make all the final tests and adjustments on my new Mac, using VMware Fusion for the Windows and Linux specific work, and then used Mercurial over an ssh tunnel to push my changes back home to my master build and release machine. The next part was easy, since I have been doing mostly automated builds for a few years now. I just start it going via a ssh login and then checked on it a few hours later from the hotel to see if it's done. At that point things started to get a little tricky, mainly because I usually do the rest of the release process by hand and in person. Since the full build is about a gigabyte of binaries I transfered just a few of them to my local machine for testing, and then I had to deal with uploading remotely from the build machine to SourceForge and our APT repository, all while I had a flaky wireless connection here and while attending various meetings. Then I realized that the software I usually use for editing the website is only installed on a machine at home. Well anyway, I muddled through and managed to get it done, and now I know where my release process could use a bit more streamlining and automation...

I got a good chuckle out of this quote:

"I understand that you want this. I am advising you against wanting it." -- Chris Mellon