Petreley's column: The Open Source: An object programming lesson

I've had to do a little programming recently, something I don't often do anymore. As a result, I've been bitten by that programming bug again. That's what inspired me to look at Zope last week. And it's what drove me to investigate programming for the K Desktop Environment (KDE), one of the many graphical desktop environments for Linux and other versions of Unix.

KDE is based primarily on a toolkit called Qt. Qt is a multi-platform object library. You can write applications with Qt and compile them to run on several platforms including Linux, BSD, or Windows, for example. (By the way, you can run Qt applications and even most KDE applications without having to run KDE itself.)Qt has an ingenious method for linking actions to visual objects called "signals and slots." What I discovered is that Qt actually trains you to think in terms of objects instead of procedural programming. Indeed, spending some time with Qt makes it clear why it is beneficial to write object-oriented code in the first place.

Here's the difference. Imagine the following approaches to building a CD player. You can start out with a workbench cluttered with hundreds of tiny parts. You begin with a circuit board, add a resistor here, a capacitor there and build it until you have a working deck. That's the procedural coding approach. Or you can start with a dozen prebuilt modules. You simply take the various modules and wire them together until you have a working deck. That's the object-oriented approach.

The problem is that it is all too common for a programmer to start with an object-oriented language but fall back into using procedural programming techniques. It's like tossing out all but one of the dozen prebuilt modules and then adding hundreds of tiny parts until there is a working CD player.

One of the most common mistakes is to build a few large objects and then program their behavior through one big event-handling loop. An event loop sits and waits for events to occur and then figures out what to do.

The code would run something like this: "Aha, a button was clicked! Which button was it? Was it the Play button? No. Was it the Stop button? Yes! Check to see if a CD is currently playing. If so, then stop the CD player. Let's go through the loop again. Aha, a CD event occurred! Was it a CD-not-inserted event? Nope. Was it a CD-is-stopped event? Yes! That means we turn on a red light."

With Qt, you don't write event loops; you wire objects together. You create a Stop button. Then you create a CD engine with a stop method. You connect the Stop button event to the stop method with one line of code. From now on, whenever someone clicks Stop, it will trigger the CD engine stop method, which stops the CD. Then you create a red-light object with a turn-on method and connect the Stop button to the red light. Now when someone presses Stop, the CD will stop playing and the red light will go on.

Whoops; that really isn't how the CD player is supposed to work, is it? The red light is really supposed to tell you that the drive is stopped regardless of what stopped it. No problem. You modify the behavior of your program by reconnecting the signals and slots. To fix the problem, you reconnect the red light to the CD drive status line. Now the red light will go on when the CD stops, regardless of what makes the drive stop.

I've barely scratched the surface of the power of signals and slots or Qt as a whole. If you want to get a better idea of how well the Qt library is designed, I strongly recommend reading through the Qt tutorial at doc.trolltech.com/tutorial.html.

Once you get your feet wet with Qt, it's a short step from there to programming for KDE.

While you're at it, I recommend you take a look at a program called KDevelop, available at www.kdevelop.org. It's a beauty of a free integrated KDE and Qt programming environment, and it includes the Qt documentation and tutorial mentioned above.

Give it a try and let me know what you think of the programming toolkit, and more specifically, signals and slots.

Nicholas Petreley is a contributing editor for LinuxWorld (www.linuxworld.com) and InfoWorld, and also works with the Linux Standard Base. Send him e-mail at nicholas_petreley@infoworld.com.

Join the newsletter!

Error: Please check your email address.

More about KDETrolltech

Show Comments

Market Place