Mitch Kapor's open source PIM to use wxPython

Mitch Kapor's Open Source Applications Foundation has emerged into blogspace, where Mitch says he'll chronicle its progress. The first project: a powerful, easy-to-use personal information manager for Linux, Windows, and Mac. Mitch writes:

At this point, a small team has spent the better part of a year thinking through the problem space and developing the fundamentals of our approach and has just begun writing the production code. We've made a number of fundamental decisions about the architecture and have arrived at a preliminary set of features. Andy Hertzfeld has built a terrific prototype which enabled us to explore lots of new ideas.

Sounds encouraging. This will be an open source project. And, of particular interest to me, the software platform is wxWindows/ wxPython. Spot on! Way back in 1999, I said in a column:

I notice that Mahogany is built using wxWindows, an open-source cross-platform GUI framework built in C++. Mahogany achieves its scriptability by embedding a Python interpreter within itself, and then supplying some Python glue modules that expose parts of the Mahogany API to Python.

As the Mahogany docs note, and as is typical of this approach to embedded scripting:

Python has access to Mahogany's internal class hierarchy. At present we supply interface definitions and Python modules for only a small number of classes, however if there is need for more classes being supported, we can easily extend the list - please ask us if you want more support!

It appears that there might be another way to skin this cat. There's another open-source product, wxPython , which encapsulates wxWindows in Python. It enables interpretive, scripted development of wxWindows applications.

This raises the question: why isn't Mahogany a wxPython app, rather than a C++ app that embeds Python? If it were, no extra interface work would be needed to script-enable Mahogany, and it would be a radically programmable application.

Ever since then, I've wondered: why can't a scripting language drive a major, user-facing, GUI-intensive application? In theory, the use of a dynamic high-level language would release a lot of creative energy into a space that is desperately in need of it. In practice...well, that's what we're about to find out.

Former URL: