Qt is a C++ class library and GUI toolkit for Unix, Windows, and embedded systems (with the latter running on Linux). In this chapter, we will introduce GUI programming in general and Qt programming in particular. We tell you why you need a GUI toolkit and why Qt is a good choice for such a toolkit. You can check Section 1.7 to make sure you know enough about C++. This chapter also tells you where you can turn if you have any problems with Qt.
GUI toolkits are not well known in the MS Windows or Macintosh world, but they are ubiquitous on Unix. This is because the Windows GUI programming API and Macintosh programming tools already contain high-level features such as buttons, scrollbars, and functions for manipulating colors, fonts, and other visual flourishes. On Unix systems, things are different. The pre-eminent windowing system on Unix—the X Window System—is very flexible, but it does not offer the programmer much help. About the only thing you get are functions that help you draw primitive graphics like lines and rectangles, set the foreground and background color, and have user interactions and other events reported back to you. These functions are network transparent, which is a very good thing, but these limited graphical features are nevertheless difficult to program. There is nothing for creating buttons or scrollbars, let alone more complex items such as dialog boxes, toolbars, or tab pages.
Of course, nobody wants to code an entire application this way—not even the toughest of hardcore Unix programmers. This is why several toolkits have been invented to facilitate GUI programming tasks for Unix. There are many toolkits to choose from. Probably the most well-known of them is Motif, because many major Unix vendors have adopted it as their native GUI toolkit. The Common Desktop Environment (CDE), which ships with some Unix-based operating systems like Solaris and HP-UX, is based on Motif. Motif is not only a GUI toolkit, but also a specification for a certain look and feel. Motif is fairly standard, having been developed by an organization supported by many vendors: the Open Software Foundation, now called The Open Group. Why shouldn’t you use it?
According to many programmers, using Motif is difficult, error prone, and not very much fun. It is problematic because it’s based on the Xt Intrinsics, an old framework for GUI toolkits that ships with every implementation of the X Window System. The Intrinsics try to emulate object orientation in C. They succeed to a certain extent, but programming with this style is awkward and sacrifices niceties like type safety. Also, Motif programs are much longer than Qt programs that accomplish the same thing.
However, Motif is a standard, especially in the look and feel department. It would be nice if you could have the same look, but with an easier programming API. Well, that’s exactly what Qt provides—although that’s not all it can do.
We have talked a little about Unix, so it’s time to make the Windows people feel at home, too. The Windows API contains functions to create GUI elements, manipulate colors, and so on. Using these functions is undoubtedly easier than programming the X Window System directly, but it’s still too cumbersome to get real work done. The Windows tools like Microsoft Foundation Classes (MFC) are in the same state as those for Unix—high-level functions are available, but they are not easy enough to use to facilitate the creation of sophisticated user interfaces. Programmers still have to spend too much time creating the user interface instead of concentrating on their application’s core. This is where application frameworks such as Qt come in.
A framework is more than a toolkit or a GUI-programming API; it is a complete programming system that hides the boring, error-prone, low-level details from the application programmer. For example, we would expect a framework to automatically distribute user interactions, such as key presses or mouseclicks, to whatever function or procedure we have defined to handle these interactions. The programming language C++ is well suited for GUI programming, which is why most frameworks use it. Frameworks exist for Smalltalk, Objective C, and other languages as well, but we won’t talk about them here.
Our framework should allow us to define objects that represent one user-interface element, such as a button or a menu, and handle all user interactions with these elements. We want to be able to define relationships between elements in terms of parent-child relations and geometrical relations. We also want to have all the boring initialization and termination stuff set up for us automatically.
With a good framework to tackle these details, you should be able to concentrate on your application’s functionality as much as possible. Your toolkit should help you as much as possible in creating the user interface.
You might have asked yourself why portability is such an important goal. If you develop software for a living, probably the most important reason for having portability is to increase your possible target market. Why should you leave out millions of Unix users just because you are a Windows programmer? Can you afford not to try to sell your programs for Windows just because you prefer Unix? Toolkits make it feasible to develop a program once and recompile it to run on other platforms. Mind you, it is still not easy and there are pitfalls to watch out for. But without such a toolkit, multiplatform programming is feasible only for the largest companies.
Even if you don’t develop your software for the open market, your custom software clients may require you to write programs in a portable fashion so they can sell or use them on additional platforms.
Even if you develop free software, you should remember that portable software often means better software. There might be hidden bugs in your program that a version for another platform uncovers easily. Also, following uniform standards makes it easier for other people to read and maintain your code. In addition, you can get more users if you write software that can be compiled on more than one platform, thereby making the development of free software more satisfactory.
On Unix systems, Qt is the best option; it’s portable, fast, and easy to use. Also, if you write free software for Unix-like operating systems such as Linux, FreeBSD, or Solaris, programming with Qt is free. In other words, you don’t have to pay license fees. We will talk more about this advantage in Section 1.5.
If you are a Windows programmer, you have undoubtedly heard about MFC, the Microsoft Foundation Classes. These classes are shipped with most Windows compilers and they fulfill all the requirements that we informally listed earlier. They are complete in terms of supported user-interface elements and you can buy a lot of third-party add ons.
If MFC contains everything you need, why should you try another library—one that’s completely unknown to many Windows programmers? There’s one important reason: portability. When you use Qt, you can write your programs once on Windows and then recompile them to run on a lot of Unix variants, too. In addition, a lot of programmers who have used both MFC and Qt consider programming with Qt to be easier. After you have overcome the initial hurdles, you will find that programming with Qt is “the way it should be”—that is, it just feels natural. There’s another reason, too—one that will appeal to most programmers: programs written with Qt tend to be very fast. This is because the programmers who wrote Qt spent a lot of time optimizing it.
Of course, other products allow portable programming for Unix and MS Windows. These products include commercial libraries like Zinc and free libraries like wxWindows. I have evaluated most of them for my projects and have always found Qt to be the best option. Of course, you should judge their merits for yourself. Try several alternatives, write sample applications, and see which toolkit is the best for you. Also, if you want to develop not only for Unix and MS Windows, but also for the Macintosh, there is no alternative but Qt.
Finally, if you are developing for embedded systems (notably, embedded systems running a version of Linux), you would have a hard time finding any GUI toolkit that comes close to Qt in terms of functionality.
Qt has its share of bugs and we will mention them as we go along. Fortunately, Qt has short release cycles, so chances are you can download or purchase a new and improved version in a few weeks or months. In the meantime, Qt developers can often help you with workarounds or patches.
GUI toolkits that allow cross-platform programming can follow one of several strategies according to how the native toolkit API is used. For Windows, this native toolkit API is the Win32 API. For the purposes of this discussion, we will assume that Motif is the “native” toolkit API on Unix systems, even though no one toolkit on Unix is truly native. Motif comes closest because it is most common. On the MacOS X, the Carbon framework could be considered the native API.
Many cross-platform toolkits use API layering. This means that they provide their own API on top of the native API. There is one implementation of this toolkit for every native API that it supports. One such toolkit is wxWindows. The wxWindows methods map to Win32 API calls on Windows and to either Motif or Xt API calls on Unix (as far as I know, no version exists for the MacOS X).
The advantages of API layering are that the toolkit is relatively easy to write and that the look and feel is 100 percent compatible with the native look and feel. The disadvantages should not be ignored, however. Programs written with toolkits that use API layering are usually slower than those that use the native APIs directly because each call has to be routed through an additional layer. Native toolkits can differ significantly in their structure, which can lead to awkward control flow in the portable toolkit. In addition, those toolkits typically provide the lowest common denominator of functionality, offering only functions that are available in all supported native APIs. Finally, inheriting in widgets and specializing in them is difficult because widgets are drawn by the native toolkit and not by the relatively thin C++ wrapper.
Some other portable toolkits emulate the API of one system on all other systems. These toolkits include products such as MainWin by Mainsoft or Wind/U by Bristol Technology, which provide the Win32 API on Unix systems. It should be clear that you need no additional software for the emulated platform because the native API of this platform is used. The API emulation is only needed for other, non-native, platforms.
While this might sound like a good idea, it often isn’t. Platforms are too different to make API emulation very practical. Also, programs on platforms that are not emulated are faster than those on the emulated platform because of the additional layer. The towering of layers can be even more frightening; it is not uncommon to have an MFC layer on top of the Win32 layer on top of a Motif layer on top of an Xt layer on top of the Xlib layer...you get the idea. A further disadvantage is that all native toolkits have some features that are undocumented, but are used or exploited nevertheless, and all will have a few hidden bugs. API-emulating toolkits are also very unlikely to emulate bugs and undocumented features, so programs created with them may turn out to be unstable.
The so-called GUI-emulating toolkits include Qt. GUI-emulating toolkits don’t use any native-toolkit calls at all. Instead, they use the drawing or graphics primitives of the respective platforms. Each widget is drawn inside the emulating toolkit.
Again, this procedure has advantages and disadvantages. Since no additional layers except the most primitive ones are used, Qt and other GUI emulators are faster than other cross-platform toolkits. Also, since all drawing is done inside the toolkit, it is easy to display an application in Motif style on MS Windows, or in Windows style on Unix. With GUI emulation, it is also easy to inherit any widget and to redefine its behavior.
This technique also has some disadvantages. First, the emulation might not always be 100 percent exact, resulting in few differences in the look and feel between programs written with native calls and programs written with Qt. Usually, these differences are so small that users hardly notice them. The second disadvantage might have more impact. For every new widget that is introduced to a platform from the manufacturer of the native toolkit, code has to be written that draws this widget in all possible states—including normal, active, and disabled. Writing this code is a lot of work—so much that it can take a lot of time until widgets are supported in the cross-platform toolkit (and some might never be supported). This applies not only to the makers of the toolkit, but also to users who want to add widgets of their own. If they want to do a complete emulation, they have to write drawing code for all supported platforms. However, the same caveat also applies to users of API-layering and API-emulating toolkits. Since Version 2.0, Qt uses a sophisticated style system that eases these burdens somewhat, but does not do away with them completely.
In summary, despite its disadvantages, the GUI-emulation technique is the most powerful. Users care much more about the GUI’s responsiveness than about the fact that it does or does not use the latest UI gimmicks. There’s no denying the fact that GUI-emulating toolkits are faster.
The standard way to acquire a commercial license for Qt is to order it from the manufacturer, Trolltech. The company accepts credit cards and fax orders. You can find pricing information and an order form at http://www.trolltech.com/purchase/. When ordering, you can decide whether you want to get Qt delivered via normal mail on CD or if you would prefer to download it from the vendor’s FTP server.
If you develop only open-source software on Unix, you don’t need the commercial edition. Simply download the source code of Qt from the FTP server at ftp://ftp.trolltech.com/qt/source . You will have to compile the source code yourself, as explained in the next section. If you are unsure of which file to obtain, go to http://www.trolltech.com/products/download/ for guidance to the file you need.
Only available on Unix/X11 and embedded systems. Contains all features of the Qt Enterprise Edition (i.e., it is the “full” package) and can only be used to develop software that is licensed under the GPL. There is no right to support with this edition.
Only available on MS-Windows. Contains all features of the Qt Enterprise Edition (i.e., it is the “full” package) and can only be used to develop noncommercial software (please see the accompanying license file for a more precise definition). There is no right to support with this edition.
Available on all supported platforms (Unix/X11, embedded systems, MS-Windows, and Macintosh). Lets you develop any type of software under any license, but leaves out some advanced modules such as the table module, the XML module, and the networking module. Includes the right to technical support.
Available on all supported platforms (Unix/X11, embedded systems, MS-Windows, and Macintosh). Lets you develop any type of software under any license and contains all Qt features. Includes the right to technical support.
If you are unsure which edition to get, contact email@example.com. If you want to develop GPL’d software for Unix/X11, get the Free Edition.
There have been a lot of flame wars on Usenet about the use of Qt to obtain free software. Since most of the arguments presented there are based on wrong or incomplete information, I won’t comment on them, but I just want to state my opinion on this subject anyway. Note that if you develop commercial software, you will probably wonder what this is all about. Rest assured: you don’t need to know anything about it.
If you develop GPL’d software for Unix systems, you can use Qt for free and do not have to pay license fees. Qt is released under the GPL, which, of course, fulfills the Open Source Definition.
Nobody who uses Qt simply by using a program written with it has to pay license fees. There is no such thing as a runtime license fee. There is, however, a per-runtime distribution fee for commercial software developed with Qt/Embedded.
In my opinion, good commercial software is better than bad free software, which is why I would rather use a very good toolkit with commercial backing like Qt (especially if the developers let me use it for free) than an inferior, entirely free toolkit.
Since developers of free software are not paid for their work, they are driven only by their own motivation. This motivation is undoubtedly higher if they have high-quality tools that let them achieve the desired results as soon and as painlessly as possible. The same concept applies to GUI toolkits. Qt is a very high-quality tool.
I have the opinion that one of the most important kinds of freedom is the freedom of choice. I want to be able to choose between different word processors and different GUI toolkits. It might be the case that for a particular project of yours, Qt might not be the best choice; but without evaluating it, you will never know what you are missing.
Whether you buy Qt on CD or download the commercial or free version, you will end up with a tar file. Unpack this file by issuing the following command:
zcat qt-x11-3.0.1.tar.gz | tar xvf -
If you have the GNU version of tar on your system, you can use this command:
tar xvzf qt-x11-3.0.1.tar.gz
Qt will be unpacked in a directory called qt-x11-commercial-3.0.1 (or a similar directory for the embedded and MacOS X platforms). Of course, you can save yourself work if you unpack the archive where you want to have it, which might be /usr/local. You should now read the INSTALL file in this directory to see if there are any special directions for your system.
Since Qt/Embedded is basically a Qt for Unix (notably Linux) that brings its own window system, there are hardly any differences in building Qt/Embedded and Qt for Unix/X11; you can just follow these instructions for building Qt/Embedded. But note that you either need framebuffer support compiled into your Linux kernel or the qvfb tool mentioned later.
Qt is pretty big, but you will rarely need everything in it. You could build a leaner version of Qt. During the build, the file $QTDIR/include/qconfig.h is included. You can add several preprocessor macros that exclude certain parts of Qt from compilation. See the sample files qconfig-large.h, qconfig-medium.h, qconfig-minimal.h, or qconfig-small.h for examples, or the file $QTDIR/doc/html/features.html in the reference documentation for a complete list.
In most cases, building the Qt library is straightforward. The process has two steps. The first step configures Qt for your system and the second builds the Qt library and examples.
A note about version numbers: when you read this book, there could already be a newer version of Qt. In this case, the version numbers in the filenames will change, but the general process will probably not.
As the very first step, you need to set the environment
$QTDIR to where you unpack
Qt; for me, that setting would be
or, if you use the C-Shell or the tcsh:
setenv QTDIR /home/kalle/qt-x11-commercial-3.0.1
You might want to put the appropriate command in one of your startup files so that you do not need to enter it again each time you log in.
Now check the options for configuring Qt by simply executing the command:
from the $QTDIR directory.
Qt will respond with the switches that the
configure command knows about:
Usage: configure [-prefix dir] \ [-docdir dir] [-headerdir dir] [-libdir dir] [-bindir dir] \ [-debug] [-release] [-qt-gif] [-no-gif] [-sm] [-no-sm] [-stl] [-no-st] \ [-qt-zlib] [-system-zlib] [-qt-libpng] [-system-libpng] \ [-no-jpeg] [-system-jpeg] [-no-thread] [-thread] \ [-Istring] [-lstring] [-Lstring] [-Rstring] [-enable-<module>] \ [-disable-<module>] [-with-<module setting>] [-without-<module setting>] Installation options: These are optional, but you may specify install directories. -prefix dir ........ This will install everything relative to dir (default /usr/local/qt) You may use these to separate different parts of the install: -bindir dir ........ Executables will be installed to dir (default PREFIX/bin) -libdir dir ........ Libraries will be installed to dir (default PREFIX/lib) -docdir dir ........ Documentation will be installed to dir (default PREFIX/doc) -headerdir dir ..... Headers will be installed to dir (default PREFIX/include) The defaults (*) are usually acceptable. If marked with a plus (+) a test for that feature has not been done yet, but will be evaluated later, the plus simply denotes the default value. Here is a short explanation of each option: * -release ........... Compile and link Qt with debugging turned off. -debug ............. Compile and link Qt with debugging turned on. * -shared ............ Create and use a shared Qt library (libqt.so). -static ............ Create and use a static Qt library (libqt.a). * -no-gif ............ Do not compile in GIF reading support. -qt-gif ............ Compile in GIF reading support. See src/kernel/qgif.h * -qt-zlib ........... Use the zlib bundled with Qt. -system-zlib ....... Use zlib from the operating system See http://www.info-zip.org/pub/infozip/zlib -make directory .... This will generate makefiles for all project files in directory. You can specify this option multiple times so as to only make specific directories. -nomake regexp ..... This will prevent matches of regexp from being built you may use this to exclude certain projects in a directory included in -make. -profile ........... Enable profiling with gprof (adds -pg options) -no-g++-exceptions . Disable exceptions on platforms using the GNU C++ compiler by using the -fno-exceptions flag. -platform target ... The platform you are building on (/home/kalle/qt-x11-commercial-3.0.1/mkspecs/linux-g++). -xplatform target .. The target platform when cross-compiling. See the PLATFORMS file for a list of supported operating systems and compilers. -Dstring ........... Add an explicit define to the preprocessor. -Istring ........... Add an explicit include path. -Lstring ........... Add an explicit library path. -Rstring ........... Add an explicit dynamic library runtime search path. -lstring ........... Add an explicit library. -enable-<module> .......... Enables a module where module is one of: styles tools kernel widgets dialogs iconview workspace network canvas table xml opengl sql -disable-<module> ......... Disables a module where module is one of: styles tools kernel widgets dialogs iconview workspace network canvas table xml opengl sql -qt-sql-<driver> .......... Enable a SQL <driver> in the Qt Library, by default none are turned on. -plugin-sql-<driver> ...... Enable SQL <driver> as a plugin to be linked to at run time. -no-sql-<driver> .......... Disable SQL <driver> entirely. Possible values for <driver>: [ mysql oci odbc psql tds ] Auto-Detected on this system: [ ] -qt-style-<style> ......... Enable a GUI <style> in the Qt Library, by default all available are on. -plugin-style-<style> ..... Enable GUI <style> as a plugin to be linked to at run time. -no-style-<style> ......... Disable GUI <style>style entirely. * -no-thread ......... Do not compile with threading support. -thread ............ Compile with threading support. -no-stl ............ Do not compile in support for STL. + -stl ............... Compile with support for STL. -remote ............ Enable remote control support. * -no-remote ......... Disable remote control support. Image Formats: -plugin-imgfmt-<format> Enable format (png, jpeg, or mng) to be linked to at runtime. Uses specified lib <format>. -qt-imgfmt-<format> ... Enable format (png, jpeg, or mng) to be linked into Qt. Uses specified lib <format>. -no-imgfmt-<format> ... Fully disable format (png, jpeg, or mng) from Qt. Third Party Image Loading Libraries: * -qt-libpng ......... Use the libpng bundled with Qt. -system-libpng ..... Use libpng from the operating system. See http://www.libpng.org/pub/png * -qt-libjpeg ........ Use the libjpeg bundled with Qt. -system-libjpeg .... Use jpeglib from the operating system. See http://www.ijg.org * -qt-libmng ......... Use the libmng bundled with Qt. -system-libmng ..... Use libmng from the operating system. See http://www.libmng.com Qt/X11 only: * -no-nas-sound ...... Do not compile in NAS sound support. -system-nas-sound .. Use NAS libaudio from the operating system. See http://radscan.com/nas.html -no-sm ............. Do not support X Session Management. * -sm ................ Support X Session Management, links in -lSM -lICE. -no-xinerama ....... Do not compile Xinerama (multihead) support. * -xinerama .......... Compile Xinerama support. Requires X11/extensions/Xinerama.h and libXinerama. -no-xrender ........ Do not compile XRender support. * -xrender ........... Compile XRender support. Requires X11/extensions/Xrender.h and libXrender. * -no-xft ............ Do not compile XftFreeType (anti-aliased font) support. -xft ............... Compile XftFreeType support. Requires X11/Xft/XftFreetype.h and libXft. * -no-tablet ......... Do not compile Tablet support. -tablet ............ Compile Tablet support (currently only on IRIX). -no-xkb ............ Do not compile XKB (X KeyBoard extension) support. * -xkb ............... Compile XKB support.
For each option group at the beginning, the default one is marked with an asterisk. In other words, if you want a marked option, you do not need to specify it explicitly. In most cases, the defaults will work just fine for you. An exception will be if you use a platform with more than one compiler known to Qt and you want to use a compiler that is not the default. In this case, you might need to specify your platform with the -platform option; see the PLATFORMS file included with Qt for a list of supported platforms.
If you build Qt/Embedded, you can select the
color depths to be supported and whether special hardware acceleration
for certain graphics cards should be included (these switches were not
shown earlier). I would recommend that
-qvfb because the virtual
framebuffer is a very useful tool when you develop software for
embedded systems on your desktop machine.
Now issue the
configure command again, but this
time specify the options you need, or none at all if you are happy
with the defaults as shown in the following example:
This is the Qt Enterprise Edition. Type '?' to view the Qt Enterprise Edition License. Type 'yes' to accept this license offer. Type 'no' to decline this license offer. Do you accept the terms of the Qt Enterprise Edition License? Creating qmake. Please wait... gmake: Nothing to be done for `all'. Build type: /home/kalle/qt-x11-commercial-3.0.1/mkspecs/linux-g++ Configuration ....... nocrosscompiler minimal-config small-config medium-config large-config full-config enterprise release dll png no-gif zlib bigcodecs x11sm xinerama xrender xkb styles tools kernel widgets dialogs iconview workspace network canvas table xml opengl sql stl Remote support ...... no STL support ......... yes Thread support ...... no GIF support ......... no MNG support ......... plugin (qt) JPEG support ........ plugin (qt) PNG support ......... yes (qt) NAS sound support ... no Session management .. yes Xinerama support .... yes Tablet support ...... no XRender support ..... yes XftFreeType support . no XKB Support ......... yes Finding project files. Please wait... 227 projects found. Creating makefiles. Please wait... ... Qt is now configured for building. Just run gmake. To reconfigure, run gmake clean and configure.
As you can see, the
first asks you to accept the Qt license. Type
yes. If you use an edition other than the
Enterprise Edition I am using here, the output might be slightly different, but the
procedure should be the same. Note that we have omitted the output at
the end where the configure script tells you about the many makefiles
being created, as well as further up where the
qmake build tool is built.
As the output tells you, you can now start building Qt by issuing:
Now go get yourself some tea, or even a full lunch—Qt is large and all the additional tools like the Qt Designer and the example programs have to be built, too.
When the compiler is done, you are ready to use Qt; there is no real
“install” step. As the built Qt library will be in
$QTDIR/lib and all the Qt tools will be in
$QTDIR/bin, you should add these directories to the
environment variables that tell your system where to look for shared
libraries and executable programs. On Linux and Solaris systems, this
location would be
PATH; for other systems, please consult
your system documentation. Please do not forget this step. If you do,
you will run into problems later on.
On some systems, you can also add the directory that contains the library to a system configuration file, such as /etc/ld.so.conf on Linux systems.
Finally, when compiling Qt programs, don’t forget
to tell your compiler about the include files with
and to inform your linker about the library with
There is a little catch when you want to build parts of Qt that need
external libraries—like the database drivers that need the respective
database access libraries. We’ll talk about configuring Qt for using
the database drivers later in the book, but you might have to specify
the path to the include and library files when building Qt
itself with the
options. Please see the chapter on databases for more
Compiling and installing Qt on Windows is easy. Depending on what you downloaded or got on a CD-ROM, you have either an executable file or a ZIP file. If you have the latter, unpack the ZIP file to a temporary directory with a program like pkunzip or winzip. You’ll find the file install.exe in the temporary directory.
Building Qt is straightforward—just follow the directions on the screen and make the requested selections. At the end, the selected compiler will start and build the Qt library, the additional tools like the designer, and the example and tutorial files.
Things can get problematic, however, if you need external libraries (e.g., for the database drivers). At the time of this writing, there is no way to tell the installer about additional paths to header or library files. The best thing you can do in this case is:
Let the installer do its work as far as it gets. It will probably report an error during building some time.
Quit the installer. In the Windows control panel,
add an environment variable
QTDIR to point to your
installation directory. (Normally, the installer would do this
automatically, but not if it cannot finish its task.) Change the
values of the
PATH variable to include
Open a command-line prompt. Go to the Qt
installation directory and load the file
src\Makefile into a text editor such as
Notepad. Look for the include paths specified with
-I and add an entry for the path to the missing
header files here. Do the same for libraries, if necessary.
Run nmake (or whichever make program you are using) manually. It will take off where the build from within the installer broke and finish building Qt and the accompanying programs.
Admittedly, this process is more complicated than it should be, and chances are that Trolltech has improved the installer by the time you read this. It is possible to specify the additional paths to the header and library files already in the installer. To run nmake, type:
After Qt is built and ready to use, you might
want to add the directory qt\include to
the environment variable your compiler uses for locating header
include for Visual C++) and add qt\lib to the environment
variable your compiler uses for locating libraries
path for Visual C++).
If you are unsure whether your C++ knowledge is extensive enough for programming with Qt, this section can help. It gives you a short rundown of the part of C++ that Qt and Qt programs use, so you will know if you lack some C++ skills.
If you want to read about some of the language features mentioned here, we recommend C++: The Core Language by Gregory Satir and Doug Brown (O’Reilly). This book concentrates on the most important parts of the language and covers almost everything mentioned here.
Of course, Qt uses classes—it is a class library. You should know what member functions are and how to call them. Also, you need to know how to write your own classes and how to derive a new class from an existing one. You do not need to be an experienced designer of class hierarchies, though. We will provide enough information here on building up your hierarchies for GUI programming.
Qt uses a lot of access methods, which are methods that get and set
values of private class variables. Set methods usually start with
get methods have no prefix (not even
text()). This is fairly basic stuff;
there’s no sophistication involved here.
Qt uses virtual functions to notify your objects about low-level events (such as mouseclicks or repaint events), so you should be comfortable with these functions. Unlike other toolkits and class libraries, Qt uses the innovative signal/slot mechanism rather than virtual functions as the central means of communication between objects. This feature is specific to Qt, so it is covered later in this book.
Of course, Qt uses inheritance, but for the most part, it relies on single inheritance. Multiple inheritance is rarely used—in fact, it is used so rarely that you might never get to see it. If you have never understood what this “virtual inheritance” means, rest assured: Qt does not use it at all.
Qt overloads some operators, but usually these operators “just work.”
For example, you can pass a
QString object to a function that expects
const char* because a cast operator jumps
in to convert your
QString object to a character pointer.
Qt uses templates for its collection classes. You cannot compile Qt with a compiler that does not understand templates, or one that has a broken implementation of templates. The use of templates is not yet compulsory in your own code, if you don’t want to use the collection classes. But since these tools are very useful, you might want to make yourself familiar with basic template usage. Again, there is not much sophistication here.
Qt uses the new
bool datatype quite
often. Unfortunately, some old compilers don’t support it, and
consequently don’t know the keywords
false, either. In these cases, you can use the
FALSE that are provided by Qt. In this book, we use
false, but if you have
one of those outdated compilers, you can always replace
Qt does not use namespaces, runtime type identification (RTTI), new style casts, other new C++ features, or features that aren’t available on all compilers yet. The Standard Template Library (STL) is not used either, but you may use it in your own programs.
If you have a professional or enterprise license for Qt, you are entitled to technical support via email. You will receive the email address with your copy of Qt. Usually, you will get answers very quickly, but if your questions are difficult, please be patient.
You can subscribe to the Qt Interest mailing list, through which a
thousand Qt users exchange ideas and help one another. The
developers of Qt monitor this mailing list as well, and sometimes jump
in if nobody else knows an answer.
Please keep in mind that the other developers on this list are not
there just to help you. Most of them are very supportive, but nobody
is required to answer your questions. To subscribe, send an email message
with the text
subscribe insert your email address here in the subject to
After you have subscribed, you can post a message to the list by sending email
The K Desktop Environment (KDE) (see http://www.kde.org) mailing lists are populated with some very experienced Qt developers, too, so you can ask for help there if you are writing a KDE application. Remember that most KDE programmers do their work voluntarily in their spare time, so please be polite and do not demand quick answers. Please see the web site http://www.kde.org/mailinglists.html for information about which lists exist and how to subscribe to them.
 For some platforms, notably Linux, precompiled binaries in various package formats may be available. Please see your operating system documentation for information about how to install these packages.