Lowering the bar to code

by Jono Bacon

A little while back, I decided I wanted to learn Python. Knowing some local Python fanatics, I was not exactly uneducated in the relative merits of the language, and although I mainly used C++ and Qt for GUI programming, I was increasingly wanting to write some GNOME software with Python. Although Qt made GUI programming easier, it seemed to me that Qt was mainly suited towards writing huge, complex tools; the kind of tools that Trolltech showcase on their website. I don't deny that Qt is an incredible product, but I was keen on writing software easier.

I decided to make the move over to Python and started reading Dive Into Python. Well, let me be completely straight here - I only really read a few chapters of the book before I was eager to get on and just write code. So, I trawled the Internet and read a few bits of code, and before I knew it I was writing my own little programs. At this primitive point in my learning, I figured that I should really set myself a test program to write so that I can at least work towards a project. In my experience I had tended to abandon many of these little test programs, but I was determined to write something of use. The more I read and learned about Python, it seemed increasingly easy to use, and I thought, what the heck, I will be adventurous. Right...

The project I decided to work on was in retrospect, remarkably adventurous. I, like many other gadget freaks across the world, own an iRiver. These little MP3/OGG players are renowned for their capabilities, and are well liked in the Open Source world for their ease of use with Linux. Hooking one of these players up to Linux involves two steps. Firstly, you plug it into your USB port, and if you are running a distribution with Project Utopia, a little window will pop up to display the contents of the iRiver's hard disk. You can now drag over your songs. After you have done this, the second step is to update the database on the iRiver. To do this you can use a special little command line program called iRipDB that has been written to generate an iRiver database file. This database basically contains details of the tracks, song length, genres and other information that can make the iRiver more pleasurable to use. Although these two steps are fairly simple, I was keen for the database generation on the iRiver to be as simple as possible. So, in my infinite wisdom of knowing Python for around four hours, I decided I would write a GUI front end to iRipDB called GNOME iRiver.

At this point, I faced some distinct challenges:

  • I needed to figure out GUI programming - I had never done any GUI programming with Python. I knew I needed to use PyGTK, but how so? Also, I was utterly uneducated in how Glade fitted into the picture.

  • I needed to figure out how to interact with the iRiver - how would my little program talk to the iRiver? Was this simple or did it involve some freaky Python bongo?

  • I needed to figure out how to run iRipDB from my program - was this a tough challenge? I suspected there would be a Python command to run a separate process, but how complex was this?

  • Oh, and I still needed to learn Python itself. Best not forget that one.

It seemed the odds were stacked against me, but I pushed on. The first step was to understand how to create a GUI program. In the C++ Qt programming world, this involves creating your user interface in Qt Designer and then using some C++ black magic to re-implement the generated class so you can write slots that hook up to the signals emitted by your interface. Although certainly usable, this way of working is not exactly easy for the novice programmer, and I suspected Glade had a similar way of working.

Not so. In the Glade scheme of things, it seems that I could create my interfaces in Glade and then use a tool called simple-glade-codegen.py to process the .glade file and spit out a file in which I could write my Python code. The script would generate all the function frosting that was required when creating connections between signals and functions in Glade. This in itself got me up and running in no time; I had a GUI program running in 5 minutes.

Dealing with the hardware was my biggest fear. Whenever I have considered programming with hardware on a Linux system before, I have always assumed it to be a hugely complex maze of code. I am pleased to report that times have changes substantially. The recent work going on in the HAL and DBUS camps has given us the ability to easily connect to the HAL daemon and find out properties about the hardware on the system. These properties include all detectable information, as well as the ability to augment this information with special device information files.

With Python support available for HAL/DBUS, I plodded on to understand how to use the technology. Unfortunately, there was virtually no documentation on how to use HAL/DBUS with Python, and the only documentation was the HAL Specification, which is written in a language that assumes you already know everything about HAL anyway. I did skim through the spec, but it was pretty much lost on me, being the numpty programmer that I am. I subsequently turned to the HAL mailing list which is populated by some notable hackers, and each of them are very responsive. I first posted to see where to begin, and the resultant information, combined with the code from the HAL Device Manager, gave me the opportunity to get started. I sent some later posts asking for some more details, but the real help came from David Zeuthen on IRC. David walked me through the process of searching for specific devices. I plan on writing up this process sometime soon for the benefit of others.

With the hardware support working in literally a few days, I was utterly impressed how simple it was to deal with hardware with HAL. I then cracked on to implement the last remaining bits and pieces to actually make the program work. After a few mails from people who had read about my progress with GNOME iRiver on my blog, I decided to release an early (but buggy) version to see what these people thought. They reported success.

Astute readers of my previous work will know that I place a lot of importance in simplicity. This is part of the reason I have made certain technical decisions in my work, and this is the reason why I have written quite a lot about the importance of simplicity and usability. With these beliefs in mind, I see no reason why simplicity and usability cannot extend to the programmer. Although programmers provide a translation layer to convert between the technicality of code and the importance of functionality and usability, this translation can be made easier if simplicity is engineered in the programming side of the wall.

This experience has demonstrated some important principles in development for me. Firstly, the ease of use of Python, and the fact I don't need to worry about many of the pure mechanics of coding (such as declaring types, memory management etc) lowers the bar for people to get involved in coding. I have never considered myself a fantastic programmer, and I have always had to work to understand concepts that natural programmers can execute in their sleep. Although I feel I understand the program design/usability side of the fence better than the programming side, Python has managed to make this translation process easier.

Simplicity breeds simplicity. If a culture of simplicity is engineered into the nuts and bolts of software authoring, it is likely that the core values of simplicity and usability will transcend to each new layer in the software stack. Take a look at GNOME for example. In recent years, a lot of emphasis has been placed in engineering good usability into the platform. This culture has been propagated by programmers such as Seth Nickell, Nat Friedman, Miguel de Icaza, Joe Shaw, Jeff Waugh and others. What we are seeing now is a definitive peer requirement that usability is well considered at every step of the development process.

This same kind of concept appears to be implemented inside the Python community. With the core Python language setting the bar for ease of use, each of the peripheral language additions and tools have a clearly defined level in which to match ease of use. We can see this in how HAL/DBUS are implemented, how PyGTK works, and how it all works with Glade. It would be pointless if Python was an easy to use language, but each of the tools built around it involved baffling levels of complexity.

It is great to have experienced such a simple and effective programming environment. With recent developments such as XUL, Mono, Ruby and other languages, a fundamental focus seems to be placed on the availability of quality high level development tools. I remember some years back hearing a barrage of snobbery about higher-level-than-C languages, and I am pleased to see this generic view has shifted. By making toolsets such as the one I have discussed in the article available, we are opening up the game to a lot more people. Sure, you may not want OpenOffice.org written in Python, but coding is not as black and white as small and large applications.

Have you had a similar experience? Should the bar be lowered? Share your views here...


2005-01-31 03:25:53
what's wrong with pyqt?
why didn't you try first pyqt?
It seems easier that gtk (if you're experienced with qt) and it has the same as glade interface builder. Moreover you would like to try dcop
from kde in order to reuse components: gtk and gnome are too messy/bloated if the simplicity is your goal (they reimplemented c++ classes/STL containers in C something very silly IMHO).
2005-01-31 07:23:54
If you are familar with QT, you can have used pyqt... You would use designer, just as you normally would, save the .ui file, and then run pyuic on the file to generate the python code. Works really well.
2005-02-03 07:41:51
accessing glade files.
I wrote a tool for Python and Glade files. It´s not a code generator. Everthing is done at runtime.