From: www.itworld.com

Programming the Geek Bowl

by Nicholas Petreley

March 20, 2001 —

I have the privilege of hosting the first annual Geek Bowl
at LinuxWorld Expo in San Jose, Calif. We have a brilliant panel of
stars lined up: Jeremy Allison, Larry Augustin, Bodo Bauer,
Scott Draeker, Jon "maddog" Hall, Miguel de Icaza, Robert
LeBlanc, Ransom Love, Bruce Perens, Eric Raymond, Jay
Sulzberger, and Bob Young. We're going to test their wits
against a wide variety of trivia questions. It should be a
real hoot, so I hope you'll make every effort to attend Tuesday, Aug. 15, from 2:30 to 3:30 p.m.

I took it upon myself to write the quiz show software that
presents the questions and keeps score. (In case you're
wondering, I will release the source code under the
GNU General Public License if only to give my critics a look at how much my coding skills have degenerated over the years.)

There were a number of problems I had to solve in order to
write the program. Most programmers would consider
them elementary challenges, but I'm so far out of practice that
it's a 3,000-mile trip just to get back into the same country.

During the Geek Bowl, questions and answers may be represented as text or as pictures to identify. The problem is that a quiz show's progress is unpredictable. There are four categories of questions: easy, moderate,
hard, and bizarre, each with its own point value. There are three
rounds to the show. During the first round, questions will
have low point values. The values go up in round two. And
the final round consists of a single difficult question
that has a high point value.

In order to satisfy the above requirements, the program
reads from five text files filled with questions and
answers, one file each for the easy, moderate, hard, bizarre and
final categories. Some of the questions and answers simply
point to a graphics file, which my program loads and
displays on demand.

There is no way to know what categories the contestants
will pick and in what order. I didn't want to predetermine
the number of questions per round because, without knowing what the pace of the show will be like, I might make the show too long or too
short. So I have to load up the questions so that I
(hopefully) won't run out for any category. And I made it
easy to jump between rounds whenever it seems appropriate.

During the pressure of the live event, I'm bound to hit the
wrong key now and then. So I assigned accelerator keys that
are hard to hit by accident. I also tried to write the
program to make it impossible to commit show-stopping
errors like bringing up an answer from the hard category
after someone rings in for an easy question. I also made sure
the program will keep track of the game's progress to be able to pick up where we left off in the event of a power outage or system crash.

Most of the programming necessary to accomplish the
above goals is simply tedious, not difficult work. The hardest part was deciding on a language and graphical toolkit, and then learning those tools well enough to crank out a program in just a few weeks. The possibilities I
looked at were C with GTK (Gimp Toolkit), C++ with Qt 2.1,
Python with GTK support, Python with Qt support, Java, and Omnis
Studio. Back when I programmed for a living, I used C most of the time.
So I leaned toward C, C++, and Java.

Omnis Studio doesn't seem to support sound, so I chucked
that as a possibility. I wasn't terribly impressed with GTK,
so I decided against that even though C would have been
the easiest language for me to jump back into after years
of programming neglect. I probably should have picked Java,
but I wanted to try my hand at doing real work with Qt.
Since I am only marginally familiar with Qt, it seemed like
a mistake to choose Python as a language. There is very
little documentation on using Qt with Python, so I'd
probably have to learn more about Qt by programming in C++
first and then switch over to Python. That isn't a good
strategy in a crunch. So I took the plunge and went for Qt
and C++.

Publishing by Xerox

At first I thought my biggest obstacle would be getting
more proficient with Qt. And I'm still struggling with
things like loading and displaying animated GIF files at
the appropriate times, so I may eliminate that feature. But
it was the process of relearning C++ that gave me the most
trouble. After all, I've only written a few useful C++
programs, and that was more years ago than I care to admit.
Sure, I have an excellent memory, but it's short. So I
forgot even some of the most basic principles of C++
programming.

In fact, it took so long to work out enough kinks in my C++
knowledge to do any useful programming that I found I
had to minimize the effort required to learn Qt. That was
the only way I could meet the deadline.

I picked up Programming With Qt by Matthias Kalle
Dalheimer (published by O'Reilly) to speed up the process.
I was quite disappointed in that work, but I normally find
O'Reilly books to be the best. Anyway, I ordered Teach Yourself Qt Programming in 24 Hours by Daniel Solin (published by Sams) to get an
alternate approach to learning Qt. I hoped a second book
would fill in the gaps left by the first.

The joke was on me. Technically, the Sams book is somewhat
better than the O'Reilly book because it is slightly more
comprehensive. So if I had to recommend one or the other, I
would recommend the Sams over the O'Reilly. But it is so
similar to the O'Reilly work that one can only conclude
that both authors used the same framework, assuming it
was available to both (which is entirely possible since there is
good material available on the Web).

The quick and dirty truth

When I release the code, you'll see how the project
deteriorated as it progressed. At first I wanted to write
the program so that all the behavior was determined by
configuration files to make it as easy as
possible to adapt the program for future use. It's still
pretty close to being that kind of application. But as the
days passed, I started to hard code more and more into the
project. I'm hoping that by releasing it as GPL code,
someone will patch up those things it lacks. If not, I'll
go back and polish it up after the show myself.

Speaking of quick and dirty, you may recall that I praised
Qt some weeks ago, particularly its use of something called
signals and slots. As it turns out, I fell into the very
trap that I warned others to avoid. The deadline pressure
pushed me away from experimenting with signals and slots
and toward taking the easy route to finishing up the
application logic. So my entire program is controlled by a
big keyboard event loop. Oh well, live and learn.

In view of the fact that I'm not using one of the best
features of Qt, was the effort to relearn C++ worthwhile?
Absolutely. Programmers of GUI-based Linux apps tend to
lean toward either C++ and Qt or the C and the Gimp Toolkit. Programming is a personal experience, so I don't
mean to offend fans of GTK. And it is quite possible that I
would have had a more polished program if I
had stuck with C over C++. But although I'm still a long
way from being a good C++ programmer, I find it easier to deal with C++ and Qt, and strongly recommend them.

LinuxWorld.com