Programming with Qt, 2nd Edition

Chapter 1. Introduction

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.

Why GUI Toolkits?

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.

Why Portability?

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.

Why Qt?

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.

Implementing Cross-Platform GUI Libraries

GUI toolkits that allow cross-platform programming can follow one of several strategies according to how the native toolkit API is used.^[3] 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.

API Layering

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.

API Emulation

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.

GUI Emulation

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.

Acquiring Qt

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.

If you run one of the very popular free Unix-like operating systems such as Linux or FreeBSD, your distribution probably contains a version of Qt. It might not always be the latest version, however.

Qt Editions

Qt comes in several different editions. The difference is both what you are allowed to do with it and which features are included. The following editions are available:

Qt Free Edition: 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.
Qt Non-Commercial 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.
Qt Professional 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.
Qt Enterprise Edition: 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 sales@trolltech.com. If you want to develop GPL’d software for Unix/X11, get the Free Edition.

How Free Is Qt?

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.

Compiling and Installing Qt

In this section, we will describe how to build Qt on the supported systems—first Unix systems (including Qt/Embedded and the Macintosh, which behaves like a Unix system), followed by Windows systems.

Installing Qt or Qt/Embedded on Unix or MacOS X systems

Whether you buy Qt on CD or download the commercial or free version, you will end up with a tar file.^[4] 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.

Building Qt/Embedded

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 variable $QTDIR to where you unpack Qt; for me, that setting would be /home/kalle/qt-x11-commercial-3.0.1:

export QTDIR=/home/kalle/qt-x11-commercial-3.0.1

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:

./configure -h

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 plan to debug Qt itself, you should specify the -debug option, which ensures that a nonoptimized version of Qt with debugging symbols is built.

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 you specify -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 configure script 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:

make

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 LD_LIBRARY_PATH and 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 -I$QTDIR/include and to inform your linker about the library with -L$QTDIR/lib -lqt.

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 -I and -L options. Please see the chapter on databases for more information.

Compiling and Installing Qt on Windows

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 %QTDIR%\bin and %QTDIR%\lib.
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:

nmake

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 files (include for Visual C++) and add qt\lib to the environment variable your compiler uses for locating libraries (path for Visual C++).

C++ as Used by Qt

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.

Objects and Classes: 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.
Access Methods: Qt uses a lot of access methods, which are methods that get and set values of private class variables. Set methods usually start with set... (e.g., setText()), while get methods have no prefix (not even get—, e.g., text()). This is fairly basic stuff; there’s no sophistication involved here.
Polymorphism and Virtual Functions: 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.
Inheritance: 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.
Operator Overloading: Qt overloads some operators, but usually these operators “just work.” For example, you can pass a QString object to a function that expects a const char* because a cast operator jumps in to convert your QString object to a character pointer.
Templates: 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.
The bool Datatype: Qt uses the new bool datatype quite often. Unfortunately, some old compilers don’t support it, and consequently don’t know the keywords true and false, either. In these cases, you can use the replacement macros TRUE and FALSE that are provided by Qt. In this book, we use true and false, but if you have one of those outdated compilers, you can always replace true with TRUE and false with FALSE.
Other Features: 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.

Getting Help

You may run into problems that you cannot solve with the Qt reference documentation or this book. There are several places where you can ask for help:

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 qt-interest-request@trolltech.com. After you have subscribed, you can post a message to the list by sending email to qt-interest@trolltech.com.
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.

^[3]If you are interested in how many platform-independent GUI toolkits exist, see the PIGUI FAQ at http://www.zeta.org.au/~rosko/pigui.htm.

^[4]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.

Get Programming with Qt, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Programming with Qt, 2nd Edition by Matthias Kalle Dalheimer