Slashdot Mirror
C++ GUI Programming with Qt 3
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.
ConclusionThis 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.
It could be an excellent book, and an excellent and very objective review, but, well, by default i would trust more in thirdy party reviews.
Qt may be nice and cool since it's multiplatform, but the pricetag associated with it is not so nice and cool (starting at 1.55k$). Is anyone aware of OSS products similar to this?
DrkBr
Don't igore the C++ nature of Qt! You don't need to know any of the ugly parts of the language. Qt makes C++ sensible. It's almost as if it were written by people who have to use C++ in their daily work :-)
Don't blame me, I didn't vote for either of them!
While for software engineers you might be able to argue that its their field, learn the language, you can't do that with people who use programming as part of their job, but not their main focus. I am constantly faced with the problem of either having other people understand my code, or writing things faster and with less bugs.
The biggest obstacle is the difficult syntax of C++. After using it for enough time it's easy to forget, but it is a rather large learning curve -- especially for people who just want their code to work. The other complaints leveled at C++ (unless you are working with embedded systems, etc.) I think are just flamewar material.
If there was one feature to pick out for why to use C++ I would have to say templates. Too bad toolkits like QT don't use them.
My own two bits: I chose Qt because from the vey start it was easy to use. I wrote my first working Qt program twenty minutes after first taking notice of Qt. Despite the non-standard signal/slot interface, Qt is about as intuitive as a toolkit can be.
At the time, every other GUI programming method used messages. From Xlib through to Win32, all GUI programming methods use messages.
Agh! Xlib and Win32 are horrible GUI APIs! At least Xlib isn't largely at fault --- its not meant to be a full GUI API. Win32, however, has no excuse! Are you honestly telling me you think that Win32 (with its 200 line GUI hello world), is more sensical than Qt???
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.
Not really. Multi-threading fits pretty naturally with OOP. Look at the BeOS API (which has a lot of parallels with Qt) sometime. Could you give more detail on why you think this is the case?
Object orientation brings bloat: often students would go way overboard in designing a solution, using 30 classes where 5 would suffice.
That's because students, by and large, are stupid. That's why they are in school, to learn. You should have taught them to only use classes when they naturally fall out of the design of the program.
Compilers are not good at OO: compared to C, C++ compilers are immature and buggy.
That was true for the STL and templates, but Qt doesn't use the STL. Qt was very well supported on the compilers of the time. Again, specific examples?
Thankfully, the GTK+ toolkit is winning the battle of the GUI toolkits.
Really now? Seems pretty even to me.
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.
Bah! My favorite apps (Konqueror, Kopete, Ksirc, and Amarok) use my favorite toolkit (Qt).
A deep unwavering belief is a sure sign you're missing something...
often students would go way overboard in designing a solution, using 30 classes where 5 would suffice
You were their teacher? Guess who's fault this is.
Exactly how much code would you have to write to create your project with Qt (or GTK). Well thats EXACTLY HOW MUCH YOU ARE USING OF THEIR CODE. Thats how much time (time = money) you save by using it instead. money/time you didn't have to spend making your project.
With GPL code, you pay for that time/money by giving back to the comunity that provided for you.
With $2400 you pay for that time money by giving back to the comunity that provided for you.
By paying nothing you basically take from the community and ask them to give you money back before they get anything of you.
Don't want to give, don't take.
People like you really piss me off. "They world owes me a job, the world owes me free music, the world owes me free software... But I owe the world nothing, it should pay me for my stuff"
Sigh. If you can't afford the license cost your software must be pretty sucky anyway, as thats barely a couple of months wages.
I don't know what it is that you're calling a message, but the MacOS X (previously NextStep) api (around since 1989, yes with an eight) has been using method calls (termed messages on objc) since the early days.
Most GUI programming environments work through some form of callbacks. Qt is no exception, though signals and slots are sort of like callbacks on steroids (and definitely more akin to the messages in the NS api than anyhting else, again, your usage of messages is somewhere between narrow and uninformed)...GTK also has callbacks, as does Tkinter, both which have been around.
Today's C++ compilers are generally nearly as fast and stable as their C counterparts. Seriously, they've been stable since at least 1999, and the good ones were stable before that. Qt deliberately created moc and avoided the STL to dodge the sketchy C++ issues of the early days so it was never much of an issue. Quite frankly you should be making the compiler choice for your students and suggesting that they work in a campus lab set up for it if they don't feel like dealing with compiler issues. You should be able to test an environment before they do. As the teacher of the course that is your responsibility.
GTK+ is in no way winning. Qt is a much much cleaner implementation of GUI (somewhat comparable to the object oriented GTK wrappers, except it also provides the foundation classes that GTK lacks). Qt is also a win for portability as it provides a common layer for a large range of functionalities from networking to GUI to openGL across the three major platforms. Last time I checked, gtk2 for windows was less than perfect and a native gtk2 port for mac os X is not even on the horizon yet. is Gnome very popular? yes. is KDE? yes. They're both out there and they're both up there. Just cause you prefer gnome doesn't mean that it's time to declare a winner.
You're making some awfully harsh statements here that appear to have no real backing. Yes you tried to teach Qt and failed. perhaps the student's weren't ready for it? perhaps your campus computing environment wasn't ready for it? perhaps you weren't prepared to teach it? I wouldn't go blaming the GUI toolkit first thing.
Brian
Because you are a coward?
How awfully nice for you. May we therefore assume that you're more clever than the rest of us?
Qt uses messages. Did you really use Qt or are you making this up?
What makes it easier to thread a program that does not 'have a GUI wrapped up inside of an object' [sic]?
What is so terrible about having a large number of classes? Only the most novice (OO) programmers I've met shy away from creating more than the 'bare minimum' of classes.
What does this have to do with Qt, anyway?
This is plain wrong. There are some great C++ compilers out there and some servicable ones. Intel's C++ compiler and GNU G++ are examples of the former, Microsoft's of the latter. Why did you let students choose their own compiler?
That first sentence is flamebait; the second is inaccurate. Mozilla isn't built on GTK+: perhaps you meant Firefox?
The parent post smells funny. I call shenanigans.
Rik
> 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.
You have two choices with respect to connecting events to event handlers in wxWidgets:
1. Use the aforementioned MFC-style message maps.
2. Use the Gtk/Qt signal/slot-style wxEvtHandler::Connect() method.
MFC-style message maps are more prevalent in the documentation, however. But if you don't wanna use them, you don't have to.