C++ GUI Programming with Qt 3 217
| 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.
Re:Online Books (Score:5, Informative)
QT Tutorial [trolltech.com]
Why to get this book (Score:5, Informative)
The book comes with a free non-commercial version of the QT-Win( windows ) library ( QT 3.3.1, I believe ). The last time this was available was version 2.3.0, so if you want to get a non-expiring version for Windows, here is your chance.
I also read the book is released under a special copyright license similar to the GPL ( the Perens License ), so that after a few months the electronic format of the book becomes legally distributable. Is that cool, or what?
online tutorials (Score:2, Informative)
Re:Sounds like I need it. (Score:4, Informative)
A downside to QT is that it is not free under windows. While this might be okay with companies, if you ever considered writing crossplatform OSS programs, this can hamper things. There is a project [sourceforge.net] porting the X11 version to windows, so its not a complete roadblock..
Of course there is always GTK which has been known to also run under windows [gimp.org] and OS X [sourceforge.net]. It is not my intention to start any flamewars -- I am just pointing out that for those in favour of either toolkit there is plenty of crossplatformability.
If either TK holds any major advantage its that GTK+ natively supports C code, but also has C++ bindings [gtkmm.org]. The signalmm library that came out of gtkmm is actually really nice, and usable for other projects. However, in that case don't forget about boost [boost.org], which also contains a signal library [boost.org], not to mention a *really* nice interface to python [boost.org] (which I'm currently using in a project). Just be warned, you need a fast computer for compiling.
Re:GPL Version (Score:2, Informative)
Take a look at MySQL [mysql.com] to see how something can be offered both commercially and under the GPL.
If you are the copyright holder for the entire code, you can license it however you please. The GPL does not remove the right of the copyright holder to do whatever they want with their own code
Re:GPL Version (Score:5, Informative)
If you want to develop closed-source applications with QT you need to purchase the commercial version of QT, you can't use the GPL version.
This way of doing things is compatible with the GPL.
Gah! Kill Qt already! (Score:1, Informative)
Trolltech charges $2400 [trolltech.com] for two platforms. Presumably cross-platform coding is the sole reason you'd be using such a GUI library - so that's going to be your base price.
But Microsoft solutions are far cheaper (it's less than $100 for Windows XP from NewEgg [newegg.com]) - and they even give away a free version of their compiler [microsoft.com].
If you're looking for a cross-platform GUI - for a commercial or free project - look at the competitors to Qt. I would not hesitate to recommend wxWidgets [wxwidgets.org] as a thoroughly competent, cross-platform, commerce-friendly GUI system.
Re:GPL Version (Score:3, Informative)
Re:Pricing (Score:3, Informative)
Re:C++ Skill... (Score:5, Informative)
I was in a similar position, with enough self-taught C++ to read and follow code but with no clue of how to build a meaningful GUI app. The great thing about Qt is that it genuinely makes OOP seem logical, in the way you make a bunch of objects and hook them together. I'd greatly recommend getting a free version of Qt, going through the tutorials and examples (that's the other great thing -- the documentation is superb) and maybe then trying KDevelop and the KDE libraries.
Pardon me for gushing, but the combination of Qt and KDevelop was a truly empowering tool in my hands and I strongly recommend it to anyone in the same boat.
/s/non-commercial/non-proprietary (Score:5, Informative)
What it can't be is proprietary.
I know Slashdot is not known for precision, but on an issue that gets everyone so worked up it's foolish to provoke people like this for no good reason.
Re:GPL Version (Score:5, Informative)
Re:Gah! Kill Qt already! (Score:1, Informative)
I've looked at libraries - imaging in particular where they charge you $200 just to get an evaluation copy.
If you want to make money from your software, but can't afford to put up $2400 then you might as well give up now, or try a GPL release - you'd be suprised how many people would still buy it.
Re:C++ Skill... (Score:3, Informative)
Actually, I'd recommend that if he has KDevelop 3, he should use it to create a new Qt app--specifically, the one with the menus/toolbars/text editor. Why? It'll generate a good amount of code, specifically, it'll create a bare-bones text editor. He can then look through the code, compile and run the app, and see how it works, then playing around with it and making changes, seeing how those changes affect the app.
Pardon me for gushing, but the combination of Qt and KDevelop was a truly empowering tool in my hands and I strongly recommend it to anyone in the same boat.
I fully agree with you here. Add Qt Designer to the mix as well--it'll really help with interface design. Though I would still recommend learning how to create widgets without Qt Designer first, in order to better learn how they work. After learning that, he should then use Qt Designer to set up the design of his apps.
Re:GPL Version (Score:1, Informative)
To further clarify. You can use the GPL version of Qt for commercial purposes, but if you sell a product that uses the GPL version of Qt your product has to be GPLed. Doesn't mean you can't sell your product, just means you can't restrict what users can do beyond the GPL and you have to provide source code, so your customers can give it, or your source code away under the GPL. However, since TrollTech also offers a non-GPL license option, if you don't want to abide by the GPL and want to sell a closed source commercial product using Qt, you can do that if you pay TrollTech for their 'commercial version'.
Also note that TrollTech does not offer a GPL version of their Windows version of Qt, that one is commercial only. Only the *nix version is GPL. Although TrollTech discourages anyone from doing so, there is legally nothing TrollTech can do to stop someone from porting the *nix version to work on Windows, the GPL specifically permits that. I believe that TrollTech might be able to legitimately require any such derivative work to change the name of the result or otherwise sufficiently distinguish that it is not a TrollTech developed and supported port. Someone correct that if its wrong. And of course such a port couldn't be sold under a closed source license the way that TrollTech sells their non-free Windows Qt.
Re:Sounds like I need it. (Score:3, Informative)
I greatly prefer Qt to Swing, though. Swing tries to be way to "pure" and as a result can be somewhat contorted.
Re:Pricing (Score:4, Informative)
It's layers on layers of API's which just multiplies the complexity, amplifies bugs, and slows things down. Not to mention the bloat on bloat.
Plus it's not really very cross platform, there are so many "This works on Gtk but not Windows" or "This works on Windows but not anything else", etc. Your code turns into #ifdef spaghetti hell. You might as well write native versions for each platform.
The only truely viable cross platform (X11, Windows, MacOS) toolkits are:
1. Qt (*too expensive, nice API, kinda bloated/slow)
2. Fltk (tight/fast, nice API, *limited power, ugly/no themes yet)... My current favorite but I have a lot of custom code to make it look good and add features I need.
3. Tk (*horrible API, not very flexible, can be slow)... I haven't used it much because the API sucks. Does this run under an X11 layer or native on MacOS?
4. Gtk (C based painful API or Gtkmm C++ bloat, kinda bloated but relatively fast on X11, slow on Windows, MacOS uses X11 layer, *buggy as hell)
Re:Sounds like I need it. (Score:2, Informative)
Furthermore, we discussed crossplatform GUI toolkits before here [slashdot.org] and here [slashdot.org]
Cheers,
Ilker
Re:Why to get this book (Score:5, Informative)
Yes. It's the Open Content License. It applies to the printed version today, meaning that you can shove it in a copier if you want and sell the copy, and it will apply to the electronic version when that is released. We usually do that about 3 months after the books reach store shelves. Source and unencrypted PDF will be available as usual.
Unfortunately, I can't say the same for the CD. There is some proprietary software on the CD, I think a Windows version of Qt and some Borland stuff, which isn't really in line with the series policy. But I found out so late that it would have seriously messed things up for the Trolltech folks for me to insist on changes, so I let that go by this time (and made sure it would not happen again).
Next books: Understanding the Linux Virtual Memory Manager [informit.com] next month, and Samba 3 by Example [informit.com] next week! Those are books 9 and 10 in the series.
Thanks
Bruce
Re:Pricing (Score:1, Informative)
2. Fltk (tight/fast, nice API, *limited power, ugly/no themes yet)... My current favorite but I have a lot of custom code to make it look good and add features I need.
3. Tk (*horrible API, not very flexible, can be slow)... I haven't used it much because the API sucks. Does this run under an X11 layer or native on MacOS?
4. Gtk (C based painful API or Gtkmm C++ bloat, kinda bloated but relatively fast on X11, slow on Windows, MacOS uses X11 layer, *buggy as hell)
What about SWT and other Java based GUI toolkits? Not viable enough? I've been looking into SWT for a while, but have not had the chance to write anything in it, so I can't really say.
Re:wxWidgets - fully free Qt alternative (Score:1, Informative)
Works for basic stuff but it seems relatively crude and unfinished as soon as one attempts to write some more complicated stuff.
Documentation is less than perfect compared to Qt docs ( still it is much better than in majority of Free projects)
I hate their event handling - event tables are a nightmarish variation on MFC event handling style.
Signal/Slot model used by QT is a pure genius compared to this stuff.
wxWindows is definitely better than GTK or Motif but if Qt is an option for your project, there is simply no comparison.
Re:Source of the books (Score:3, Informative)
Thanks
Bruce
Re:C++ Skill... (Score:3, Informative)
Signals and slots are probably the biggest hurtle to jump over for basic application development in Qt. They're somewhat different than run of the mill callbacks. The event-driven programming paradigm takes a bit of getting used to.
My advice to you, however, is to learn more languages. There is nothing that teaches a concept as well as seeing how it manifests itself in multiple languages. C++ is not all there is to object oriented programming. At the very least, python and objective-C have lots to teach you about OOP. As far as your Qt-learning goals, you'll see in part how the problems solved by signals and slots in Qt have been dealt with in other languages with less cumbersome object orientated features, and in that way gain a deeper understanding of and appreciation for the design decisions made in the tools you use.
In short the answer to your question is that you need to understand object oriented concepts with a little bit of depth. Class hierarchies, private, protected, friend, etc., Polymorphism both via operator overloading (which is used extensively in the Qt base classes), and via the 'common parent class (QObject)' approaches is also good to have a handle on.
Really, though. Learn more languages. There's lots of fun stuff to be done in languages with large standard libraries like java and python (and objective-c if you happen to be a mac user), even without getting into user interfaces.
Brian
The Independent Qt Tutorial (Score:2, Informative)
http://www.digitalfanatics.org/project
(but without those spaces in the URL)
Re:C++ Skill... (Score:2, Informative)
Re:Gah! Kill Qt already! (Score:2, Informative)
In the land of $100k for a DB, $70k servers, etc, $2400 is nothing. Now if you want to make the case that $2400 is too steep for a single developer, I've spent that much for Enterprise versions of JBuilder. Maybe it's too much for a shareware developer, or a budget strapped startup, but it's certainly not out of reach.
Re:Pricing (Score:1, Informative)
5. Fox toolkit [fox-toolkit.org]. I haven't used it much, but I am using an application that does. The app is kind of nice, so I assume the toolkit is at least passable.
Re:wxWidgets - fully free Qt alternative (Score:4, Informative)
Use the Gtk/Qt signal/slot-style wxEvtHandler::Connect()
Qt's Signals and Slots and wxEvtHandler::Connect() are two entirely different things:
wxWindows requires connection to have a valid id number, which means a mess of ids in the first place. Qt's signals and slots does not require ids. Keeping track of ids is a nightmare, especially if you delete some.
wxWindows connects functions to events, not methods to methods. With wxWindows, can't call an object method directly.
Can't call private methods unless callback function is made friend to a class; which means callback function is visible to end-user (i.e. non-static).
wxEvtHandler::Connect() is not typesafe: any wxObject-derived instance can be passed as user data. Qt's signals and slots and GTK's templated signals are much safer.
Only events can be connected in WxWindows; which means you have to define event data structures, event ids, etc. In Qt, it could not be simpler: connect a method marked as signal to a method marked as slot.
Using Connect() does not mean there are no message maps. In fact, all Connect() does is create a message map dynamically. Which means lots of wasted memory, memory fragmentation etc., slow execution etc
Connect() callbacks accepts specific arguments; Qt's signals and slots accept any argument, just like a normal C++ function.
Can you still claim that wxWindows are equivalent to Qt ? the callback task is much more time-consuming in wxWindows than in Qt. With Qt's signals and slots, one can make beautiful Model-View-Controller architectures; can't say the same with WxWindows.