C++ GUI Programming with Qt 3

william_lorenz writes: "With the recent release of KDE 3.2 and KDevelop 3.0, and with the forming of the KDE Quality team as mentioned on Slashdot just days ago, it was an opportune time to read my newest book, C++ GUI Programming with Qt 3. (Qt is of course TrollTech's multi-platform windowing toolkit -- Win32, Linux, UNIX, and the embedded space with Qt/Embedded -- upon which KDE is built. There's a free version licensed under the GPL for non-commercial use and also a commercial version.)" Read on for the rest of Lorenz' review. C++ GUI Programming with Qt 3 author Jasmin Blanchette, Mark Summerfield pages 464 publisher Prentice Hall rating 9 reviewer Bill Lorenz ISBN 0131240722 summary A smooth introduction to best practices for Qt 3 application development.

I didn't have to force myself to read this one: the book grabbed my interest from the beginning. It's filled with just enough technical details to whet my technical curiosity, keep me turning pages, and provide the important information, clearly and concisely. I don't have much Qt development experience (none at all yet), although I am experienced in other windowing toolkits. The book quickly provided me with everything I need to know to get up and developing an application, and now I know where to quickly start.

Who's it for? I am of course a novice Qt developer, yet one with a fair amount of IT experience, specifically with other windowing toolkits. I found this book not only a great introduction for those who want to get started with Qt, but it's also a trove of information for somewhat intermediate Qt developers. It's not for people who work for Trolltech or have already been developing feature-rich KDE applications; however, besides providing a great point of entry for new Qt developers, the book does touch on some more advanced topics. Technical books tend to age quickly, but I should note that the book is written by some of the people who brought us Qt 3 and are working on bringing us Qt 4, so this book should have a degree of forward compatibility. What can I expect to learn?

The book is divided into two sections: "Basic Qt" and "Intermediate Qt" development.

The basic Qt section covers everything that someone new to Qt would probably want to learn, beginning with a simple application and an explanation of signals and slots (signals and slots work much the same way as windowing events in Java, for example, and can help to tell when a button or key is pressed). Signals and slots help make the sample application functional. This section also introduces the Qt reference documentation, available online as a reference during development, and Qt Designer, for those who want to use a graphical user interface to create components such as dialog boxes. A quick overview of some of the available widgets is next (widgets are graphical elements such as dialog boxes and buttons), which helps to give someone brand new to Qt development a feel for some of the components that come ready-to-build-upon. This is all covered in the first 38 pages of the book.

I should point out that I think that knowledge of the C++ programming language is essential if one is to learn good things from this book (I'm a big proponent of learning through experience, and you'll need to play with C++ code), but learning Qt and C++ development at the same time might help one come up with some interesting project ideas for learning!

After a quick introduction to creating custom widgets and double buffering (used in some cases to prevent screen flicker), the intermediate section starts by hopping right into layout managers, intended to make graphical forms and components beautiful (and more usable), just like tables helped to make HTML beautiful before CSS came around; layout managers help do for graphical application components what the font and alignment settings do for a word processor. The managers included are very similar to those used in Java's JFC/Swing stuff, and they work well. Also covered are methods for creating 2D and 3D graphics, drag-and-drop, and event processing. Compared to signals and slots, event processing gives the developer more control, and becomes important when writing custom widgets or changing the way an existing widget behaves.

Following this are sections on internationalization, providing online help within an application, multithreading for responsive applications, and Qt's platform-specific features. Qt works with Microsoft's ActiveX, for example, although this apparently requires the Qt/Windows Enterprise Edition as opposed to the free edition of Qt. It's important to point out that Qt implements its own threading capabilities, and the section on threads covers this in depth.

Conclusion

This is a great book for those interested in Qt and KDE development, cross-platform C++ graphical application development, and just making beautiful, functional applications. The book provides information that can't be had from the Qt API alone, and it does so in a way that kept me turning pages. Blanchette and Summerfield organized their text well, with logical chapters that make finding tips for that first application possible. This book gets twelve thumbs up from me.

Bill Lorenz is Vice-President of the Linux Users Group of Cleveland and is helping to organize the Ohio LinuxFest, 2004 edition (call for submissions now in the wild!). You can purchase C++ GUI Programming with Qt 3 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Sounds like I need it.

[Trejkaz]

I've been considering getting into native GUI development for a while now and Qt seems like as good a way as any to enter. The API is about as clean as Java's Swing, and I can hopefully ignore the C++ nature of it for the most part by finding a binding to something else. :-)

Re:Sounds like I need it.

[Trejkaz]

My current thoughts are using Qt/Java or Qt-Ruby, but it will largely depend what I decide to write.

There are also C bindings for Qt in development, if I was going for an extremely simple application I would just use those.

The #1 reason I would learn Qt, however, is to give myself a decent chance of contributing to the Psi project. I would be forced to learn C++ in that case but at least Psi's C++ is clean compared to many C++ apps I've seen. :-)

Re:Sounds like I need it.

[HuguesT]

Ah yes, no template (no STL), no exception, home-grown String class and the weird non-standard signal/slot extension. C++ from ca 1990.

Ugly is in the eye of the beholder.

Re:Sounds like I need it.

[Brandybuck]

no template (no STL)

The number one thing that confuses newbies

no exception

An incredibly difficult thing to get right no matter how simple the syntax. Exception "tarpits" are very sticky indeed.

home-grown String class

Only because the C++ string class is so limited without the use of STL algorithms.

weird non-standard signal/slot extension

Or you could use the weird "standard" signal/slot mechanism of libsig++. But beware of huge template bloat if you do. Signals/slots are an elegant solution that has plagued GUI developers for years. No fumbling with dangling callback pointers. No masses of abstract interfaces. No unreadable macros. Just a simple syntax and you get to connect user events to code.

C++ from ca 1990

Well of course! That was the era of Object Oriented Programming. This decade all the C++ purists are into Generic Programming, and frankly the C++ syntax for GP sucks. Yes you can write C++ in an Industrial Strength Style with full blown template partial specialization and code that causes your eyes to bleed, but please don't subject me to it.

GPL Version

[bfree]

Quoting from the submission:

There's a free version licensed under the GPL for non-commercial use

Pardon? How can a GPL be version be restricted like that? Of course it can be used commercially, just under the terms of the GPL.

Re:GPL Version

[Trejkaz]

The holders of the copyright can decide which license applies to which parties. Trolltech have simply decided that commercial parties need to pay them money to use it, while everyone else can use the GPL.

C++ Skill...

[MP3Chuck]

What level of C++ knowledge is necessary to begin working with something like Qt (or other windowing libraries for that matter)? Having taken several semesters of C++ so far, I want to try something a little more tangible than the prompt stuff we've been doing.

Some reasons to use an OS' native toolkit

[Rascasse]

Speaking as a relatively new Mac OS X user, I'd like to add the following reasons not to try to use cross-platform GUI toolkits. Looks are deceiving. Though they appear to look like native widgets, upon closer inspection some differences become apparent. Moreover, they may not act like native widgets. The keyboard shortcut equivalents may be different than what are available on the native OS' widgets. Scripting support may be available on the native OS' widgets, but unavailable on these cross-platform widgets. As minor as these differences may appear at first-glance, they add enough inconsistency to ruin the user experience - especially on OSes such as Mac OS X.

I used to be a big fan of cross-platform GUI programming, but having worked on all variations of Windows, Linux desktops, and Mac OS X, I am now against the idea. I now believe if you're going to support a platform, use the native toolkits as they bring a level of consistency that is just not there with cross-platform toolkits. Having to use a GTK or QT-based app on Mac OS X these days proves to be tremendously frustrating. Text boxes don't have spell-checking or auto-completion. The red dot in the window decoration does not change if the document does. In fact, there is often no document-based implementation whereas there would be one if a native solution was developed. On Windows and Linux, the differences may only be cosmetic, but on OSes such as Mac OS X looks are only the tip of the iceberg with the problem. Cocoa widgets look pretty, but they also bring with them a lot of functionality that I've yet to see replicated on these cross-platform toolkits.

So please, when in Rome do as the Romans do.

Re:Some reasons to use an OS' native toolkit

[Trejkaz]

The thing is, on a whole class of platforms, Qt is the "native" toolkit.

But you're right. Spell checking isn't only a problem on OSX, it's even a problem on KDE. Even if every KDE app you own uses the built-in spellchecker to check every text entry box, a Qt app you compile today will not use it automatically.

Cross-platform toolkits like wxWindows are supposed to deal with this sort of problem by just proxying the native toolkits. I'm not sure how well this works because I haven't used wx* either, mostly put off by the ugliness displayed in most screenshots from wx* apps.

Somewhat OT: Something smaller than Qt3?

[rthille]

From the FAQ:
Qt/Embedded can be configured to for ROM requirements between 800k and 3M, depending on what features are enabled.
I'm working on a new software load for the Ceiva (ver 2), and 800k ROM just for the graphics is way to heavyweight.

Re:Somewhat OT: Something smaller than Qt3?

[Anonymous Coward]

Fltk is what you want. Qt's pricing sucks ass anyway.

How does Qt programming compare with Gnustep?

[Lord of the Fries]

I've done a little Gnustep programming... is there anyone who's done both who can give a comparison? Would I be happier doing Qt?

Re:How does Qt programming compare with Gnustep?

[CoolMoDee]

being a Cocoa programmer myself, my guess is, maybe. Once having developed the *step way, I find it a pain to prgoram in environments that aren't message based (such as ObjC/*Step). One thing is for sure though, developing in QT would make your programs look normal in the average linux user's envionment, and would look prettier. Of course the horinztal menu patch could change part of that.

Qt is not my favorite toolkit

[Anonymous Coward]

I'm posting anonymously for obvious reasons.

I'm a Teaching Fellow (TF) at Harvard, and I am involved in teaching programming usable interfaces to students, and setting them assignments.

Back in 1999, when Qt was the only toolkit of note, I suggested that an assignment in Qt would be in order. I underestimated the grief that this would bring me.

1. Object orientation as a language prescription is a bad idea: At the time, every other GUI programming method used messages. From Xlib through to Win32, all GUI programming methods use messages. It is considerably easier to thread a program that does not have a GUI wrapped up inside of a object than one that does not.
2. Object orientation brings bloat: often students would go way overboard in designing a solution, using 30 classes where 5 would suffice. At the end of the course, I wanted to take my bat object and call bash on their skull object.
3. Compilers are not good at OO: compared to C, C++ compilers are immature and buggy. Sure, this is a compiler issue not a toolkit issue, but I found it frustrating debugging student's choice of compiler rather than choice of code.

Thankfully, the GTK+ toolkit is winning the battle of the GUI toolkits. Students these days feel much more grounded in reality when they see their favourite applications such as mozilla, gaim, xchat, and xmms using the same toolkit they do.

Re:Qt is not my favorite toolkit

[tequesta]

First of all, what keeps you from combining object orientation and messages? An event is a message that gets placed in a queue and taken out sometime later and delivered. Objects register for the events they want to receive. Perfectly threadable, perfectly object-oriented and moreover perfectly obvious to understand.

Second, if your students over-design, maybe you're doing something wrong as a teacher? I'm a research fellow at a German university and teach students myself. It's true, it takes a while for them to "grok" OO. But once they do, it's the most obvious and simple concept there is.

Third, you base your statement that "compilers are not good at OO" on current C++ compilers. Well, (although this is a Qt thread) C++ is not the only object-oriented language around, and I agree it's certainly one of the hardest to learn. For a programming course that's about concepts (such as "usable interfaces"), you probably don't want problems with the language get in the way of the students. After a student has the concepts down pat, it's easy to write them in a different language, even an unwieldy monster such as C++.

For alternatives, check out Objective-C or Smalltallk (maybe even Java) sometime. They're both excellent languages for learning object-oriented programming, and the language doesn't get in your way (maybe Smalltalk even less than ObjC). Once the students have understood what OO and good GUI programming is all about, they can always learn C++ if they feel the need. It's only a language. But be warned, they'll probably balk at C++ once they've seen how nice a language can be.

Fourth, C++ compilers (especially gcc) have improved a lot during the last couple years.

What you really, really should do...

[Dog and Pony]

... is give these guys a hand up: QT 3 Win32- this project would be totally awesome would it be done!

Where's VB for unix

[superpulpsicle]

Wasn't there a bunch of development on Visual Basic for unix platforms at one time with syntaxes similar to M$ VB from Visual Studio?

Whatever happen to that?

Re:Where's VB for unix

[Anonymous Coward]

You might want to check out the Gambas Project at http://gambas.sourceforge.net/

wxWidgets - fully free Qt alternative

[georgevulov]

Those looking for a fully free C++ toolkit should consider wxWidgets. With its superb sizer layouting system, rich api, native look, and great support (You often get replies from the authors themselves on the mailing lists), it is one of the best free toolkits around.

Now, with the new partnership between wxWidgets and Borland, wxWidgets is likely to develop even more rapidly.

Though wxWindows is free, unlike the free version of Qt it is not GPL, thus it can be used for commercial software development without worry.

Re:wxWidgets - fully free Qt alternative

[master_p]

You forgot to tell a few things:

1) WxWindows break OO principles by using message maps; in other words, you don't overload a method, you define which callback to call using an id through a table. Message maps is a major reason why MFC sucks.

2) There are quite a few bugs in it.

In my opinion, not everything should be without price. Since Qt is the best toolkit there is, Trolltech deserves to get rich (hey, even BillG got rich from the horrible kludge that is WIN32).

Visual Component Framework

[Space_Soldier]

For those of you that do not know, there is Visual Component Framework (VCF) at vcf.sf.net. The author of VCF is in the same boat as many of you. He likes Qt very much, bud does not like the price associated with it, thus he created VCF which has the goal of working on Windows, Linux, and Mac OS X. Right now it works on Windows, parts of it work on Linux and OS X. VCF is free and has the BSD licence.

Re:So, if I understood correctly.....

[botzi]

...C++ is bad because its complex??? Sharpen up.
C++ is *the* language, complex - sure enough, misunderstood - even more sure, 90% of today's CS stuff is drawned in its own mediocricy - count on that!!! this was one of the best books on programming languages I've ever read and if you're capable of understanding 50% of it you're sure to change your opinion on the language. Oh and...

...ever try reading someone else's C++?

Yes, as well as C, Lisp, Java, PHP...etc. And for all those cases I found the following statement true: as long as the person who's wrote it is a <language name here> programmer and not someone *forced* to do the job in <language name here>, it will be a joy to read - in all the other cases the code readability depends on writer's & reader's intelligence.

Re:Gah! Kill Qt already!

[cozziewozzie]

How is Qt's licensing abysmal, please? It's licensed under the GPL. Just like Linux, GNU, GCC, Emacs, MySQL, MPlayer, The GIMP, and just about any other Free Software program.

So, what's so abysmal about the GPL? You sound like you think the world would be much better off if Linux, GNU, GCC, Emacs etc. all changed to proprietary licensing (like "WindowsXP from NewEgg") and available for "less than $100 from NewEgg".

Re:Gah! Kill Qt already!

[JCholewa]

> Oh, and there is no GPL version for Windows

As a matter of fact, there is.

Trolltech has no impetus or obligation to port GPL Qt to Win32. But GPL is GPL, so anybody with enough skill can -- and did -- port the codebase to MS Windows. Yeah, it's not perfect (yet), but I've compiled and run stuff written in Qt2.3NC with this GPL'd version of Qt3.x.

--
-JC
coder
http://www.jc-news.com/parse.cgi?coding/main

PS: It's Windows-native and doesn't need X11 to run, in case you're confusing it with the similar project on the same sourceforge area.