C++ GUI Programming with Qt 3

Alex Moskalyuk writes "Before Sun monopolized the notion of 'write once, run everywhere,' those who enjoy programming in C++ had the choice of using Qt libraries that provide cross-platform GUI support. C++ GUI Programming with Qt3 is written by the employees of TrollTech, the company that created and currently distributes the Qt environment." Read on for the rest of Alex's review.

The first question that came to mind when I got this book - is there any need for it? Qt's Documentation is detailed and extensive with how-to's and an API reference available online for free. I have done GUI development in .NET (with C#) and Tk (with Perl) environments, and even though I've never tried Qt, the site with tutorials looked like a sufficiently good resource to start.

However, after getting through the first few chapters, religiously trying out the code, my opinions on whether a separate book is needed have changed. Jasmin Blanchette and Mark Summerfield's book can take a sufficiently clueless newbie with some C++ knowledge and guide him through the intricacies of GUI building, providing practical advice and some bits of experience on the way. You learn about the practicality of this book by turning to page 3 (with page 1 being the title) and seeing a code example as the second paragraph of the first chapter. Writing a basic GUI application in C++/Qt is attractively easy, to win you over and make you read the rest of the chapter, as well as finish the basic introduction by creating a windowed application with SpinBox and Slider widgets.

The table of contents is available on the publisher's Web site and looks fairly simple. Each chapter takes about 20-30 pages, with screenshots and code examples provided as part of the text. Reading the first 5 chapters, which comprise the "Basic Qt" section and take up 110 pages, should be enough for any C++ developer to build a sufficiently complex GUI application if all that's required is some graphical interface slapped on top of the functionality that's already there.

The rest of the book -- "Intermediate Qt" chapters -- take the reader into the common problems of GUI development, providing some insight into more advanced topics as well. Supporting networking, working with graphics and images, internationalization of the software application, interacting with help, reading XML through SAX and DOM APIs, accessing databases and doing inter-process communication are all covered here. The authors tended to avoid inserting huge amounts of reference material into the book, and, for example, in the XML chapter when working with Unicode you will be told to go online and download the numeric values of the Unicode characters instead of dedicating valuable book pages to it.

The language of the book is simple to follow; there are plenty of code examples (with discussion following each), and when the authors make certain choices, they also explain why. The diagrams and screenshots are clear (although not in color), and the code examples can be easily separated from the text. This is the first official TrollTech guide to Qt 3.2 programming, and the authors promise that the techniques will work with Qt 4.

Perhaps part of the positive impression that this book left is the fact that programming in Qt is easy and straightforward. At the early stages of my education, I started learning GUI programming with MFC, which left an indelible image of complexity and will probably increase psychiatrist bills in the future (to be fair to Microsoft, Windows Forms with .NET is a huge step forward). The book and the Qt library made some complex things sound quite simple and enjoyable to program. As Matthias Ettrich notes in the foreword to this book, the most important point in reasoning why Qt is so popular is "because programmers like it."

The book comes with a CD that contains non-commercial version of Qt 3.2 for Windows/Mac/Linux, Borland C++ 5.5 (Non-Commercial) and trial version of Borland C++ 6.0 compilers, SQLite database engine and book source code. The non-commercial version of Qt 3.2 for Windows can be installed for Borland C++ 5.5, Borland C++ 6.0, Microsoft Visual C++ 6 and Microsoft Visual C++.NET environments. The examples are quite conveniently located in folders with chapter numbers, followed by subfolders with example names.

Whether you're looking for general introduction to GUI development with C++ or trying to learn Qt, having worked with other libraries and toolkits before, this book is a good source of practical information and reference. The book is part of Perens' Open Source Series.

---

Alex Moskalyuk enjoys reading and reviewing books on programming and tech industry in general. You can read his other reviews on his personal site. You can purchase C++ GUI Programming with Qt 3from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Qt != write once, run anywhere

[vocaro (569257)]

Actually, Qt is "Write once, compile anywhere".

Java class files are fundamentally different because you actually can run them anywhere without recompiling.

Re:Qt != write once, run anywhere

[FortKnox (169099)]

Before Sun monopolized the notion of 'write once, run everywhere,'

This line was put up front for one reason. Kick dirt on java to attempt to get the C++ coders respect up front so they'll read my review.

Notice how Java reviews don't start with "since C++ requires so much double checking and almost certain memory leaks..."

Just another flame war awaiting to happen.

Re:Qt != write once, run anywhere

[prostoalex (308614)]

You're over-analyzing it. I taught Java for two years and have used it professionally (although currently it's more of a C world for me), and frankly have little reason for bashing it.

I just needed some opening line to introduce the concept of Qt's cross-platform nature. If the flamewar was the point, I'd post something like this [jwz.org].

Re:Qt != write once, run anywhere

[MrBlue VT (245806)]

Actually, no they aren't. Java source code is compiled to byte code once. From then on that byte code is read by the Java Virtual Machine and executed. The JVM does do some JIT compiling, but it would be wrong to state that you have to recompile every time you run an application.

C++

[nycsubway (79012)]

C/C++ syntax has something going for it; it's very easy to program once you know the syntax. It is also very portable across different platforms. I assume that like many libraries, the functions can be called from a language other than C++, but isn't it cool that so much in the open source community uses a more or less common base language..

_________________________________

Re:C++

[scorpioX (96322)]

I'll agree with you on C, but C++ is an wieldy beast compared to the simple elegance of C. If you want to see what C++ should have been, take a look at Objective-C. A true object-oriented language that doesn't break C compatibility in subtle ways. And if the reviewer had ever used NeXT/Apple/GNUStep OpenStep API's, he'd be singing a different tune about how "easy" it is to program GUI code in C++.

Re:C++

[FortKnox (169099)]

C/C++ syntax has something going for it; it's very easy to program once you know the syntax

Umm, I'd say that's a loaded question. Any language is easy to code in once you know the syntax, its the higher thinking that's usually the hurdle, which is why I question why you lumped C and C++ together in your statement. C++ doesn't require you to use objects, but its the reason it was made, right? Someone that knows C and learns some of the C++ syntax and symbols (like the '>>' and such) can program C

Litany Against Syntax

[devphil (51341)]

As LISP coders will tell you, if you're having to think about the "sin tax", it's not user-friendly. Move past that. Think about the semantics. Or as the Bene Gesserit would say,

Syntax is the mind-killer. It is the little death that leads to total obfuscation. I will face the syntax. I will permit it to pass over and through the parser, and when the compiler is done I will turn my debugger's eye to see its path. Where the syntax has gone there will be nothing. Only the executable shall remain.

Re:C++

[ENOENT (25325)]

Yes, C++ is easy to program once you know the syntax. Unfortunately, even Bjarne only knows about 60% of the syntax.

Re:C++

[Bruce Perens (3872)]

I used to think C syntax was easy to understand, until I learned about "Duff's Device".

Bruce

Re:C++

[ENOENT (25325)]

I used to think that Perl's syntax was easy to understand, until I actually saw some Perl code.

Re:C++

[__past__ (542467)]

I completely disagree. C++ syntax is horribly complicated, with many corner cases (one could say the same about its semantics). Creating a correct C++ parser is damn hard, probably only Perl is as hard to parse correctly.

And if its portability would be so great, why did complete, standards-compliant compilers only get available recently? Why do many projects choose not to use exceptions or even templates to avoid portability problems?

Oh, and no, you cannot easily call C++ from other languages, unless you take the time to create 'extern "C"' wrappers for all functions, either manually or with some tool like swig. Otherwise name mangling, which is not standardized across implementations will bite you. You cannot even generally link two libraries compiled with different C++ compilers together.

Re:C++

[happyfrogcow (708359)]

Why do many projects choose not to use exceptions or even templates

This is due to the way C++ is generally taught or learned on ones own. Everyone and their mother seems to teach C++ as a C. They might throw in some small sections on classes and encapsulation, and if your lucky virtual methods. But STL? Exceptions? Christ, I didn't even know C++ had exceptions until way after I had read 2 different books on C++ and taken a C++ course. At that point, still no knowledge of C++ exceptions. Then I eventually bought "The C++ Programming Language" by Bjarne and have been completely enlightened by his examples and insight into the language.

You can't learn C++ by reading K&R.

Your other points are valid I think, I just wanted to make this point.

Re:C++

[Carewolf (581105)]

No the reason you didnt learn of exceptions, is to protect you. C++ exceptions are crippled bastards only their mother Bjarne can appreciate.

If people in generel knew more of C++ exceptions, the C-trolls would have much more ammunition. It is better simple not to talk about them.

The same goes partly for STL

Personally I like wxWindows

[LordKazan (558383)]

I personally like the wxWindows library. It's fully object oiented and handles all default behaviors for you. It has a very easy to use message handling system and the documentation is excellent (but should include a screenshot of each control for quicker reference). I once wrote apps is pure win32 API.. *puke* [this was before I really got interested in linux] I now refuse to use anything other than wxWindows.

Advantages of wxWindows:
Fully Cross Platform
Easy to learn API
Object Oriented model is well suited to GUI construction - 1 class = 1 screen object

You really should check it out - www.wxwindows.org

Re:Personally I like wxWindows

[10Ghz (453478)]

Advantages of wxWindows:

Fully Cross Platform
Easy to learn API
Object Oriented model is well suited to GUI construction

Doesn't Qt have those same advantages?

Re:Personally I like wxWindows

[DAldredge (2353)]

wxWindows doesn't cost money if you use it in commerical apps.

Re:Personally I like wxWindows

[Falrick (528)]

You're right, it doesn't cost any money to use in comercial apps, but after just finishing writing a comercial app using it, I feel that I can justifiably say, "You get what you pay for".

I ported a Qt application to wxWindows because we couldn't afford to buy any more Qt licenses for more developers. Not much had been written in Qt, so it didn't seem like it would be a big deal. But man can I tell you that moving from Qt, where things just worked, to wxWindows was a pain.

Things as simple as changing the mouse cursor didn't always work (yes, I submitted a bug report along with a fix). wxWindows enforces a particular widget hierarchy which also implies a line of communication (you always communicate up the widget stack through events, and down the widget stack through methods).

The documentation was not always correct. And so far as being cross platform, a large number of widgets have comments along with them such as, "On Windows, feature X and Y are supported. Using GTK, only Feature X is supported.".

Extending widgets is not as simple as it should be. I needed a toggle button with an image, so I derived a class from the toggle button class and added a handler for the paint event only to find that no paint event is generated or handled for the toggle button! How the hell it paints itself is beyond me, but placing the same paint handling code into a frame derived class worked fine. This kind of inconsistency drives a developer up a wall!

Other anoyances include wxWindows changing the colors of my mouse pointers (if I wanted the foreground to be black, I would have made it black!) and the limitation of two color mouse pointers. I had full color mouse pointers in Qt so there should be some way of doing it in wxWindows.

That being said, I did like some of the features of wxWindows. The event handler stack is a neat implementation and I ended up using it heavily. It was easy to add my own event types, though this is another case where some of the documentation is just flat out wrong.

Re:Personally I like wxWindows

[arkanes (521690)]

wxWindows uses Gtk on linux, unless you were running the "Universal" mode. If it looks like crap for you it's because Gtk looks like crap for you.

The major point of wxWindows is that it uses native, not emulated widgets (unlike all other cross platform toolkits that I'm aware of).

Re:Personally I like wxWindows

[Bruce Perens (3872)]

I think we are going to have a wxWindows book by Julian Smart.

Bruce

Re:Personally I like wxWindows

[Bruce Perens (3872)]

I checked with my executive editor. The book will publish this year.

Thanks

Bruce

KAutoConfig

[IceFox (18179)]

Just a note for those Qt devs who are doing cross platform work. I have abstracted out KAutoConfig from KDE and made it into its own LGPL library recently and can be downloaded here [rit.edu] to use in your free and commercial applications. (Stop wasting your time re-inventing the wheel!)

[Speal about what it is/does]

Do you want to add a full fledged configure dialog to your Qt application by only writing one, twenty line function? If so than the KAutoConfig library is what you want. KAutoConfig is several classes that enables a developer to easily create a configure dialog for their applications. It automatically syncs GUI widgets values with values in the configuration file. It does this by looking for keys and widgets that have the same name. It obtains the default values from the initial values of the widgets. KAutoConfigDialog also manages all of the buttons in a normal configure dialog.

-Benjamin Meyer

Qt.

[Cave Dweller (470644)]

Qt is probably the best C++ GUI toolkit out there. In my experience, developing an application is extremely easy and straightforward, due to the fact that the people at TT used the simple (yet effective) model of slots and signals. Writing a new event handler is as simple as overriding a method and then connecting it to your widget -- simple as that.

Not to mention the great I18N possibilities, the great XML-based Qt Designer application, etc, etc.

All in all, there are very few drawbacks to Qt, other than the commercial price -- but hey, if you're an open source developer, you get it for free. Otherwise, your employer will get his money's worth back -- simply due to the fact that Qt is such an excellent product.

(No, I don't work for TT -- I just enjoy their products very much)

Re:Qt.

[f0rt0r (636600)]

I wish I had mod points. When I first looked at cross-platform development, I resisted QT because it was commercial ( and cost $$$ ), so I tried out Java. I hit too many road blocks with Java so I tried C++ with wxWindows. I couldn't find any decent documentation, and everything I did find was very convoluted. Support was websites and mailing lists, neither of which answered even a single question I had.

Finally I said "What the heck, let me try QT", and I was awed by how simple it was to get it to work. It

Re:Qt.

[Jeremi (14640)]

Qt relies on moc or something like that to preprocess C++ source files for signals & slots??

This is true, but it's not a problem in practice. Qt's qmake program generates a nice makefile for each platform that handles all the details for you, and you never really notice the moc files are there.

Re:Qt.

[DenOfEarth (162699)]

That is all well and good, and in theory, it works just fine (well, in practice too, I guess), but the reason that I like to use Qt is that there is a seperate syntax to defining slots and signals. It makes it much easier to read if you skim down your class prototype and the word 'slot' or the word 'signal' appear by themselves. To me that is very clear, and though it requires the use of a precpocessor step, who gives a darn. learn to use a makefile.

The signals and slots as you've shown look no differ

Qt / GTK

[The Night Watchman (170430)]

I'm a programmer, but not a GUI developer, so my knowledge of such things is limited. I've used Qt applications, and I've used GTK applications. Personally, I like GTK2, but that's mainly on an aesthetic level, rather than a functional or development level.

I ask anyone who's developed in either/both of GTK/Qt, and even those with Win32 experience. What advantages does Qt have over the other choices?

---

Re:Qt / GTK

[StormReaver (59959)]

"I ask anyone who's developed in either/both of GTK/Qt, and even those with Win32 experience. What advantages does Qt have over the other choices?"

I haven't programmed directly in the Win32 API beyond making a few calls from VB (back when I was forced to use that steaming pile...), but the general gist is that it is comparable to Xlib (which I have used a lot in the last year or so). Xlib, and therefore Win32 API, are quite painful to use extensively. Qt is light years easier and friendlier to use than either of the raw APIs mentioned above.

I had started GUI programming under Linux with GTK+. I used it (and it's C++ counterpart called GTK--, which was the whole reason I learned C++) as much as I could for a couple years before discovering Qt. I have been a Qt programmer since late 1998/early 1999 (or whenever version 1.44 was mainstream).

Qt, with its support applications (Qt Designer being the cream of the crop); its incredible documentation; and it's thoroughly well-designed API, was a dramatic step forward from GTK+/GTK--. It is, all by itself, a compelling reason to learn C++ if you don't already know it.

Before Java?

[OYAHHH (322809)]

Given Trolltech doesn't even have a website on archive.org prior to the year 2000 I find it a tad bit hard to believe that Sun was later in it's definition of write-once-run-anywhere.

Plus, if we're gonna play those games then I was using Motif on variety of platforms in the early/mid nineties with C without a need for re-write.

So I hardly think QT is a defining standard for write-one-run-anywhere GUI development.

Re:Before Java?

[vurian (645456)]

In 1996 Linux Journal published its first article on developing with Qt: http://www.linuxjournal.com/article.php?sid=0201. By that time, Qt had already been in development for four years, and Troll Tech was 2 1/2 years old.

Warning for "Qt Programming"

[eddy (18759)]

I had the misfortune to read a book on Qt by Patrick Ward called Qt Programming [gazonk.org]. I'm sorry, but it's got to be one of the worst books on this topic that I've ever seen.

Stay far, far away from it.

Language-Neutral GUI

[Tablizer (95088)]

Why are so many GUI systems still closely coupled with specific languages? Why not divorce the GUI engine from languages? I don't know of any library that has successfuly done that. Although Tk comes close, it still requires a specific interpreter be installed.

Re:Language-Neutral GUI

[Glock27 (446276)]

Why are so many GUI systems still closely coupled with specific languages? Why not divorce the GUI engine from languages? I don't know of any library that has successfuly done that. Although Tk comes close, it still requires a specific interpreter be installed.

I can think of some that do pretty well: GTK+ (usable from many different languages) and the Aqua widget set (usable from Objective-C, Java and C++ at least - probably more). For that matter, the Windows GUI is accessible from many languages.

All of them were written in C, which as a simple language, makes interfacing practical/possible. Simplicity has it's virtues. ;-)

Re:Language-Neutral GUI

[TheVoice900 (467327)]

Qt has excellent bindings for Python and Perl (and no doubt others, just I've never used them), and arguably, it's much easier to program from Python than it is from C++.

I would say Java is less of a "monopoly" than Qt

[iamacat (583406)]

With Java, there is a free as in beer VM for most platforms and as far as I understand, you can port Sun's code to your platform for free. You can also develop a clean-room VM and call it something other than Java.

With Qt, it's either an expensive license (my company requires a senior VP approval for any software over $150) or your program is GPLed and Linux-only. I guess a clean room port would be Ok though?

I chose Java UI + JNI over embedded Qt before for just these reasons. For C++ programming, I just hope OpenStep really takes off.

This book is under an Open Source license

[Bruce Perens (3872)]

The text of book is under an Open Source license, as with all books in my series. A few months after publication, both source and unencrypted PDF will be uploaded.

It's not the policy of my series to publish proprietary software on the accompanying CD. But there is some Borland stuff and a copy of Windows Qt on the CD. This is due to a mis-communication with my publisher. I found out about it very late in the process (as I was reading a galley proof), and decided to allow the deviation from policy this time rather than cause a tremendous hassle for Troll Tech. The book had already been advertised, and orders had been booked from stores, etc.

Thanks

Bruce

Programming with Qt - O'Reilly

[adamofgreyskull (640712)]

Does anyone know how this compares with Programming with Qt from O'Reilly? That was the reccommended text for a Soft module I did last term/semester (whatever the uni chooses to call them this week). I thought it covered pretty much everything I needed..and even touched on the aforementioned XML/DOM/SAX stuff.

Pronunciation of Qt.

[euxneks (516538)]

Is it "cute" or "cutey" or what?

Someone buy Trolltech and LGPL it...PLEASE!

[mrm677 (456727)]

QT is awesome. Its license isn't. Before you dismiss this as another ill-informed troll message, consider this:

I am involved with a university research project. We started developing our app using QT, but had to quickly abandon it due to the GPL issue. Due to complications with funding and grants, we can't currently open-source our project. And we will not be obtaining QT Developer's licenses for the following reasons:

1. The bureaucratic mess. A proposal would have to be written, alternatives examined, and so forth. This could take too long. This crap is the way many universities work...most software is given to us or obtained very cheaply with academic licenses.

2. Cost. $1550 goes a long ways in funding graduate students. Our research director would rather hire more students with the money saved. Even Microsoft Visual Studio, which includes far more than GUI widgets, is only a couple hundred bucks for the academic edition.

I think this is one example of why this is hurting the Linux movement. GTK is LGPL...QT should be the same. I know that TrollTech needs to pay their developers, but I sure wish someone like IBM would buy them out and LGPL QT. For something intregal to a platform, such as GUI toolkits, having to spend $1500 for a license to develop a close-source application just isn't good. Also consider small-time shareware developers. I know that shareware isn't popular in Linux, but its a way for a developer to get payed for creating that unique, niche application

Of course my arguments are based on my opinion that KDE/QT is superior to Gnome/GTK, and that if it weren't for the license issue, it would be the dominant platform today.

Re:Someone buy Trolltech and LGPL it...PLEASE!

[by Anonymous Coward]

With all due respect, you need to clarify your grant/funding issues.

If you are producing something which is non-commercial, then there should be no issue with the GPL. You aren't selling it, so you don't need to distribute source. Moreover, you are working with a university, which absorbs public funds and has an obligation to contribute to public knowledge and development.

If the issue is that a private company is using you as a cheap research arm, producing a product for them, then they should easily be a

Re:Someone buy Trolltech and LGPL it...PLEASE!

[Capt. Beyond (179592)]

The only reason why you would want to use the LGPL, is that you want to keep your code proprietary and to yourself.

Qt is superior to gtk because it is created by professional developers, not college students.

Perhaps if you did some research into Trolltech's licenses you would figure out that Trolltech has Edu licenses as well.

It's LGPL that is hurting Linux, as Linux is about free software, LGPL is only about proprietary software. Do you really want Linux to have more non free, closed source, proprietary software??

Simple language

[InodoroPereyra (514794)]

From the review:

The language of the book is simply to follow

This is so important. Some of the ... well, probably most of the C++ documentation is so complex that scares people off. Granted, the language is complex. But you can always present documentation in a friendly manner, with examples, and leave subtle points for a separate, advanced discussion. But I have the feeling that some C++ experts want to be part of an elite of a few enlightened people who know it. Too bad because it is a great language.

In this regard, Qt is a beautiful C++ toolkit, easy to use, really friendly, nicely integrated and documented. Not to mention the great RAD tools like QtDesigner ...

Re:SCOde?

[10Ghz (453478)]

SCO and Canopy combined own a bit over 5% of TT. Majority of the company is owned by the employees of TT. SCO/Canopy can in no shape or form control TT. And TT can't buy the shares back if SCO/Canopy is unwilling to sell.

So quit your whining.

Re:non commercial QT?

[Dave_bsr (520621)]

You can use QT as long as your applications are non-commercial, as I recall. You could always RTFL - Read teh Friendly License.

Re:non commercial QT?

[baxissimo (135512)]

Then what do you call this [trolltech.com] ?

It's not libre free, but beer free. And it's old as hell. But the poster was correct that there is a "non-commercial" version for windows that's freely available. Be warned though that Trolltech's definition of "non-commercial" is rather peculiar.

I'm wondering if they'll make this new non-comm 3.2 edition similarly available.

In the meantime I continue to happily use FOX [fox-toolkit.org].

Re:non commercial QT?

[Keith Russell (4440)]

I thought there wasn't a non commercial version of qt for windows.

There was, then there wasn't, now there is again. Trolltech withdrew the old non-comm version late last year because it was based on 2.3, and every other supported platform/license combination was on 3.x. The book includes a non-commercial version of 3.2 for Windows.

Re:non commercial QT?

[arkanes (521690)]

It's worth noting that the non-commercial versions are binary-only. Not an issue for many people, of course, but I like having source code for my libraries (if only because I like to know whats going on if something doesn't work).

Also, this non-commercial version does not appear to be available on the Trolltech website, so you'll need to get the book (and the text of the license for it doesn't appear to be available either, although I'd assume it's similiar to the 2.3 non-comm license).

Re:Four things I don't care about!

[mcpkaaos (449561)]

1) C++ (Because I can do everything in C)

That carries about as much weight as saying, "I don't care about women because I can do everything with my hand."

Re:Not C++

[arevos (659374)]

It's incompatable with the STL. But not standard C++.

Re:Qt4?

[Capt. Beyond (179592)]

I dont think there ever has been a date scheduled for Qt 4 release. Any information you may have gotten about Qt 4, was not official.
Stay tuned...