Restructure the documentation, both on a file and on a content level.

- directory structure in doc/src
- moving of class-specific documentation together with classes
- new, less cluttered index page
- significantely reduced number of "groups of classes"
- categorized all (?) documentation into "Frameworks" or "Howtos"
- reformatting of examples pages
- splitting of very long documentation pages into walkthroughs
- some writing where it was missing


Squashed commit of the following:

commit b44ea6c917a7470a678509f4c6c9b8836d277346
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 18:32:09 2009 +0200

    Some cleaning up in the categories.

commit b592c6eba72332fd23911251d836cf0af4514bae
Merge: 1e10d9e 285d4b1
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 18:20:57 2009 +0200

    Merge branch 'master' into doccleanup

commit 1e10d9e732f4171e61b3d1ecf0b64f7509e71607
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 18:19:03 2009 +0200

    Split the "io" group into "io" and "network".

    And list the network classes in the respective overview documentation.

commit fae86d24becb69c532a9c3b4fbf744c44a54f49d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 18:00:32 2009 +0200

    Move the string-processing classes together with the Unicode in Qt docu.

commit d2a6dd3307b0306bd7a8e283e11a99e833206963
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 18:00:14 2009 +0200

    Not a toplevel topic, it's within the "paint system" set of pages.

commit 44cba00cdf7fb086dd3bb62b15c0f9a7915e20c2
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 17:57:37 2009 +0200

    "Canvas UI" is not a stand-alone concept in Qt - yet!

commit 5f6e69b38fbca661709bc20b502ab0bc1b251b96
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 17:43:01 2009 +0200

    Can just as well delete the old index.

commit aa5ec5327dceb1d3df62b990a32c970cce03ba9c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 17:39:52 2009 +0200

    Some rephrasing and easier access to the "Keyboard Focus" docu.

commit 6248de281565cafce12221c902e9944867b338b3
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 17:37:02 2009 +0200

    Replace the old index with the new index.

commit 110acab8af0c99db9905b0f4cc6e93c325b1e3c6
Merge: d88d526 53807e5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 17 16:04:59 2009 +0200

    Merge branch 'master' into doccleanup

commit d88d52681d758e9e730de0e69290472728bf8c40
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 16 17:34:14 2009 +0200

    Give the "Widgets and Layouts" topic a bit more content.

commit 01e108a5f2d1d0948c2093987a77f222d6cc4d09
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 16 14:21:41 2009 +0200

    Move OpenVG "best practices" documentation into howtos directory.

commit 86f4ca38f965909a29cee0478c537558a4ea8f5a
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 16 14:18:32 2009 +0200

    Add module documentation for OpenVG and Multimedia.

commit 9fef923acbbb75cdc3fc4e984aec177ddcd24c53
Merge: e7e5cd9 72c1cb2
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 16 13:20:23 2009 +0200

    Merge branch 'master' into doccleanup

commit e7e5cd9444ac0e7be55ecfbeb8c9ace23784205b
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 16 13:20:08 2009 +0200

    Add Google custom search box.

    Not sure why that change was never merged in by git.

commit 348372947a3d7da2b28325731ac02bbc67cdec41
Merge: 3ff51b9 aa09d4f
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 15 02:14:31 2009 +0200

    Merge branch 'master' into doccleanup

commit 3ff51b9b52af39c00a938db380809e36b6c701c9
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 15 02:09:38 2009 +0200

    Minor word-smithing.

commit da612b4130061e094a16d47a450f3f3fe6f547c7
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 15 01:55:16 2009 +0200

    Separating the "multimedia" group into reasonable sets of classes.

commit 838955a1a780e41ea77676e1bef8e471c7a2a2f5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 23:12:33 2009 +0200

    Just one file, doesn't need a separate directory.

commit b99f56262faa4410880d08787f2c8d9a509d303d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 23:05:59 2009 +0200

    Move documentation for Asian codecs into src/corelib/codecs.

    Not ideal, the source of most of those codecs live in src/plugins/codecs,
    but since this is no real API documentation it's probably appropriate.

commit ba2258c0b6587d959cdfe6ff99c4d36319077aac
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 22:24:33 2009 +0200

    Renaming of files that used old product/company names.

commit 30ee7deb935bb3de4257cd71be5ba9610376047c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 22:14:30 2009 +0200

    Those will only used by "Qt 4 for Qt 3" users, so leave the original text.

commit d0c110d047bbbd2dde70fc51ad702db59fa3883b
Merge: c5eccd5 8198d35
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 22:12:15 2009 +0200

    Merge branch 'master' into doccleanup

commit c5eccd51ad85cfaf07ea8522a977b7bef70f70fd
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 22:09:43 2009 +0200

    Moving some last files from doc/src into subdirectories.

commit d2dc303d92c1f66bf721b65fca1c6d55ab7ec01d
Merge: 0bdf16e a835ec7
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 15:39:59 2009 +0200

    Merge branch 'master' into doccleanup

commit 0bdf16e1bb04e532d4cc72c5646cb28470d5e627
Merge: 04bb351 c73fd72
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 14 13:08:37 2009 +0200

    Merge branch 'master' into doccleanup

    Conflicts:
    	src/3rdparty/webkit/WebKit/qt/Api/qwebelement.cpp

commit 04bb3513f107a895cfbbf98f8c4f9a67e392c72a
Merge: 8a52ce8 07d2ce1
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 12 19:58:04 2009 +0200

    Merge branch 'master' into doccleanup

    Conflicts:
    	tools/qdoc3/test/qt-html-templates.qdocconf

commit 8a52ce8055d5d8b1bf799bf1fdde18aaf8b940c7
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 12 13:30:50 2009 +0200

    Fix some links to the qt.nokia.com page, and at least some linking to IO.

commit f7823801bf750b0b76ce0871c3f9e8e59c7901fe
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 12 12:27:19 2009 +0200

    Make links in header point to the pages with links to everything else.

commit 335012b7e96698d6ec7994fdfd52813140f12413
Merge: 21b1263 96b6a3c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 12 12:17:57 2009 +0200

    Merge branch 'master' into doccleanup

    Conflicts:
    	doc/src/classes/qtdesigner-api.qdoc
    	doc/src/desktop-integration.qdoc
    	doc/src/distributingqt.qdoc
    	doc/src/examples-overview.qdoc
    	doc/src/examples.qdoc
    	doc/src/frameworks-technologies/dbus-adaptors.qdoc
    	doc/src/geometry.qdoc
    	doc/src/groups.qdoc
    	doc/src/objecttrees.qdoc
    	doc/src/plugins-howto.qdoc
    	doc/src/qt4-accessibility.qdoc
    	doc/src/qt4-scribe.qdoc
    	doc/src/qt4-sql.qdoc
    	doc/src/qt4-styles.qdoc
    	doc/src/qtdbus.qdoc
    	doc/src/qtgui.qdoc
    	doc/src/qtmain.qdoc
    	doc/src/qtopengl.qdoc
    	doc/src/qtscripttools.qdoc
    	doc/src/qtsvg.qdoc
    	doc/src/qtuiloader.qdoc
    	doc/src/qundo.qdoc
    	doc/src/richtext.qdoc
    	doc/src/topics.qdoc
    	doc/src/xml-processing/xml-processing.qdoc

commit 21b126346989a86a828ee8a66bb12108d2bb2b71
Merge: 88e7d76 204c771
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 11 18:15:17 2009 +0200

    Merge branch 'master' into doccleanup

commit 88e7d76ceec664404a913469025ed9a7ca6f4fb0
Merge: 97c4128 1c62dc4
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 11 18:00:56 2009 +0200

    Merge branch 'master' into doccleanup

commit 97c412815162859d853c5a4ede1eb9bd4be4af9b
Merge: cf5d8ae 4096911
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 19:27:08 2009 +0200

    Merge branch 'master' into doccleanup

commit cf5d8ae4b09a92fed5b4e4cabbcfd49116e9e13f
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 19:09:57 2009 +0200

    This should link to the platform specific documentation.

commit 38610f0ff210286f92528495d48f434d2c0db8e8
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 18:59:35 2009 +0200

    These groups are embedded in the respective framework overview already.

commit 1e58a90c561d33aada9427b17db8e0f7bbe02fa7
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 18:54:47 2009 +0200

    Remove howtos and overviews from script group.

    The "Making Applications Scriptable" page needs to be split into a
    walkthrough anyway.

commit 1e68b8d7d53500b8fb6c9c821d46e045ed7efe6f
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 18:30:10 2009 +0200

    Groups are for classes. The objectmodel framework overview links to those.

commit a0a95420c82e2a77150b070e98609aa3e1b3b1a6
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 18:22:20 2009 +0200

    Kill the "buildsystem" group.

    All documents can be reached through the "Developing with Qt" page.

commit 7b23a40c5ba3a215fba6032ad96199b5c9797e98
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 18:07:23 2009 +0200

    This guide should only be in the porting group.

commit ef731bcc53a9b34ba3b42e5ad7caf4234941c4a9
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 18:06:21 2009 +0200

    Phonon is a framework on its own.

    The whole "multimedia" group is a rather random collection of stuff...

commit 5d290d48fc428573ccd31861cf57d214051ba349
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 17:59:36 2009 +0200

    Move the Qt Help documentation into frameworks.

    This needs a bit of a rewrite, and the list of classes needs to be
    integrated.

commit 5e4d094c8712bfb46d844e09746aad5da3ac4a91
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 17:58:52 2009 +0200

    The list of all classes that use implicit sharing is not useful on its own.

commit 2059a0be23c5953f9758098cb7a9416cb86d5ad1
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 17:55:20 2009 +0200

    Make the QtScript overview documentation part of frameworks.

commit 3413696bd745ee5862aa517dcfc9c8446fee9b82
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 17:54:59 2009 +0200

    Make the list of drag & drop classes part of the framework docu.

commit f1c85ea263b30de1e1a1f6c5cb8b8d9ee12254cb
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 17:44:57 2009 +0200

    Porting guides are part of the Howto's

commit cfcc742f938cf7c278f1f8b11b24a61f62fb4c62
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 17:44:26 2009 +0200

    All platform specific docu is available through one toplevel page.

commit 53c642fe4cbc2dbd44fe5b9b4e32feeca438b5c3
Merge: c564285 41537bb
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 16:48:09 2009 +0200

    Merge branch 'master' into doccleanup

commit c5642857b2f2364134f58776661cc08a9da13b2c
Merge: 9cdeba7 24aa363
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 10 15:53:47 2009 +0200

    Merge branch 'master' into doccleanup

commit 9cdeba712c51eb0bf71eab35080734a2b93efcc5
Merge: 09dac33 d13418e
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 8 11:46:42 2009 +0200

    Merge branch 'master' into doccleanup

commit 09dac333d427792a8d33fa311a63c620678e7920
Merge: f7b211e dfa2842
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Aug 7 15:40:33 2009 +0200

    Merge branch 'master' into doccleanup

    Conflicts:
    	doc/src/examples.qdoc

commit f7b211e5588fee20913a8d02c55cca0e05ea2859
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Aug 6 14:58:49 2009 +0200

    Rename file to follow naming scheme and resulting html.

commit ed6432fea376e60e4dd7c8987ed61a063af11ac7
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Aug 6 14:58:10 2009 +0200

    Structure the XML documentation into a walk-through.

    The XmlPatterns docu should probably be split into two or three sections,
    XQuery, XPath and XML Schema.

commit 3dbc1d4ca08d3cac47ca2709b6fb1a2419442c36
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Aug 6 14:15:00 2009 +0200

    Add a table of contents.

commit 1569c35cb90c10ead72dcea2c4b99a0a6cbfcc13
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Aug 6 14:04:52 2009 +0200

    Splitting the long SQL documentation into walkthrough steps.

commit 6a05688bce3cca34dd1b8b323b8feb49d3133d7e
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Aug 6 13:49:50 2009 +0200

    Combining various desktop integration topics into one document.

commit c02c9adca98ba1d4494dd9c7de4ef5b191d9721a
Merge: 4cc4a81 2a286b0
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Aug 6 08:16:04 2009 +0200

    Merge branch 'doccleanup' of git@scm.dev.nokia.troll.no:qt/vohis-docuwork into doccleanup

commit 4cc4a81324cff3c1ad91867cf3acb87d9b4184c6
Merge: a88dc5d 06d57fc
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Aug 6 08:15:52 2009 +0200

    Merge branch 'master' into doccleanup

commit 2a286b03167ce028821b4007bf08537d2c5637c2
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 23:23:28 2009 +0200

    Some writing on windows and dialogs.

    Also some restructuring of the existing content.

commit a88dc5d72bec7abeec23b289c212418499c25e4a
Merge: 86f956c fb8bb14
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 18:09:58 2009 +0200

    Merge branch 'master' into doccleanup

commit 86f956c89b9b8fb3d684665797d4a5b5e538fb2c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 17:09:36 2009 +0200

    All "Qt 4 vs Qt 3" docu lives in porting.

    Some of those files have been changed by now to move docu into overview
    files where the respective information was missing.

commit ac6f1fc8b1e760ae69ce799e13ac92144eeb89e2
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 17:06:15 2009 +0200

    Start work on windows and dialogs docu.

commit 4253dea2661dc3526a9dec53f336301992b543cb
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 16:03:52 2009 +0200

    Make QtWebKit module documentation follow the other modules:

    - Module overview only lists classes, library, header and license
    implication

    - Usage-documentation is separated

commit a27f1b8498ba8d06743e70ecde4fc1e44d5f02f0
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 16:01:25 2009 +0200

    Make QtWebKit classes show up in the module overview.

commit d38d185ec8b7d32037e86b4ecbbc725343aabea7
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 15:40:17 2009 +0200

    Make the most important sections a bit larger.

commit 70991dcdfb8c00baa960381b297fdcb8ed7f50d0
Merge: deb4c2b e95166d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 14:35:07 2009 +0200

    Merge branch 'master' into doccleanup

commit deb4c2bb4d7120579fda541b03c0a77d989089d5
Merge: 37e5373 f78bd88
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 12:59:22 2009 +0200

    Merge branch 'master' into doccleanup

commit 37e5373dcc5455b1e029ee389ce7985a98f579d9
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 11:32:43 2009 +0200

    These new examples are not yet fully documented

commit 85fb40ea11458040e09302bb898d89664eb280b5
Merge: 8b78e18 bcf41cf
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 11:30:26 2009 +0200

    Merge branch 'master' into doccleanup

    Conflicts:
    	doc/src/examples-overview.qdoc
    	doc/src/examples.qdoc
    	tools/qdoc3/htmlgenerator.cpp

commit 8b78e1828b93a9762301d80cb110a1f1b7c4211f
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 00:04:36 2009 +0200

    Line-feed fixes.

commit 2fa80a411dd96369c0e09defc54af44118930ae5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 00:04:00 2009 +0200

    The "buildsystem" docu seems a reasonable start for proper documentation.

    Three lists of tools - in the buildsystem table, in the tools-list docu
    and implicitly through \ingroup qttools. Needs to be consolidated.

commit 8d4043feab66698664cfa17bd150eabf4fe2420d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 00:01:32 2009 +0200

    Restructure the i18n page.

    The list of classes needs to be reviewed.

commit 49f718b1e75c02bc43feac93d5b233064c032555
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Wed Aug 5 00:00:45 2009 +0200

    The Accessibility group is just a group of classes.

commit b17db7dc54c1945cd2651fdebde471c71ef4001d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 23:40:21 2009 +0200

    Remove the "Topics" group.

    Things are part of frameworks or how-to documentation. Top-level groups are
    right now still on the "all overviews" document.

commit 31e5c276b50130542dbd824b0b8cc20b16ca1cb1
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 22:45:43 2009 +0200

    Splitting the thread documentation into multiple pages.

    Also add relevant classes from QtConcurrent to the thread group.

commit d491ffb0e949f1d8653d73495e091b241a025558
Merge: e99794c 3ff7afd
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 19:29:18 2009 +0200

    Merge branch 'doccleanup' of git@scm.dev.nokia.troll.no:qt/vohis-docuwork into doccleanup

commit 3ff7afd6c11d824af38c72afdea4b6578f6de784
Merge: 1dae0ad 2df403d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 18:07:11 2009 +0200

    Merge branch 'doccleanup' of git@scm.dev.nokia.troll.no:qt/vohis-docuwork into doccleanup

    Conflicts:
    	doc/src/accessible.qdoc
    	doc/src/activeqt.qdoc
    	doc/src/animation.qdoc
    	doc/src/containers.qdoc
    	doc/src/custom-types.qdoc
    	doc/src/desktop-integration.qdoc
    	doc/src/dnd.qdoc
    	doc/src/frameworks-technologies/accessible.qdoc
    	doc/src/frameworks-technologies/activeqt-container.qdoc
    	doc/src/frameworks-technologies/activeqt-server.qdoc
    	doc/src/frameworks-technologies/activeqt.qdoc
    	doc/src/frameworks-technologies/animation.qdoc
    	doc/src/frameworks-technologies/containers.qdoc
    	doc/src/frameworks-technologies/dbus-adaptors.qdoc
    	doc/src/frameworks-technologies/dbus-intro.qdoc
    	doc/src/frameworks-technologies/desktop-integration.qdoc
    	doc/src/frameworks-technologies/dnd.qdoc
    	doc/src/frameworks-technologies/implicit-sharing.qdoc
    	doc/src/frameworks-technologies/ipc.qdoc
    	doc/src/frameworks-technologies/model-view-programming.qdoc
    	doc/src/frameworks-technologies/phonon.qdoc
    	doc/src/frameworks-technologies/qt4-interview.qdoc
    	doc/src/frameworks-technologies/qtdesigner.qdoc
    	doc/src/frameworks-technologies/qthelp.qdoc
    	doc/src/frameworks-technologies/statemachine.qdoc
    	doc/src/frameworks-technologies/templates.qdoc
    	doc/src/frameworks-technologies/unicode.qdoc
    	doc/src/frameworks/accessible.qdoc
    	doc/src/frameworks/activeqt-container.qdoc
    	doc/src/frameworks/activeqt-server.qdoc
    	doc/src/frameworks/activeqt.qdoc
    	doc/src/frameworks/animation.qdoc
    	doc/src/frameworks/containers.qdoc
    	doc/src/frameworks/dbus-adaptors.qdoc
    	doc/src/frameworks/dbus-intro.qdoc
    	doc/src/frameworks/desktop-integration.qdoc
    	doc/src/frameworks/dnd.qdoc
    	doc/src/frameworks/ipc.qdoc
    	doc/src/frameworks/model-view-programming.qdoc
    	doc/src/frameworks/phonon.qdoc
    	doc/src/frameworks/qt4-interview.qdoc
    	doc/src/frameworks/qtdesigner.qdoc
    	doc/src/frameworks/qthelp.qdoc
    	doc/src/frameworks/qundo.qdoc
    	doc/src/frameworks/richtext.qdoc
    	doc/src/frameworks/statemachine.qdoc
    	doc/src/graphicsview.qdoc
    	doc/src/howtos/custom-types.qdoc
    	doc/src/howtos/session.qdoc
    	doc/src/implicit-sharing.qdoc
    	doc/src/introtodbus.qdoc
    	doc/src/ipc.qdoc
    	doc/src/model-view-programming.qdoc
    	doc/src/modules.qdoc
    	doc/src/new_index.qdoc
    	doc/src/objectmodel/custom-types.qdoc
    	doc/src/objectmodel/object.qdoc
    	doc/src/objectmodel/objecttrees.qdoc
    	doc/src/overviews.qdoc
    	doc/src/phonon.qdoc
    	doc/src/porting/qt4-tulip.qdoc
    	doc/src/qaxcontainer.qdoc
    	doc/src/qaxserver.qdoc
    	doc/src/qdbusadaptors.qdoc
    	doc/src/qt4-interview.qdoc
    	doc/src/qtdesigner.qdoc
    	doc/src/qthelp.qdoc
    	doc/src/statemachine.qdoc
    	doc/src/technologies/implicit-sharing.qdoc
    	doc/src/technologies/templates.qdoc
    	doc/src/technologies/unicode.qdoc
    	doc/src/templates.qdoc
    	doc/src/unicode.qdoc
    	doc/src/widgets-and-layouts/layout.qdoc
    	doc/src/widgets-and-layouts/styles.qdoc
    	doc/src/widgets-and-layouts/widgets.qdoc
    	src/gui/kernel/qstandardgestures.cpp

commit 1dae0adf3d85620f7574a2a0475510a627a896dc
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:46:58 2009 +0200

    This way it appears as part of the overview, and the moc docu links to it.

commit 5802092887e46dc5eb034bb9b45dd34a265607f5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:45:09 2009 +0200

    Not sure what it is yet, but definitely not an architecture.

    QDataStream links to this page, that might just as well be enough.

commit 69d32c4ff079bcaea098b34de70b7d9587e51e88
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:43:42 2009 +0200

    Use \annotatedlist command to list all widget classes.

    Needs nicer formatting, ie qdoc could be \table aware for those lists and
    skip the header.

commit 02057d7575bb4f0875e82ea4cb76552f2d8ac17a
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:35:46 2009 +0200

    This should be together with all the other licensing documentation.

commit be91b2fe15c67cb90eaa59121d7ff51eb21b4dba
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:26:02 2009 +0200

    These are best practices.

commit 8e0b104db1266a736ac246c9466656c058df18f2
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:25:35 2009 +0200

    Another technology.

commit 19c16384d712c652716776c94c749030b0742752
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:24:55 2009 +0200

    Remove duplicate and out-of-date license headers.

commit 689aa91de0f840fc0f98f0adfbb2f18d72c6b985
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 17:21:00 2009 +0200

    Move into frameworks.

    Add explicitly printed list of classes instead of using a separate
    \group page. The \group page is still there as long as qdoc requires it.

    Threading and WebKit are still "architectures", coming later.

commit 3f96833ab78dacd7ae66e6dd58a3a0dee22229e7
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 16:35:17 2009 +0200

    Remove IPC group.

    Only two classes, and those are explicitly listed in the real
    documentation about IPC in Qt.

commit bbb02d8cc55c9595226f42fe5b617261584c6bdd
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 15:54:46 2009 +0200

    Use the new \annotatedlist command, and make it a framework.

commit ba3a0376acb44ae5cafc8bd3802bd425dcb663a5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 15:38:24 2009 +0200

    Make \annotatedlist <group> work.

commit c80fb8d6a143c81700c2aefe7af1e83dd487dde4
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 15:37:51 2009 +0200

    These are API documentation, not architecture.

commit 713744520bd35d510864ad48464575f1c8a35668
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 15:10:25 2009 +0200

    Frameworks and technologies used in Qt are really one thing.

commit a86d4248c1e3c13f245c49f3f2d018ec4babc822
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 15:00:35 2009 +0200

    Move into correct groups and make the howto a walk-through.

commit 7cc88f310e0dfa37d39026d67443f518531d7fe9
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 12:50:58 2009 +0200

    Architecture -> Frameworks and Technologies

commit 4a3ba3f19d78c4df5343af951c761df47e22759a
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 12:50:41 2009 +0200

    Some consolidation of the Tulip documentation.

commit d3dab98b96d83ce408523f8ccb9363a09eed1f34
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 12:01:10 2009 +0200

    Start with "Frameworks and Technologies" vs "howtos and best practices".

commit 37a8e364442e6234c6a83667eb64af1c79b38e9b
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 12:00:34 2009 +0200

    Beautify.

commit c86d844a79406d4b9fee67578efd67e27ce96b83
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 00:04:40 2009 +0200

    Fix some headers.

commit 20b775d781d3b1d91164320807c21c8a6efcf011
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 23:48:17 2009 +0200

    Split the accessibility docu into a "compared to Qt 3" section, and move
    real information into the overview.

commit 6846a1bccf7d212f7ee0471f992cfb16efb71c43
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 23:47:37 2009 +0200

    The gui-programming seems rather arbitrary and should go away.

    Some things fit into the desktop integration, which is probably more a
    howto. Focus is a concept in the widgets context, and application-wide
    techniques like accelerators should probably be part of the "window"
    docu.

commit 8c7bc99e78a69751080de07618bf003bc227e2db
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 23:45:28 2009 +0200

    Move "Getting Started" documentation into getting-started directory.

commit 561cc3eafa20903243f3946ac4b7b724554c341c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 19:06:16 2009 +0200

    Group "getting started" documents into a walkthrough structure.

commit 6d703807348923a068dea7360fb4456cbde071b6
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 17:35:15 2009 +0200

    Add screenshots for example-overview page.

commit f7a47536305e157c16e8a863f145a2617606a2cc
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 2 16:57:04 2009 +0200

    Link to the real documentation, not just to the modules overview.

commit 92ce250ba206f4dde198637f1a30cd10768d9ae5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 2 16:56:41 2009 +0200

    A new layout for the examples.

    Needs a bit of shuffeling around, and more screenshots and descriptive text
    for some categories.

commit a5e2e2939b32dee0aceabe136aa4c13b12c88070
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 22:39:27 2009 +0200

    Cleanup the script-related groups a bit.

commit ca469165a9f55ca6bd31e53d85d74883fe892ed4
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 22:17:16 2009 +0200

    Add QContiguousCache to the list of containers as a special case.

commit a21292704bd12daf2495195b216424442e097220
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 21:52:37 2009 +0200

    Cleaning up groups of text- and string-related classes.

    Make a clear separation between classes that deal with string data (ie
    QString, QByteArray, QTextStream) and classes that are part of the "scribe"
    framework.

    Merge documentation from the Qt 4.0 introduction of Scribe into the
    richtext processing guide.

commit 3854592806e23955f69613bdc1e2998d5d6f3a8a
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 20:50:06 2009 +0200

    One group of thread-related classes should be enough.

commit b8935bc0ec3d33b6a3fe7b3b220b5781ad79d68d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 19:32:21 2009 +0200

    Move documentation for classes into same directory as the respective
    header files (or implementation file, if one exists).

    This follows the Qt standard, and there is no particular reason why .qdoc
    files cannot live in src. Since there are a number of .cpp files that have
    only documentation it might also be an idea to rename the .qdoc files to
    .cpp and add them to the .pro-files to have them included in generated
    project files for easier access.

commit b61cc5eaf2f2bf72cff209ab0f69fde48fb87471
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 19:29:46 2009 +0200

    Starting to tie together the widgets and layouts groups and documentation.

commit 47fb0c6cf1dacdbfa07a59cf4dc703dd2c35eb8c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 18:43:34 2009 +0200

    This is all duplicate information that is better covered in the
    sql-programming guide.

commit d3c70dd9ed84b4688cbabf30f6b906665b676b76
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 18:37:53 2009 +0200

    Consolidate style documentation.

commit 1d8d30eee1e2fe9f8e77ce1462803921b2132ade
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 17:13:44 2009 +0200

    Split plugin-documentation into two: writing plugins and deploying plugins.

commit a329665353a78749b0d4fdd6e75403252d34f679
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 14:19:47 2009 +0200

    Some final module cleaning up.

commit e3de6579d43cc9796b69188cfb9d3d415a91a770
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:51:54 2009 +0200

    Move remaining overview groups into one file.

commit 7d783342f520f8376e561246268371d0b74a4e44
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:51:34 2009 +0200

    The "io" group should be about file access (be it local or networked).

commit 961fcefb034fea89d1aab2bfed5acaabb65e8d34
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:36:51 2009 +0200

    Kill the "time" group.

    The "How to use timers in your application" documentation covers the usecase.

commit c7bebf1a4c3e2da54ce6a5d649926d76bf65e41e
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:28:21 2009 +0200

    Kill the group "misc".

commit e414a8945cb938ccc6bd1bd8cd52adbfade096c2
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:09:24 2009 +0200

    Kill the "Environment" group.

    It was a random collection of classes, mostly ending up in there because
    of copy/paste (I suspect).

commit 9236a04e7ac6dd3910f035d15b8ab23297fd5f24
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:08:37 2009 +0200

    More moving of files and content.

commit 1ef3134bade2df33ff68c7c906cf20343abd86a5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 02:03:07 2009 +0200

    Workaround qdoc being difficult.

commit 49064b0570088fe749fc08c02c5ab6d23855089f
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 01:49:52 2009 +0200

    Some more moving of files into meaningful directories.

commit df4ced831cf9f49c638c231fa9f2754699a8a59d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 01:41:14 2009 +0200

    Separate module documentation from frameworks documentation.

    Module documentation will list the classes in each module, how to use the
    respective libraries and headerfiles from a build-system perspective and
    what the legal implications are when linking against those libraries.

    The documentation of frameworks lives now in the frameworks subdirectory,
    or in dedicated subdirectories for the key frameworks.

commit f4ccabe1abb97f91f196dab1948fee6135c9fa6e
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 00:47:54 2009 +0200

    Group files in subdirectories that would correspond to top level topics.

commit ceb0110a364185b8b5d7bea3d3d1d54500035fcc
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 21:48:45 2009 +0200

    Group files in subdirectories that would correspond to top level topics.

commit 72a4dae65b25c9df400218252f1c68d59724ff75
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 20:57:39 2009 +0200

    Fix a few links.

commit ecb79681417e8bc3d8e46065dc12146f4d4dfc5f
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 20:20:55 2009 +0200

    Consolidate the two example documents into one page.

commit d30d980055e7c531c9e73cdf9a1b220ce9691eef
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 19:25:16 2009 +0200

    The QtAssistant module is obsolete, remove it.

    QAssistantClient is in the list of obsolete classes.

commit 137ecd1ee70f0766fd94c6199d8a6b8217d020ca
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 18:56:14 2009 +0200

    Get rid of \mainclass

    If we want to select a list of main classes, then we can use \ingroup for
    that, and document them coherently as part of the Fundamentals or a
    relevant framework.

commit 042a7f21e68120e43b68444cbf3cfeca3aad4488
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 18:23:55 2009 +0200

    The new index page and respective style changes.

commit 5245d784eb46287f8e1ae41addb2765eb19b0663
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 17:05:46 2009 +0200

    Deployment group is gone.

commit 567d737a8d08f227133674ebfe2d161888862b8c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 16:48:53 2009 +0200

    All "lists of classes etc" are now in classes.qdoc... I hope.

commit 0bb6074c0b38f07697e72a50a2ef60b561e718fe
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 16:47:20 2009 +0200

    Cleaning up files documenting deployment. Text need to be reviewed and merged.

commit 2df403da24a2959c02d0d845d1d4fac0c3aa38e0
Author: Thierry Bastian <thierry.bastian@nokia.com>
Date:   Mon Aug 3 16:49:46 2009 +0200

    fix warnings on mingw (gcc4.4)

    basically reordering members initialization in constructors or fixing
    singed/unsigned checks.

    Reviewed-by: Trustme

commit e887c7705b8b7f218b3605eeefb316dea274fe27
Author: Richard Moe Gustavsen <richard.gustavsen@nokia.com>
Date:   Tue Aug 4 10:00:01 2009 +0200

    Mac: Remove debug work output

commit 62687960508b2855b48d64825b445e5738c44142
Author: Richard Moe Gustavsen <richard.gustavsen@nokia.com>
Date:   Tue Aug 4 09:45:47 2009 +0200

    Modify imagewidget example so it works with new API

commit 9c7aed68270b336ae9a309d9eb0107d49729c1f3
Author: Richard Moe Gustavsen <richard.gustavsen@nokia.com>
Date:   Tue Aug 4 09:43:14 2009 +0200

    Add support for pan gesture on mac (carbon and cocoa)

commit be5783878a977148b34dc64c464e951be312964e
Author: Morten Sorvig <msorvig@trolltech.com>
Date:   Tue Aug 4 09:47:05 2009 +0200

    Remove the "preliminary support" warning for 10.6

    Also make the "usupported on > 10.6" error a warning. No need
    to stop the build, the warning will be printed enough times.

commit f6282eec434d073fef46d50ef141df6fa36033b9
Author: Morten Sorvig <msorvig@trolltech.com>
Date:   Tue Aug 4 09:31:56 2009 +0200

    Build on snow leopard.

    Don't error out when building qmake, just let it build a 64-bit binary (even for carbon)

    RebBy: Richard Moe Gustavsen

commit abae82a26f4dec34635827acf0784058be638e31
Author: Morten Sorvig <msorvig@trolltech.com>
Date:   Tue Aug 4 08:15:21 2009 +0200

    Make Cocoa builds 64-bit by default on snow leopard.

commit 4672e771c164503d998ccb6ca05cf7e7906fb031
Author: Jason McDonald <jason.mcdonald@nokia.com>
Date:   Tue Aug 4 15:40:15 2009 +1000

    Fix incorrect license headers.

    Reviewed-by: Trust Me

commit a3bd65e8eb0fd39e14539919cc9ced645c969883
Author: Bill King <bill.king@nokia.com>
Date:   Tue Aug 4 14:57:36 2009 +1000

    Fixes failed queries when mysql auto-prepares

    Queries like "Show Index" etc, fail on mysql when automatically prepared
    due to a bug in several versions of mysql. Basically anything but a
    select query will fail. This fixes this by making the user explicitly
    prepare the query if they want to, and the blame then falls on them
    if they try and prepare a statement likely to fail.  This fix also
    seems to result in a speedup for single-execution queries, possibly
    due to reduction in roundtrip communications.

    All autotests pass & behaviour conforms to documentation.

    Task-number: 252450, 246125

commit 4612596a6a945ab0199fe06727ff3ea350092ec1
Author: Jason McDonald <jason.mcdonald@nokia.com>
Date:   Tue Aug 4 14:49:14 2009 +1000

    Fix obsolete license headers

    Reviewed-by: Trust Me

commit c3bcc8b094341e0dc768ef5820ba359e2c23436a
Author: Aaron Kennedy <aaron.kennedy@nokia.com>
Date:   Tue Aug 4 10:59:02 2009 +1000

    Doc fixes

    Reviewed-by: TrustMe

commit 1d60528ced1f6818a60889d672089bfe4d2290bb
Author: Morten Sorvig <msorvig@trolltech.com>
Date:   Mon Aug 3 15:57:44 2009 +0200

    Fix spelling error.

commit e99794c1200515f18ffdd0bec9c143db46e009a1
Merge: 199db81 d65f893
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 09:24:14 2009 +0200

    Merge branch 'master' into doccleanup

commit 199db8104a680f91451cf2c93d2d41077b5605bb
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Tue Aug 4 00:04:40 2009 +0200

    Fix some headers.

commit e8f8193b951a9f9e4b6d309c44151c47b715e901
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 23:48:17 2009 +0200

    Split the accessibility docu into a "compared to Qt 3" section, and move
    real information into the overview.

commit 8006ec36024e972be21e8397c2cc758a0e9b2ba0
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 23:47:37 2009 +0200

    The gui-programming seems rather arbitrary and should go away.

    Some things fit into the desktop integration, which is probably more a
    howto. Focus is a concept in the widgets context, and application-wide
    techniques like accelerators should probably be part of the "window"
    docu.

commit 8dab96460280b8af6726905e8d5d24020930b882
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 23:45:28 2009 +0200

    Move "Getting Started" documentation into getting-started directory.

commit 523fd47c29c24a865855d085a0036fc741203930
Merge: a1e50f6 2076f15
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 19:10:51 2009 +0200

    Merge branch 'master' into doccleanup

commit a1e50f6619ff1a302dd1fefbcb6b0cd62a653e7d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 19:06:16 2009 +0200

    Group "getting started" documents into a walkthrough structure.

commit e393b4f458263cb2f011cc5e5e67cdcc48610ea9
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 17:35:15 2009 +0200

    Add screenshots for example-overview page.

commit 8c84f307f73ab7b77a91e61ed18fdc685afebcc5
Merge: a16033a 34e272a
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Mon Aug 3 11:03:41 2009 +0200

    Merge branch 'master' into doccleanup

commit a16033a287afe2f494401e24f02f046ec98d944c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 2 16:57:04 2009 +0200

    Link to the real documentation, not just to the modules overview.

commit 6c4ed0361c860e738b9344dfb191f55d35b3309f
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sun Aug 2 16:56:41 2009 +0200

    A new layout for the examples.

    Needs a bit of shuffeling around, and more screenshots and descriptive text
    for some categories.

commit 2dde2faa8f6e86acf738a808412c5e3c21c44658
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 22:39:27 2009 +0200

    Cleanup the script-related groups a bit.

commit a66227d0bed87c633a22a4d155f6a7f0061fc34e
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 22:17:16 2009 +0200

    Add QContiguousCache to the list of containers as a special case.

commit b22133eef28566f1c3c5d57aa0e8272af26da86a
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 21:52:37 2009 +0200

    Cleaning up groups of text- and string-related classes.

    Make a clear separation between classes that deal with string data (ie
    QString, QByteArray, QTextStream) and classes that are part of the "scribe"
    framework.

    Merge documentation from the Qt 4.0 introduction of Scribe into the
    richtext processing guide.

commit b30ba739308905b6c06987cec47d4de1e5d172de
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 20:50:06 2009 +0200

    One group of thread-related classes should be enough.

commit a2511650577126026f98cb7416c159498f6f2db5
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 19:32:21 2009 +0200

    Move documentation for classes into same directory as the respective
    header files (or implementation file, if one exists).

    This follows the Qt standard, and there is no particular reason why .qdoc
    files cannot live in src. Since there are a number of .cpp files that have
    only documentation it might also be an idea to rename the .qdoc files to
    .cpp and add them to the .pro-files to have them included in generated
    project files for easier access.

commit f333ad71384cf42c20219a55d9dfa1e29a8c263e
Merge: bad9ba5 5aed3db
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Sat Aug 1 12:04:55 2009 +0200

    Merge branch 'master' into doccleanup

commit bad9ba5468333be2f08da7f28950c980bc63c787
Merge: 49f38b7 c57ed13
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 19:31:04 2009 +0200

    Merge branch 'master' into doccleanup

commit 49f38b7afe3205eedccf655c0ad749d685cb3d52
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 19:29:46 2009 +0200

    Starting to tie together the widgets and layouts groups and documentation.

commit e6c4b8316b7c90b19815c0008a282983012c68b3
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 18:43:34 2009 +0200

    This is all duplicate information that is better covered in the
    sql-programming guide.

commit 620620ae969bed86d970519bead45762bd39ede1
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 18:37:53 2009 +0200

    Consolidate style documentation.

commit 01c78ff78888d3ccb50189206b9bcacaf13f5c80
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 17:13:44 2009 +0200

    Split plugin-documentation into two: writing plugins and deploying plugins.

commit a21f510c982dce06ac1769e61e93574f90cc48c4
Merge: da93c4c c6cdfcb
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 16:04:51 2009 +0200

    Merge branch 'master' into doccleanup

commit da93c4ccc25dd189dfb9b71bda28bd1e3a7230c1
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 14:19:47 2009 +0200

    Some final module cleaning up.

commit 9eb0815bbd01b7e30877110b53aa6f82b8e9221d
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:51:54 2009 +0200

    Move remaining overview groups into one file.

commit 65d4c4145386a409aeb1372ae5adc6f3e71e444b
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:51:34 2009 +0200

    The "io" group should be about file access (be it local or networked).

commit 1a3de3a7add6d9e7653e46b57b00852845384a42
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:36:51 2009 +0200

    Kill the "time" group.

    The "How to use timers in your application" documentation covers the usecase.

commit dbadf1c060e051dbac7f5c72528ef6a3125d5ba3
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:28:21 2009 +0200

    Kill the group "misc".

commit 7b7484b37b074d52af5c4ff9b138087a75965508
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:09:24 2009 +0200

    Kill the "Environment" group.

    It was a random collection of classes, mostly ending up in there because
    of copy/paste (I suspect).

commit b5271d81e7da6666d339041d028a0ae6c8ed75c4
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 13:08:37 2009 +0200

    More moving of files and content.

commit 96a707d25342c273cdd7629fc1e24b0ead4118de
Merge: 4ffe572 18fbfdf
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 11:08:11 2009 +0200

    Merge branch 'master' into doccleanup

commit 4ffe572a954e99d604c1360fc55db25e8586436c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 02:03:07 2009 +0200

    Workaround qdoc being difficult.

commit 7f0e965c7cf613782e8189069444a4b549f0c11a
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 01:49:52 2009 +0200

    Some more moving of files into meaningful directories.

commit b0d67674469e57b29e60110888352ae955adcdd8
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 01:41:14 2009 +0200

    Separate module documentation from frameworks documentation.

    Module documentation will list the classes in each module, how to use the
    respective libraries and headerfiles from a build-system perspective and
    what the legal implications are when linking against those libraries.

    The documentation of frameworks lives now in the frameworks subdirectory,
    or in dedicated subdirectories for the key frameworks.

commit 45240a9c0eba9e42e6e441a55a407173a81a7344
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Fri Jul 31 00:47:54 2009 +0200

    Group files in subdirectories that would correspond to top level topics.

commit 896507f2f4fdc541fc436cf901a2beb72d35f6aa
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 21:48:45 2009 +0200

    Group files in subdirectories that would correspond to top level topics.

commit 37eb554f75d8b1d9d76993f6fcf632933c9616a2
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 20:57:39 2009 +0200

    Fix a few links.

commit 74027c3568c1bdbb9960d203266f4ccc5e89c05c
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 20:20:55 2009 +0200

    Consolidate the two example documents into one page.

commit cfc0fd3df050cf6c0e3229d22adfbff35aed46af
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 19:25:16 2009 +0200

    The QtAssistant module is obsolete, remove it.

    QAssistantClient is in the list of obsolete classes.

commit 0f86c7a176fc920669ca8a880afa141434f37767
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 18:56:14 2009 +0200

    Get rid of \mainclass

    If we want to select a list of main classes, then we can use \ingroup for
    that, and document them coherently as part of the Fundamentals or a
    relevant framework.

commit c4dfbc6bf58ef741fdab01538e75e9472e8370bf
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 18:23:55 2009 +0200

    The new index page and respective style changes.

commit a3e4eb6712e24a4d6156c340ee98671887a2b2fa
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 17:05:46 2009 +0200

    Deployment group is gone.

commit f03ee6192450db977bc2e4b07ffc613314b63a80
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 16:48:53 2009 +0200

    All "lists of classes etc" are now in classes.qdoc... I hope.

commit c5fb9a4b5208498454812d27578ac62ae23652a4
Author: Volker Hilsheimer <volker.hilsheimer@nokia.com>
Date:   Thu Jul 30 16:47:20 2009 +0200

    Cleaning up files documenting deployment. Text need to be reviewed and merged.

4 files changed, 1891 insertions, 0 deletions

diff --git a/doc/src/deployment/deployment-plugins.qdoc b/doc/src/deployment/deployment-plugins.qdoc
new file mode 100644
index 0000000000..b02bdd8c54
--- /dev/null
+++ b/doc/src/deployment/deployment-plugins.qdoc
@@ -0,0 +1,236 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at http://qt.nokia.com/contact.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+    \page deployment-plugins.html
+    \title Deploying Plugins
+    \brief A guide to plugins-specific aspects of deploying Qt and Qt Application
+
+    This document explains how to deploy plugin libraries that Qt or
+    your application should load at runtime. If you use
+    \l{How to Create Qt Plugins#Static Plugins}{static plugins}, then the
+    plugin code is already part of your application executable, and no
+    separate deployment steps are required.
+
+    \tableofcontents
+
+    \section1 The Plugin Directory
+
+    When the application is run, Qt will first treat the application's
+    executable directory as the \c{pluginsbase}. For example if the
+    application is in \c{C:\Program Files\MyApp} and has a style plugin,
+    Qt will look in \c{C:\Program Files\MyApp\styles}. (See
+    QCoreApplication::applicationDirPath() for how to find out where
+    the application's executable is.) Qt will also look in the
+    directory specified by
+    QLibraryInfo::location(QLibraryInfo::PluginsPath), which typically
+    is located in \c QTDIR/plugins (where \c QTDIR is the directory
+    where Qt is installed). If you want Qt to look in additional
+    places you can add as many paths as you need with calls to
+    QCoreApplication::addLibraryPath(). And if you want to set your
+    own path or paths you can use QCoreApplication::setLibraryPaths().
+    You can also use a \c qt.conf file to override the hard-coded
+    paths that are compiled into the Qt library. For more information,
+    see the \l {Using qt.conf} documentation. Yet another possibility
+    is to set the \c QT_PLUGIN_PATH environment variable before running
+    the application. If set, Qt will look for plugins in the
+    paths (separated by the system path separator) specified in the variable.
+
+    \section1 Loading and Verifying Plugins Dynamically
+
+    When loading plugins, the Qt library does some sanity checking to
+    determine whether or not the plugin can be loaded and used. This
+    provides the ability to have multiple versions and configurations of
+    the Qt library installed side by side.
+
+    \list
+    \o Plugins linked with a Qt library that has a higher version number
+       will not be loaded by a library with a lower version number.
+
+      \br
+      \bold{Example:} Qt 4.3.0 will \e{not} load a plugin built with Qt 4.3.1.
+
+    \o Plugins linked with a Qt library that has a lower major version
+       number will not be loaded by a library with a higher major version
+       number.
+
+      \br
+      \bold{Example:} Qt 4.3.1 will \e{not} load a plugin built with Qt 3.3.1.
+      \br
+      \bold{Example:} Qt 4.3.1 will load plugins built with Qt 4.3.0 and Qt 4.2.3.
+
+    \o The Qt library and all plugins are built using a \e {build
+       key}. The build key in the Qt library is examined against the build
+       key in the plugin, and if they match, the plugin is loaded. If the
+       build keys do not match, then the Qt library refuses to load the
+       plugin.
+
+      \br \bold{Rationale:} See the \l{#The Build Key}{The Build Key} section below.
+    \endlist
+
+    When building plugins to extend an application, it is important to ensure
+    that the plugin is configured in the same way as the application. This means
+    that if the application was built in release mode, plugins should be built
+    in release mode, too.
+
+    If you configure Qt to be built in both debug and release modes,
+    but only build applications in release mode, you need to ensure that your
+    plugins are also built in release mode. By default, if a debug build of Qt is
+    available, plugins will \e only be built in debug mode. To force the
+    plugins to be built in release mode, add the following line to the plugin's
+    project file:
+
+    \snippet doc/src/snippets/code/doc_src_plugins-howto.qdoc 3
+
+    This will ensure that the plugin is compatible with the version of the library
+    used in the application.
+
+    \section2 The Build Key
+
+    When loading plugins, Qt checks the build key of each plugin against its
+    own configuration to ensure that only compatible plugins are loaded; any
+    plugins that are configured differently are not loaded.
+
+    The build key contains the following information:
+    \list
+    \o Architecture, operating system and compiler.
+
+       \e {Rationale:}
+       In cases where different versions of the same compiler do not
+       produce binary compatible code, the version of the compiler is
+       also present in the build key.
+
+    \o Configuration of the Qt library. The configuration is a list
+       of the missing features that affect the available API in the
+       library.
+
+       \e {Rationale:}
+       Two different configurations of the same version of
+       the Qt library are not binary compatible. The Qt library that
+       loads the plugin uses the list of (missing) features to
+       determine if the plugin is binary compatible.
+
+       \e {Note:} There are cases where a plugin can use features that are
+       available in two different configurations. However, the
+       developer writing plugins would need to know which features are
+       in use, both in their plugin and internally by the utility
+       classes in Qt. The Qt library would require complex feature
+       and dependency queries and verification when loading plugins.
+       Requiring this would place an unnecessary burden on the developer, and
+       increase the overhead of loading a plugin. To reduce both
+       development time and application runtime costs, a simple string
+       comparision of the build keys is used.
+
+    \o Optionally, an extra string may be specified on the configure
+       script command line.
+
+       \e {Rationale:}
+       When distributing binaries of the Qt library with an
+       application, this provides a way for developers to write
+       plugins that can only be loaded by the library with which the
+       plugins were linked.
+    \endlist
+
+    For debugging purposes, it is possible to override the run-time build key
+    checks by configuring Qt with the \c QT_NO_PLUGIN_CHECK preprocessor macro
+    defined.
+
+    \section1 The Plugin Cache
+
+    In order to speed up loading and validation of plugins, some of
+    the information that is collected when plugins are loaded is cached
+    through QSettings. This includes information about whether or not
+    a plugin was successfully loaded, so that subsequent load operations
+    don't try to load an invalid plugin. However, if the "last modified"
+    timestamp of a plugin has changed, the plugin's cache entry is
+    invalidated and the plugin is reloaded regardless of the values in
+    the cache entry, and the cache entry itself is updated with the new
+    result.
+
+    This also means that the timestamp must be updated each time the
+    plugin or any dependent resources (such as a shared library) is
+    updated, since the dependent resources might influence the result
+    of loading a plugin.
+
+    Sometimes, when developing plugins, it is necessary to remove entries
+    from the plugin cache. Since Qt uses QSettings to manage the plugin
+    cache, the locations of plugins are platform-dependent; see
+    \l{QSettings#Platform-Specific Notes}{the QSettings documentation}
+    for more information about each platform.
+
+    For example, on Windows the entries are stored in the registry, and the
+    paths for each plugin will typically begin with either of these two strings:
+
+    \snippet doc/src/snippets/code/doc_src_plugins-howto.qdoc 6
+
+    \section1 Debugging Plugins
+
+    There are a number of issues that may prevent correctly-written plugins from
+    working with the applications that are designed to use them. Many of these
+    are related to differences in the way that plugins and applications have been
+    built, often arising from separate build systems and processes.
+
+    The following table contains descriptions of the common causes of problems
+    developers experience when creating plugins:
+
+    \table
+    \header \o Problem \o Cause \o Solution
+    \row \o Plugins sliently fail to load even when opened directly by the
+            application. \QD shows the plugin libraries in its
+            \gui{Help|About Plugins} dialog, but no plugins are listed under each
+            of them.
+         \o The application and its plugins are built in different modes.
+         \o Either share the same build information or build the plugins in both
+            debug and release modes by appending the \c debug_and_release to
+            the \l{qmake Variable Reference#CONFIG}{CONFIG} variable in each of
+            their project files.
+    \row \o A valid plugin that replaces an invalid (or broken) plugin fails to load.
+         \o The entry for the plugin in the plugin cache indicates that the original
+            plugin could not be loaded, causing Qt to ignore the replacement.
+         \o Either ensure that the plugin's timestamp is updated, or delete the
+            entry in the \l{#The Plugin Cache}{plugin cache}.
+    \endtable
+
+    You can also use the \c QT_DEBUG_PLUGINS environment variable to obtain
+    diagnostic information from Qt about each plugin it tries to load. Set this
+    variable to a non-zero value in the environment from which your application is
+    launched.
+*/
diff --git a/doc/src/deployment/deployment.qdoc b/doc/src/deployment/deployment.qdoc
new file mode 100644
index 0000000000..75b870fd60
--- /dev/null
+++ b/doc/src/deployment/deployment.qdoc
@@ -0,0 +1,1464 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at http://qt.nokia.com/contact.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+    \page deployment.html
+    \title Deploying Qt Applications
+
+    Deploying an Qt application does not require any C++
+    programming. All you need to do is to build Qt and your
+    application in release mode, following the procedures described in
+    this documentation. We will demonstrate the procedures in terms of
+    deploying the \l {tools/plugandpaint}{Plug & Paint} application
+    that is provided in Qt's examples directory.
+
+    \section1 Static vs. Shared Libraries
+
+    There are two ways of deploying an application:
+
+    \list
+        \o Static Linking
+        \o Shared Libraries (Frameworks on Mac)
+    \endlist
+
+    Static linking results in a stand-alone executable. The advantage
+    is that you will only have a few files to deploy. The
+    disadvantages are that the executables are large and with no
+    flexibility (i.e a new version of the application, or of Qt, will
+    require that the deployment process is repeated), and that you
+    cannot deploy plugins.
+
+    To deploy plugin-based applications, you can use the shared
+    library approach. Shared libraries also provide smaller, more
+    flexible executables. For example, using the shared library
+    approach, the user is able to independently upgrade the Qt library
+    used by the application.
+
+    Another reason why you might want to use the shared library
+    approach, is if you want to use the same Qt libraries for a family
+    of applications. In fact, if you download the binary installation
+    of Qt, you get Qt as a shared library.
+
+    The disadvantage with the shared library approach is that you
+    will get more files to deploy. For more information, see
+    \l{sharedlibrary.html}{Creating Shared Libraries}.
+
+    \section1 Deploying Qt's Libraries
+
+    \table
+    \header
+        \o {4,1} Qt's Libraries
+    \row
+        \o \l {QtAssistant}
+        \o \l {QAxContainer}
+        \o \l {QAxServer}
+        \o \l {QtCore}
+    \row
+        \o \l {QtDBus}
+        \o \l {QtDesigner}
+        \o \l {QtGui}
+        \o \l {QtHelp}
+    \row
+        \o \l {QtNetwork}
+        \o \l {QtOpenGL}
+        \o \l {QtScript}
+        \o \l {QtScriptTools}
+    \row
+        \o \l {QtSql}
+        \o \l {QtSvg}
+        \o \l {QtWebKit}
+        \o \l {QtXml}
+    \row
+        \o \l {QtXmlPatterns}
+        \o \l {Phonon Module}{Phonon}
+        \o \l {Qt3Support}
+    \endtable
+
+    Since Qt is not a system library, it has to be redistributed along
+    with your application; the minimum is to redistribute the run-time
+    of the libraries used by the application.  Using static linking,
+    however, the Qt run-time is compiled into the executable.
+
+    In particular, you will need to deploy Qt plugins, such as
+    JPEG support or SQL drivers. For more information about plugins,
+    see the \l {plugins-howto.html}{How to Create Qt Plugins}
+    documentation.
+
+    When deploying an application using the shared library approach
+    you must ensure that the Qt libraries will use the correct path to
+    find the Qt plugins, documentation, translation etc. To do this you
+    can use a \c qt.conf file. For more information, see the \l {Using
+    qt.conf} documentation.
+
+    Depending on configuration, compiler specific libraries must be
+    redistributed as well. For more information, see the platform
+    specific Application Dependencies sections: \l
+    {deployment-x11.html#application-dependencies}{X11}, \l
+    {deployment-windows.html#application-dependencies}{Windows}, \l
+    {deployment-mac.html#application-dependencies}{Mac}.
+
+    \section1 Licensing
+
+    Some of Qt's libraries are based on third party libraries that are
+    not licensed using the same dual-license model as Qt. As a result,
+    care must be taken when deploying applications that use these
+    libraries, particularly when the application is statically linked
+    to them.
+
+    The following table contains an inexhaustive summary of the issues
+    you should be aware of.
+
+    \table
+    \header \o Qt Library \o Dependency
+            \o Licensing Issue
+    \row    \o QtHelp     \o CLucene
+    \o The version of clucene distributed with Qt is licensed
+    under the GNU LGPL version 2.1 or later. This has implications for
+    developers of closed source applications. Please see
+    \l{QtHelp Module#License Information}{the QtHelp module documentation}
+    for more information.
+
+    \row    \o QtNetwork  \o OpenSSL
+    \o Some configurations of QtNetwork use OpenSSL at run-time. Deployment
+    of OpenSSL libraries is subject to both licensing and export restrictions.
+    More information can be found in the \l{Secure Sockets Layer (SSL) Classes}
+    documentation.
+
+    \row    \o QtWebKit   \o WebKit
+    \o WebKit is licensed under the GNU LGPL version 2 or later.
+    This has implications for developers of closed source applications.
+    Please see \l{QtWebKit Module#License Information}{the QtWebKit module
+    documentation} for more information.
+
+    \row    \o \l{Phonon Module}{Phonon}     \o Phonon
+    \o Phonon relies on the native multimedia engines on different platforms.
+    Phonon itself is licensed under the GNU LGPL version 2. Please see
+    \l{Phonon Module#License Information}{the Phonon module documentation}
+    for more information on licensing and the
+    \l{Phonon Overview#Backends}{Phonon Overview} for details of the backends
+    in use on different platforms.
+    \endtable
+
+    \section1 Platform-Specific Notes
+
+    The procedure of deploying Qt applications is different for the
+    various platforms:
+
+    \list
+        \o \l{Deploying an Application on X11 Platforms}{Qt for X11 Platforms}
+        \o \l{Deploying an Application on Windows}{Qt for Windows}
+        \o \l{Deploying an Application on Mac OS X}{Qt for Mac OS X}
+        \o \l{Deploying Qt for Embedded Linux Applications}{Qt for Embedded Linux}
+    \endlist
+
+    \sa Installation {Platform-Specific Documentation}
+*/
+
+/*!
+    \page deployment-x11.html
+    \contentspage Deploying Qt Applications
+
+    \title Deploying an Application on X11 Platforms
+
+    Due to the proliferation of Unix systems (commercial Unices, Linux
+    distributions, etc.), deployment on Unix is a complex
+    topic. Before we start, be aware that programs compiled for one
+    Unix flavor will probably not run on a different Unix system. For
+    example, unless you use a cross-compiler, you cannot compile your
+    application on Irix and distribute it on AIX.
+
+    Contents:
+
+    \tableofcontents
+
+    This documentation will describe how to determine which files you
+    should include in your distribution, and how to make sure that the
+    application will find them at run-time. We will demonstrate the
+    procedures in terms of deploying the \l {tools/plugandpaint}{Plug
+    & Paint} application that is provided in Qt's examples directory.
+
+    \section1 Static Linking
+
+    Static linking is often the safest and easiest way to distribute
+    an application on Unix since it relieves you from the task of
+    distributing the Qt libraries and ensuring that they are located
+    in the default search path for libraries on the target system.
+
+    \section2 Building Qt Statically
+
+    To use this approach, you must start by installing a static version
+    of the Qt library:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 0
+
+    We specify the prefix so that we do not overwrite the existing Qt
+    installation. The example above only builds the Qt libraries,
+    i.e. the examples and Qt Designer will not be built.  When \c make
+    is done, you will find the Qt libraries in the \c /path/to/Qt/lib
+    directory.
+
+    When linking your application against static Qt libraries, note
+    that you might need to add more libraries to the \c LIBS line in
+    your project file. For more information, see the \l {Application
+    Dependencies} section.
+
+    \section2 Linking the Application to the Static Version of Qt
+
+    Once Qt is built statically, the next step is to regenerate the
+    makefile and rebuild the application. First, we must go into the
+    directory that contains the application:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 1
+
+    Now run qmake to create a new makefile for the application, and do
+    a clean build to create the statically linked executable:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 2
+
+    You probably want to link against the release libraries, and you
+    can specify this when invoking \c qmake. Note that we must set the
+    path to the static Qt that we just built.
+
+    To check that the application really links statically with Qt, run
+    the \c ldd tool (available on most Unices):
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 3
+
+    Verify that the Qt libraries are not mentioned in the output.
+
+    Now, provided that everything compiled and linked without any
+    errors, we should have a \c plugandpaint file that is ready for
+    deployment. One easy way to check that the application really can
+    be run stand-alone is to copy it to a machine that doesn't have Qt
+    or any Qt applications installed, and run it on that machine.
+
+    Remember that if your application depends on compiler specific
+    libraries, these must still be redistributed along with your
+    application. For more information, see the \l {Application
+    Dependencies} section.
+
+    The \l {tools/plugandpaint}{Plug & Paint} example consists of
+    several components: The core application (\l
+    {tools/plugandpaint}{Plug & Paint}), and the \l
+    {tools/plugandpaintplugins/basictools}{Basic Tools} and \l
+    {tools/plugandpaintplugins/extrafilters}{Extra Filters}
+    plugins. Since we cannot deploy plugins using the static linking
+    approach, the executable we have prepared so far is
+    incomplete. The application will run, but the functionality will
+    be disabled due to the missing plugins. To deploy plugin-based
+    applications we should use the shared library approach.
+
+    \section1 Shared Libraries
+
+    We have two challenges when deploying the \l
+    {tools/plugandpaint}{Plug & Paint} application using the shared
+    libraries approach: The Qt runtime has to be correctly
+    redistributed along with the application executable, and the
+    plugins have to be installed in the correct location on the target
+    system so that the application can find them.
+
+    \section2 Building Qt as a Shared Library
+
+    We assume that you already have installed Qt as a shared library,
+    which is the default when installing Qt, in the \c /path/to/Qt
+    directory. For more information on how to build Qt, see the \l
+    {Installation} documentation.
+
+    \section2 Linking the Application to Qt as a Shared Library
+
+    After ensuring that Qt is built as a shared library, we can build
+    the \l {tools/plugandpaint}{Plug & Paint} application. First, we
+    must go into the directory that contains the application:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 4
+
+    Now run qmake to create a new makefile for the application, and do
+    a clean build to create the dynamically linked executable:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 5
+
+    This builds the core application, the following will build the
+    plugins:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 6
+
+    If everything compiled and linked without any errors, we will get
+    a \c plugandpaint executable and the \c libpnp_basictools.so and
+    \c libpnp_extrafilters.so plugin files.
+
+    \section2 Creating the Application Package
+
+    There is no standard package management on Unix, so the method we
+    present below is a generic solution. See the documentation for
+    your target system for information on how to create a package.
+
+    To deploy the application, we must make sure that we copy the
+    relevant Qt libraries (corresponding to the Qt modules used in the
+    application) as well as the executable to the same
+    directory. Remember that if your application depends on compiler
+    specific libraries, these must also be redistributed along with
+    your application. For more information, see the \l {Application
+    Dependencies} section.
+
+    We'll cover the plugins shortly, but the main issue with shared
+    libraries is that you must ensure that the dynamic linker will
+    find the Qt libraries. Unless told otherwise, the dynamic linker
+    doesn't search the directory where your application resides. There
+    are many ways to solve this:
+
+    \list
+    \o You can install the Qt libraries in one of the system
+       library paths (e.g. \c /usr/lib on most systems).
+
+    \o You can pass a predetermined path to the \c -rpath command-line
+       option when linking the application. This will tell the dynamic
+       linker to look in this directory when starting your application.
+
+    \o You can write a startup script for your application, where you
+       modify the dynamic linker configuration (e.g.  adding your
+       application's directory to the \c LD_LIBRARY_PATH environment
+       variable. \note If your application will be running with "Set
+       user ID on execution," and if it will be owned by root, then
+       LD_LIBRARY_PATH will be ignored on some platforms. In this
+       case, use of the LD_LIBRARY_PATH approach is not an option).
+
+    \endlist
+
+    The disadvantage of the first approach is that the user must have
+    super user privileges. The disadvantage of the second approach is
+    that the user may not have privileges to install into the
+    predetemined path. In either case, the users don't have the option
+    of installing to their home directory. We recommend using the
+    third approach since it is the most flexible. For example, a \c
+    plugandpaint.sh script will look like this:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 7
+
+    By running this script instead of the executable, you are sure
+    that the Qt libraries will be found by the dynamic linker. Note
+    that you only have to rename the script to use it with other
+    applications.
+
+    When looking for plugins, the application searches in a plugins
+    subdirectory inside the directory of the application
+    executable. Either you have to manually copy the plugins into the
+    \c plugins directory, or you can set the \c DESTDIR in the
+    plugins' project files:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 8
+
+    An archive distributing all the Qt libraries, and all the plugins,
+    required to run the \l {tools/plugandpaint}{Plug & Paint}
+    application, would have to include the following files:
+
+    \table 100%
+    \header
+        \o Component \o {2, 1} File Name
+    \row
+        \o The executable
+        \o {2, 1} \c plugandpaint
+    \row
+        \o The script to run the executable
+        \o {2, 1} \c plugandpaint.sh
+    \row
+        \o The Basic Tools plugin
+        \o {2, 1} \c plugins\libpnp_basictools.so
+    \row
+        \o The ExtraFilters plugin
+        \o {2, 1} \c plugins\libpnp_extrafilters.so
+    \row
+        \o The Qt Core module
+        \o {2, 1} \c libQtCore.so.4
+    \row
+        \o The Qt GUI module
+        \o {2, 1} \c libQtGui.so.4
+    \endtable
+
+    On most systems, the extension for shared libraries is \c .so. A
+    notable exception is HP-UX, which uses \c .sl.
+
+    Remember that if your application depends on compiler specific
+    libraries, these must still be redistributed along with your
+    application. For more information, see the \l {Application
+    Dependencies} section.
+
+    To verify that the application now can be successfully deployed,
+    you can extract this archive on a machine without Qt and without
+    any compiler installed, and try to run it, i.e. run the \c
+    plugandpaint.sh script.
+
+    An alternative to putting the plugins in the \c plugins
+    subdirectory is to add a custom search path when you start your
+    application using QApplication::addLibraryPath() or
+    QApplication::setLibraryPaths().
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 9
+
+    \section1 Application Dependencies
+
+    \section2 Additional Libraries
+
+    To find out which libraries your application depends on, run the
+    \c ldd tool (available on most Unices):
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 10
+
+    This will list all the shared library dependencies for your
+    application. Depending on configuration, these libraries must be
+    redistributed along with your application. In particular, the
+    standard C++ library must be redistributed if you're compiling
+    your application with a compiler that is binary incompatible with
+    the system compiler. When possible, the safest solution is to link
+    against these libraries statically.
+
+    You will probably want to link dynamically with the regular X11
+    libraries, since some implementations will try to open other
+    shared libraries with \c dlopen(), and if this fails, the X11
+    library might cause your application to crash.
+
+    It's also worth mentioning that Qt will look for certain X11
+    extensions, such as Xinerama and Xrandr, and possibly pull them
+    in, including all the libraries that they link against. If you
+    can't guarantee the presence of a certain extension, the safest
+    approach is to disable it when configuring Qt (e.g. \c {./configure
+    -no-xrandr}).
+
+    FontConfig and FreeType are other examples of libraries that
+    aren't always available or that aren't always binary
+    compatible. As strange as it may sound, some software vendors have
+    had success by compiling their software on very old machines and
+    have been very careful not to upgrade any of the software running
+    on them.
+
+    When linking your application against the static Qt libraries, you
+    must explicitly link with the dependent libraries mentioned
+    above. Do this by adding them to the \c LIBS variable in your
+    project file.
+
+    \section2 Qt Plugins
+
+    Your application may also depend on one or more Qt plugins, such
+    as the JPEG image format plugin or a SQL driver plugin. Be sure
+    to distribute any Qt plugins that you need with your application,
+    and note that each type of plugin should be located within a
+    specific subdirectory (such as \c imageformats or \c sqldrivers)
+    within your distribution directory, as described below.
+
+    \note If you are deploying an application that uses QtWebKit to display
+    HTML pages from the World Wide Web, you should include all text codec
+    plugins to support as many HTML encodings possible. 
+
+    The search path for Qt plugins (as well as a few other paths) is
+    hard-coded into the QtCore library. By default, the first plugin
+    search path will be hard-coded as \c /path/to/Qt/plugins. As
+    mentioned above, using pre-determined paths has certain
+    disadvantages, so you need to examine various alternatives to make
+    sure that the Qt plugins are found:
+
+    \list
+
+    \o \l{qt-conf.html}{Using \c qt.conf}. This is the recommended
+    approach since it provides the most flexibility.
+
+    \o Using QApplication::addLibraryPath() or
+    QApplication::setLibraryPaths().
+
+    \o Using a third party installation utility or the target system's
+    package manager to change the hard-coded paths in the QtCore
+    library.
+
+    \endlist
+
+    The \l{How to Create Qt Plugins} document outlines the issues you
+    need to pay attention to when building and deploying plugins for
+    Qt applications.
+*/
+
+/*!
+    \page deployment-windows.html
+    \contentspage Deploying Qt Applications
+
+    \title Deploying an Application on Windows
+
+    This documentation will describe how to determine which files you
+    should include in your distribution, and how to make sure that the
+    application will find them at run-time. We will demonstrate the
+    procedures in terms of deploying the \l {tools/plugandpaint}{Plug
+    & Paint} application that is provided in Qt's examples directory.
+
+    Contents:
+
+    \tableofcontents
+
+    \section1 Static Linking
+
+    If you want to keep things simple by only having a few files to
+    deploy, i.e. a stand-alone executable with the associated compiler
+    specific DLLs, then you must build everything statically.
+
+    \section2 Building Qt Statically
+
+    Before we can build our application we must make sure that Qt is
+    built statically. To do this, go to a command prompt and type the
+    following:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 11
+
+    Remember to specify any other options you need, such as data base
+    drivers, as arguments to \c configure. Once \c configure has
+    finished, type the following:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 12
+
+    This will build Qt statically. Note that unlike with a dynamic build,
+    building Qt statically will result in libraries without version numbers;
+    e.g. \c QtCore4.lib will be \c QtCore.lib. Also, we have used \c nmake
+    in all the examples, but if you use MinGW you must use
+    \c mingw32-make instead.
+
+    \note If you later need to reconfigure and rebuild Qt from the
+    same location, ensure that all traces of the previous configuration are
+    removed by entering the build directory and typing \c{nmake distclean}
+    before running \c configure again.
+
+    \section2 Linking the Application to the Static Version of Qt
+
+    Once Qt has finished building we can build the \l
+    {tools/plugandpaint}{Plug & Paint} application. First we must go
+    into the directory that contains the application:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 13
+
+    We must then run \c qmake to create a new makefile for the
+    application, and do a clean build to create the statically linked
+    executable:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 14
+
+    You probably want to link against the release libraries, and you
+    can specify this when invoking \c qmake. Now, provided that
+    everything compiled and linked without any errors, we should have
+    a \c plugandpaint.exe file that is ready for deployment. One easy
+    way to check that the application really can be run stand-alone is
+    to copy it to a machine that doesn't have Qt or any Qt
+    applications installed, and run it on that machine.
+
+    Remember that if your application depends on compiler specific
+    libraries, these must still be redistributed along with your
+    application. You can check which libraries your application is
+    linking against by using the \c depends tool. For more
+    information, see the \l {Application Dependencies} section.
+
+    The \l {tools/plugandpaint}{Plug & Paint} example consists of
+    several components: The application itself (\l
+    {tools/plugandpaint}{Plug & Paint}), and the \l
+    {tools/plugandpaintplugins/basictools}{Basic Tools} and \l
+    {tools/plugandpaintplugins/extrafilters}{Extra Filters}
+    plugins. Since we cannot deploy plugins using the static linking
+    approach, the application we have prepared is incomplete. It will
+    run, but the functionality will be disabled due to the missing
+    plugins. To deploy plugin-based applications we should use the
+    shared library approach.
+
+    \section1 Shared Libraries
+
+    We have two challenges when deploying the \l
+    {tools/plugandpaint}{Plug & Paint} application using the shared
+    libraries approach: The Qt runtime has to be correctly
+    redistributed along with the application executable, and the
+    plugins have to be installed in the correct location on the target
+    system so that the application can find them.
+
+    \section2 Building Qt as a Shared Library
+
+    We assume that you already have installed Qt as a shared library,
+    which is the default when installing Qt, in the \c C:\path\to\Qt
+    directory. For more information on how to build Qt, see the \l
+    {Installation} documentation.
+
+    \section2 Linking the Application to Qt as a Shared Library
+
+    After ensuring that Qt is built as a shared library, we can build
+    the \l {tools/plugandpaint}{Plug & Paint} application. First, we
+    must go into the directory that contains the application:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 15
+
+    Now run \c qmake to create a new makefile for the application, and
+    do a clean build to create the dynamically linked executable:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 16
+
+    This builds the core application, the following will build the
+    plugins:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 17
+
+    If everything compiled and linked without any errors, we will get
+    a \c plugandpaint.exe executable and the \c pnp_basictools.dll and
+    \c pnp_extrafilters.dll plugin files.
+
+    \section2 Creating the Application Package
+
+    To deploy the application, we must make sure that we copy the
+    relevant Qt DLL (corresponding to the Qt modules used in
+    the application) as well as the executable to the same directory
+    in the \c release subdirectory.
+
+    Remember that if your application depends on compiler specific
+    libraries, these must be redistributed along with your
+    application. You can check which libraries your application is
+    linking against by using the \c depends tool. For more
+    information, see the \l {Application Dependencies} section.
+
+    We'll cover the plugins shortly, but first we'll check that the
+    application will work in a deployed environment: Either copy the
+    executable and the Qt DLLs to a machine that doesn't have Qt
+    or any Qt applications installed, or if you want to test on the
+    build machine, ensure that the machine doesn't have Qt in its
+    environment.
+
+    If the application starts without any problems, then we have
+    successfully made a dynamically linked version of the \l
+    {tools/plugandpaint}{Plug & Paint} application. But the
+    application's functionality will still be missing since we have
+    not yet deployed the associated plugins.
+
+    Plugins work differently to normal DLLs, so we can't just
+    copy them into the same directory as our application's executable
+    as we did with the Qt DLLs.  When looking for plugins, the
+    application searches in a \c plugins subdirectory inside the
+    directory of the application executable.
+
+    So to make the plugins available to our application, we have to
+    create the \c plugins subdirectory and copy over the relevant DLLs:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 18
+
+    An archive distributing all the Qt DLLs and application
+    specific plugins required to run the \l {tools/plugandpaint}{Plug
+    & Paint} application, would have to include the following files:
+
+    \table 100%
+    \header
+        \o Component \o {2, 1} File Name
+    \row
+        \o The executable
+        \o {2, 1} \c plugandpaint.exe
+    \row
+        \o The Basic Tools plugin
+        \o {2, 1} \c plugins\pnp_basictools.dll
+    \row
+        \o The ExtraFilters plugin
+        \o {2, 1} \c plugins\pnp_extrafilters.dll
+    \row
+        \o The Qt Core module
+        \o {2, 1} \c qtcore4.dll
+    \row
+        \o The Qt GUI module
+        \o {2, 1} \c qtgui4.dll
+    \endtable
+
+    In addition, the archive must contain the following compiler
+    specific libraries depending on your version of Visual Studio:
+
+    \table 100%
+    \header
+        \o \o VC++ 6.0 \o VC++ 7.1 (2003) \o VC++ 8.0 (2005) \o VC++ 9.0 (2008)
+    \row
+        \o The C run-time
+        \o \c msvcrt.dll
+        \o \c msvcr71.dll
+        \o \c msvcr80.dll
+        \o \c msvcr90.dll
+    \row
+        \o The C++ run-time
+        \o \c msvcp60.dll
+        \o \c msvcp71.dll
+        \o \c msvcp80.dll
+        \o \c msvcp90.dll
+    \endtable
+
+    To verify that the application now can be successfully deployed,
+    you can extract this archive on a machine without Qt and without
+    any compiler installed, and try to run it.
+
+    An alternative to putting the plugins in the plugins subdirectory
+    is to add a custom search path when you start your application
+    using QApplication::addLibraryPath() or
+    QApplication::setLibraryPaths().
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 19
+
+    One benefit of using plugins is that they can easily be made
+    available to a whole family of applications.
+
+    It's often most convenient to add the path in the application's \c
+    main() function, right after the QApplication object is
+    created. Once the path is added, the application will search it
+    for plugins, in addition to looking in the \c plugins subdirectory
+    in the application's own directory. Any number of additional paths
+    can be added.
+
+    \section2 Visual Studio 2005 Onwards
+
+    When deploying an application compiled with Visual Studio 2005 onwards,
+    there are some additional steps to be taken.
+
+    First, we need to copy the manifest file created when linking the
+    application. This manifest file contains information about the
+    application's dependencies on side-by-side assemblies, such as the runtime
+    libraries.
+
+    The manifest file needs to be copied into the \bold same folder as the
+    application executable. You do not need to copy the manifest files for
+    shared libraries (DLLs), since they are not used.
+
+    If the shared library has dependencies that are different from the
+    application using it, the manifest file needs to be embedded into the DLL
+    binary. Since Qt 4.1.3, the follwoing \c CONFIG options are available for
+    embedding manifests:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 20
+
+    To use the options, add
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 21
+
+    to your .pro file. The \c embed_manifest_dll option is enabled by default.
+
+    You can find more information about manifest files and side-by-side
+    assemblies at the
+    \l {http://msdn.microsoft.com/en-us/library/aa376307.aspx}{MSDN website}.
+
+    There are two ways to include the run time libraries: by bundling them
+    directly with your application or by installing them on the end-user's
+    system.
+
+    To bundle the run time libraries with your application, copy the directory
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 22
+
+    into the folder where your executable is, so that you are including a
+    \c Microsoft.VC80.CRT directory alongside your application's executable. If
+    you are bundling the runtimes and need to deploy plugins as well, you have
+    to remove the manifest from the plugins (embedded as a resource) by adding
+    the following line to the \c{.pro} file of the plugins you are compiling:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 23
+
+    \warning If you skip the step above, the plugins will not load on some
+    systems.
+
+    To install the runtime libraries on the end-user's system, you need to
+    include the appropriate Visual C++ Redistributable Package (VCRedist)
+    executable with your application and ensure that it is executed when the
+    user installs your application.
+
+    For example, on an 32-bit x86-based system, you would include the
+    \l{http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE}{vcredist_x86.exe}
+    executable. The \l{http://www.microsoft.com/downloads/details.aspx?familyid=526BF4A7-44E6-4A91-B328-A4594ADB70E5}{vcredist_IA64.exe}
+    and \l{http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B}{vcredist_x64.exe}
+    executables provide the appropriate libraries for the IA64 and 64-bit x86
+    architectures, respectively.
+
+    \note The application you ship must be compiled with exactly the same
+    compiler version against the same C runtime version. This prevents
+    deploying errors caused by different versions of the C runtime libraries.
+
+
+    \section1 Application Dependencies
+
+    \section2 Additional Libraries
+
+    Depending on configuration, compiler specific libraries must be
+    redistributed along with your application. You can check which
+    libraries your application is linking against by using the
+    \l{Dependency Walker} tool. All you need to do is to run it like
+    this:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 24
+
+    This will provide a list of the libraries that your application
+    depends on and other information.
+
+    \image deployment-windows-depends.png
+
+    When looking at the release build of the Plug & Paint executable
+    (\c plugandpaint.exe) with the \c depends tool, the tool lists the
+    following immediate dependencies to non-system libraries:
+
+    \table 100%
+        \header
+            \o Qt
+            \o VC++ 6.0
+            \o VC++ 7.1 (2003)
+            \o VC++ 8.0 (2005)
+            \o MinGW
+        \row
+        \o \list
+               \o QTCORE4.DLL - The QtCore runtime
+               \o QTGUI4.DLL - The QtGui runtime
+           \endlist
+        \o \list
+               \o MSVCRT.DLL - The C runtime
+               \o MSVCP60.DLL - The C++ runtime (only when STL is installed)
+           \endlist
+        \o \list
+               \o MSVCR71.DLL - The C runtime
+               \o MSVCP71.DLL - The C++ runtime (only when STL is installed)
+           \endlist
+        \o \list
+               \o MSVCR80.DLL - The C runtime
+               \o MSVCP80.DLL - The C++ runtime (only when STL is installed)
+           \endlist
+        \o \list
+               \o MINGWM10.DLL - The MinGW run-time
+           \endlist
+    \endtable
+
+    When looking at the plugin DLLs the exact same dependencies
+    are listed.
+
+    \section2 Qt Plugins
+
+    Your application may also depend on one or more Qt plugins, such
+    as the JPEG image format plugin or a SQL driver plugin. Be sure
+    to distribute any Qt plugins that you need with your application,
+    and note that each type of plugin should be located within a
+    specific subdirectory (such as \c imageformats or \c sqldrivers)
+    within your distribution directory, as described below.
+
+    \note If you are deploying an application that uses QtWebKit to display
+    HTML pages from the World Wide Web, you should include all text codec
+    plugins to support as many HTML encodings possible. 
+
+    The search path for Qt plugins is hard-coded into the QtCore library. 
+    By default, the plugins subdirectory of the Qt installation is the first 
+    plugin search path. However, pre-determined paths like the default one 
+    have certain disadvantages. For example, they may not exist on the target 
+    machine. For that reason, you need to examine various alternatives to make 
+    sure that the Qt plugins are found:
+
+    \list
+
+    \o \l{qt-conf.html}{Using \c qt.conf}. This approach is the recommended 
+    if you have executables in different places sharing the same plugins.
+
+    \o Using QApplication::addLibraryPath() or
+    QApplication::setLibraryPaths(). This approach is recommended if you only 
+    have one executable that will use the plugin. 
+
+    \o Using a third party installation utility to change the
+    hard-coded paths in the QtCore library.
+
+    \endlist
+
+    If you add a custom path using QApplication::addLibraryPath it could 
+    look like this:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 54
+
+    Then qApp->libraryPaths() would return something like this:
+
+    "C:/customPath/plugins " 
+    "C:/Qt/%VERSION%/plugins" 
+    "E:/myApplication/directory/"
+
+    The executable will look for the plugins in these directories and 
+    the same order as the QStringList returned by qApp->libraryPaths(). 
+    The newly added path is prepended to the qApp->libraryPaths() which 
+    means that it will be searched through first. However, if you use 
+    qApp->setLibraryPaths(), you will be able to determend which paths 
+    and in which order they will be searched.
+
+    The \l{How to Create Qt Plugins} document outlines the issues you
+    need to pay attention to when building and deploying plugins for
+    Qt applications.
+*/
+
+/*!
+    \page deployment-mac.html
+    \contentspage Deploying Qt Applications
+
+    \title Deploying an Application on Mac OS X
+
+    Starting with version 4.5, Qt now includes a \l {macdeploy}{deployment tool}
+    that automates the prodecures described in this document.
+
+    This documentation will describe how to create a bundle, and how
+    to make sure that the application will find the resources it needs
+    at run-time. We will demonstrate the procedures in terms of
+    deploying the \l {tools/plugandpaint}{Plug & Paint} application
+    that is provided in Qt's examples directory.
+    
+    \tableofcontents
+
+    \section1 The Bundle
+
+    On the Mac, a GUI application must be built and run from a
+    bundle. A bundle is a directory structure that appears as a single
+    entity when viewed in the Finder. A bundle for an application
+    typcially contains the executable and all the resources it
+    needs. See the image below:
+
+    \image deployment-mac-bundlestructure.png
+
+    The bundle provides many advantages to the user. One primary
+    advantage is that, since it is a single entity, it allows for
+    drag-and-drop installation. As a programmer you can access bundle
+    information in your own code. This is specific to Mac OS X and
+    beyond the scope of this document. More information about bundles
+    is available on \l
+    {http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/index.html}{Apple's Developer Website}.
+
+    A Qt command line application on Mac OS X works similar to a
+    command line application on Unix and Windows. You probably don't
+    want to run it in a bundle: Add this to your application's .pro:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 26
+
+    This will tell \c qmake not to put the executable inside a
+    bundle. Please refer to the \l{Deploying an Application on
+    X11 Platforms}{X11 deployment documentation} for information about how
+    to deploy these "bundle-less" applications.
+
+    \section1 Xcode
+
+    We will only concern ourselves with command-line tools here. While
+    it is possible to use Xcode for this, Xcode has changed enough
+    between each version that it makes it difficult to document it
+    perfectly for each version. A future version of this document may
+    include more information for using Xcode in the deployment
+    process.
+
+    \section1 Static Linking
+
+    If you want to keep things simple by only having a few files to
+    deploy, then you must build everything statically.
+
+    \section2 Building Qt Statically
+
+    Start by installing a static version of the Qt library. Remember
+    that you will not be able to use plugins and you must build in all
+    the image formats, SQL drivers, etc..
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 27
+
+    You can check the various options that are available by running \c
+    configure -help.
+
+    \section2 Linking the Application to the Static Version of Qt
+
+    Once Qt is built statically, the next step is to regenerate the
+    makefile and rebuild the application. First, we must go into the
+    directory that contains the application:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 28
+
+    Now run \c qmake to create a new makefile for the application, and do
+    a clean build to create the statically linked executable:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 29
+
+    You probably want to link against the release libraries, and you
+    can specify this when invoking \c qmake. If you have Xcode Tools
+    1.5 or higher installed, you may want to take advantage of "dead
+    code stripping" to reduce the size of your binary even more. You
+    can do this by passing \c {LIBS+= -dead_strip} to \c qmake in
+    addition to the \c {-config release} parameter. This doesn't have
+    as large an effect if you are using GCC 4, since Qt will then have
+    function visibility hints built-in, but if you use GCC 3.3, it
+    could make a difference.
+
+    Now, provided that everything compiled and linked without any
+    errors, we should have a \c plugandpaint.app bundle that is ready
+    for deployment. One easy way to check that the application really
+    can be run stand-alone is to copy the bundle to a machine that
+    doesn't have Qt or any Qt applications installed, and run the
+    application on that machine.
+
+    You can check what other libraries your application links to using
+    the \c otool:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 30
+
+    Here is what the output looks like for the static \l
+    {tools/plugandpaint}{Plug & Paint}:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 31
+
+    For more information, see the \l {Application Dependencies}
+    section.
+
+    If you see \e Qt libraries in the output, it probably
+    means that you have both dynamic and static Qt libraries installed
+    on your machine. The linker will always choose dynamic over
+    static. There are two solutions: Either move your Qt dynamic
+    libraries (\c .dylibs) away to another directory while you link
+    the application and then move them back, or edit the \c Makefile
+    and replace link lines for the Qt libraries with the absolute path
+    to the static libraries. For example, replace
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 32
+
+    with
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 33
+
+    The \l {tools/plugandpaint}{Plug & Paint} example consists of
+    several components: The core application (\l
+    {tools/plugandpaint}{Plug & Paint}), and the \l
+    {tools/plugandpaintplugins/basictools}{Basic Tools} and \l
+    {tools/plugandpaintplugins/extrafilters}{Extra Filters}
+    plugins. Since we cannot deploy plugins using the static linking
+    approach, the bundle we have prepared so far is incomplete. The
+    application will run, but the functionality will be disabled due
+    to the missing plugins. To deploy plugin-based applications we
+    should use the framework approach.
+
+    \section1 Frameworks
+
+    We have two challenges when deploying the \l
+    {tools/plugandpaint}{Plug & Paint} application using frameworks:
+    The Qt runtime has to be correctly redistributed along with the
+    application bundle, and the plugins have to be installed in the
+    correct location so that the application can find them.
+
+    When distributing Qt with your application using frameworks, you
+    have two options: You can either distribute Qt as a private
+    framework within your application bundle, or you can distribute Qt
+    as a standard framework (alternatively use the Qt frameworks in
+    the installed binary). These two approaches are essentially the
+    same. The latter option is good if you have many Qt applications
+    and you would prefer to save memory. The former is good if you
+    have Qt built in a special way, or want to make sure the framework
+    is there. It just comes down to where you place the Qt frameworks.
+
+    \section2 Building Qt as Frameworks
+
+    We assume that you already have installed Qt as frameworks, which
+    is the default when installing Qt, in the /path/to/Qt
+    directory. For more information on how to build Qt, see the \l
+    Installation documentation.
+
+    When installing, the identification name of the frameworks will
+    also be set. The identification name is what the dynamic linker
+    (\c dyld) uses to find the libraries for your application.
+
+    \section2 Linking the Application to Qt as Frameworks
+
+    After ensuring that Qt is built as frameworks, we can build the \l
+    {tools/plugandpaint}{Plug & Paint} application. First, we must go
+    into the directory that contains the application:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 34
+
+    Now run qmake to create a new makefile for the application, and do
+    a clean build to create the dynamically linked executable:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 35
+
+    This builds the core application, the following will build the
+    plugins:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 36
+
+    Now run the \c otool for the Qt frameworks, for example Qt Gui:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 37
+
+    You will get the following output:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 38
+
+    For the Qt frameworks, the first line (i.e. \c
+    {path/to/Qt/lib/QtGui.framework/Versions/4/QtGui (compatibility
+    version 4.0.0, current version 4.0.1)}) becomes the framework's
+    identification name which is used by the dynamic linker (\c dyld).
+
+    But when you are deploying the application, your users may not
+    have the Qt frameworks installed in the specified location. For
+    that reason, you must either provide the frameworks in an agreed
+    upon location, or store the frameworks in the bundle itself.
+    Regardless of which solution you choose, you must make sure that
+    the frameworks return the proper identification name for
+    themselves, and that the application will look for these
+    names. Luckily we can control this with the \c install_name_tool
+    command-line tool.
+
+    The \c install_name_tool works in two modes, \c -id and \c
+    -change. The \c -id mode is for libraries and frameworks, and
+    allows us to specify a new identification name. We use the \c
+    -change mode to change the paths in the application.
+
+    Let's test this out by copying the Qt frameworks into the Plug &
+    Paint bundle. Looking at \c otool's output for the bundle, we can
+    see that we must copy both the QtCore and QtGui frameworks into
+    the bundle. We will assume that we are in the directory where we
+    built the bundle.
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 39
+
+    First we create a \c Frameworks directory inside the bundle. This
+    follows the Mac OS X application convention. We then copy the
+    frameworks into the new directory. Since frameworks contain
+    symbolic links, and we want to preserve them, we use the \c -R
+    option.
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 40
+
+    Then we run \c install_name_tool to set the identification names
+    for the frameworks. The first argument after \c -id is the new
+    name, and the second argument is the framework which
+    identification we wish to change.  The text \c @executable_path is
+    a special \c dyld variable telling \c dyld to start looking where
+    the executable is located. The new names specifies that these
+    frameworks will be located "one directory up and over" in the \c
+    Frameworks directory.
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 41
+
+    Now, the dynamic linker knows where to look for QtCore and
+    QtGui. Then we must make the application aware of the library
+    locations as well using \c install_name_tool's \c -change mode.
+    This basically comes down to string replacement, to match the
+    identification names that we set for the frameworks.
+
+    Finally, since the QtGui framework depends on QtCore, we must
+    remember to change the reference for QtGui:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 42
+
+    After all this we can run \c otool again and see that the
+    application will look in the right locations.
+
+    Of course, the thing that makes the \l {tools/plugandpaint}{Plug &
+    Paint} example interesting are its plugins. The basic steps we
+    need to follow with plugins are:
+
+    \list
+        \o Put the plugins inside the bundle
+        \o Make sure that the plugins use the correct library using the
+           \c install_name_tool
+        \o Make sure that the application knows where to get the plugins
+    \endlist
+
+    While we can put the plugins anywhere we want in the bundle, the
+    best location to put them is under Contents/Plugins. When we built
+    the Plug & Paint plugins, the \c DESTDIR variable in their \c .pro
+    file put the plugins' \c .dylib files in a \c plugins subdirectory
+    in the \c plugandpaint directory. So, in this example, all we need
+    to do is move this directory:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 43
+
+    If we run \c otool on for example the \l
+    {tools/plugandpaintplugins/basictools}{Basic Tools} plugin's \c
+    .dylib file we get the following information.
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 44
+
+    Then we can see that the plugin links to the Qt frameworks it was
+    built against. Since we want the plugins to use the framework in
+    the application bundle we change them the same way as we did for
+    the application. For example for the Basic Tools plugin:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 45
+
+
+    We must also modify the code in \c
+    tools/plugandpaint/mainwindow.cpp to \l {QDir::cdUp()}{cdUp()} one
+    directory since the plugins live in the bundle. Add the following
+    code to the \c mainwindow.cpp file:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 46
+
+    \table
+    \row
+    \o \inlineimage deployment-mac-application.png
+    \o
+    The additional code in \c tools/plugandpaint/mainwindow.cpp also
+    enables us to view the plugins in the Finder, as shown to the left.
+
+    We can also add plugins extending Qt, for example adding SQL
+    drivers or image formats. We just need to follow the directory
+    structure outlined in plugin documentation, and make sure they are
+    included in the QCoreApplication::libraryPaths(). Let's quickly do
+    this with the image formats, following the approach from above.
+
+    Copy Qt's image format plugins into the bundle:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 47
+
+    Use \c install_name_tool to link the plugins to the frameworks in
+    the bundle:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 48
+
+    Then we update the source code in \c tools/plugandpaint/main.cpp
+    to look for the new plugins. After constructing the
+    QApplication, we add the following code:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 49
+
+    First, we tell the application to only look for plugins in this
+    directory. In our case, this is what we want since we only want to
+    look for the plugins that we distribute with the bundle. If we
+    were part of a bigger Qt installation we could have used
+    QCoreApplication::addLibraryPath() instead.
+
+    \endtable
+
+    \warning When deploying plugins, and thus make changes to the
+    source code, the default identification names are reset when
+    rebuilding the application, and you must repeat the process of
+    making your application link to the Qt frameworks in the bundle
+    using \c install_name_tool.
+
+    Now you should be able to move the application to another Mac OS X
+    machine and run it without Qt installed. Alternatively, you can
+    move your frameworks that live outside of the bundle to another
+    directory and see if the application still runs.
+
+    If you store the frameworks in another location than in the
+    bundle, the technique of linking your application is similar; you
+    must make sure that the application and the frameworks agree where
+    to be looking for the Qt libraries as well as the plugins.
+
+    \section2 Creating the Application Package
+
+    When you are done linking your application to Qt, either
+    statically or as frameworks, the application is ready to be
+    distributed. Apple provides a fair bit of information about how to
+    do this and instead of repeating it here, we recommend that you
+    consult their \l
+    {http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/index.html}{software delivery}
+    documentation.
+
+    Although the process of deploying an application do have some
+    pitfalls, once you know the various issues you can easily create
+    packages that all your Mac OS X users will enjoy.
+
+    \section1 Application Dependencies
+
+    \section2 Qt Plugins
+
+    Your application may also depend on one or more Qt plugins, such
+    as the JPEG image format plugin or a SQL driver plugin. Be sure
+    to distribute any Qt plugins that you need with your application,
+    and note that each type of plugin should be located within a
+    specific subdirectory (such as \c imageformats or \c sqldrivers)
+    within your distribution directory, as described below.
+
+    \note If you are deploying an application that uses QtWebKit to display
+    HTML pages from the World Wide Web, you should include all text codec
+    plugins to support as many HTML encodings possible. 
+
+    The search path for Qt plugins (as well as a few other paths) is
+    hard-coded into the QtCore library. By default, the first plugin
+    search path will be hard-coded as \c /path/to/Qt/plugins. But
+    using pre-determined paths has certain disadvantages. For example,
+    they may not exist on the target machine. For that reason you need
+    to examine various alternatives to make sure that the Qt plugins
+    are found:
+
+    \list
+
+    \o \l{qt-conf.html}{Using \c qt.conf}. This is the recommended
+    approach since it provides the most flexibility.
+
+    \o Using QApplication::addLibraryPath() or
+    QApplication::setLibraryPaths().
+
+    \o Using a third party installation utility to change the
+    hard-coded paths in the QtCore library.
+
+    \endlist
+
+    The \l{How to Create Qt Plugins} document outlines the issues you
+    need to pay attention to when building and deploying plugins for
+    Qt applications.
+
+    \section2 Additional Libraries
+
+    You can check which libraries your application is linking against
+    by using the \c otool tool. To use \c otool, all you need to do is
+    to run it like this:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 50
+
+    Unlike the deployment processes on \l {Deploying an Application on
+    X11 Platforms}{X11} and \l {Deploying an Application on
+    Windows}{Windows}, compiler specific libraries rarely have to
+    be redistributed along with your application. But since Qt can be
+    configured, built, and installed in several ways on Mac OS X,
+    there are also several ways to deploy applications. Typically your
+    goals help determine how you are going to deploy the
+    application. The last sections describe a couple of things to keep
+    in mind when you are deploying your application.
+
+    \section2 Mac OS X Version Dependencies
+
+    Qt 4.2 has been designed to be built and deployed on Mac OS X 10.3
+    up until the current version as of this writing, Mac OS X 10.4 and
+    all their minor releases. Qt achieves this by using "weak
+    linking." This means that Qt tests if a function added in newer
+    versions of Mac OS X is available on the computer it is running on
+    before it uses it. This results in getting access to newer
+    features when running on newer versions of OS X while still
+    remaining compatible on older versions.
+
+    For more information about cross development issues on Mac OS X,
+    see \l
+    {http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html}{Apple's Developer Website}.
+
+    Since the linker is set to be compatible with all OS X version, you have to
+    change the \c MACOSX_DEPLOYMENT_TARGET environment variable to get weak
+    linking to work for your application. You can add:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 51
+
+    to your .pro file and qmake will take care of this for you.
+
+    However, there is a bit of a wrinkle to keep in mind when your are
+    deploying. Mac OS X 10.4 ("Tiger") ships GCC 4.0 as its default
+    compiler. This is also the GCC compiler we use for building the
+    binary Qt package. If you use GCC 4.0 to build your application,
+    it will link against a dynamic libstdc++ that is only available on
+    Mac OS X 10.4 and Mac OS X 10.3.9.  The application will refuse to
+    run on older versions of the operating system.
+
+    For more information about C++ runtime environment, see \l
+    {http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/index.html}{Apple's Developer Website}
+
+    If you want to deploy to versions of Mac OS X earlier than 10.3.9,
+    you must build with GCC 3.3 which is the default on Mac OS X
+    10.3. GCC 3.3 is also available on the Mac OS X 10.4 "Xcode Tools"
+    CD and as a download for earlier versions of Mac OS X from Apple
+    (\l {https://connect.apple.com/}{connect.apple.com}). You can use
+    Apple's \c gcc_select(1) command line tool to switch the default
+    complier on your system.
+
+    \section3 Deploying Phonon Applications on Mac OS X
+
+    \list
+        \o If you build your Phonon application on Tiger, it will work on
+           Tiger, Leopard and Panther.
+        \o If you build your application on Leopard, it will \bold not work
+        on Panther unless you rename the libraries with the following command
+        after you have built your application:
+
+        \snippet doc/src/snippets/code/doc_src_deployment.qdoc 51a
+
+        This command must be invoked in the directory where
+        \c{libphonon_qt7.dylib} is located, usually in 
+        \c{yourapp.app/Contents/plugins/phonon_backend/}.
+        \o The \l {macdeploy}{deployment tool} will perform this step for you.
+
+        \o If you are using Leopard, but would like to build your application
+        against Tiger, you can use:
+
+        \snippet doc/src/snippets/code/doc_src_deployment.qdoc 51b
+    \endlist
+
+    \section2 Architecture Dependencies
+
+    The Qt for Mac OS X libraries, tools, and examples can be built "universal"
+    (i.e. they run natively on both Intel and PowerPC machines).  This
+    is accomplished by passing \c -universal on the \c configure line
+    of the source package, and requires that you use GCC 4.0.x. On
+    PowerPC hardware you will need to pass the universal SDK as a
+    command line argument to the Qt configure command. For example:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 52
+
+    From 4.1.1 the Qt binary package is already universal.
+
+    If you want to create a binary that runs on older versions of
+    PowerPC and x86, it is possible to build Qt for the PowerPC using
+    GCC 3.3, and for x86 one using GCC 4.0, and use Apple's \c lipo(1)
+    tool to stitch them together. This is beyond the scope of this
+    document and is not something we have tried, but Apple documents
+    it on their \l
+    {http://developer.apple.com/documentation/}{developer website}.
+
+    Once you have a universal Qt, \a qmake will generate makefiles
+    that will build for its host architecture by default. If you want
+    to build for a specific architecture, you can control this with
+    the \c CONFIG line in your \c .pro file. Use \c CONFIG+=ppc for
+    PowerPC, and \c CONFIG+=x86 for x86. If you desire both, simply
+    add both to the \c CONFIG line. PowerPC users also need an
+    SDK. For example:
+
+    \snippet doc/src/snippets/code/doc_src_deployment.qdoc 53
+
+    Besides \c lipo, you can also check your binaries with the \c file(1)
+    command line tool or the Finder.
+    
+    \section1 The Mac Deployment Tool
+    \target macdeploy
+    The Mac deployment tool can be found in QTDIR/bin/macdeployqt. It is
+    designed to automate the process of creating a deployable
+    application bundle that contains the Qt libraries as private
+    frameworks.
+    
+    The mac deployment tool also deploys the Qt plugins, according
+    to the following rules:
+    \list
+    \o Debug versions of the plugins are not deployed.
+    \o The designer plugins are not deployed.
+    \o The Image format plugins are always deployed.
+    \o SQL driver plugins are deployed if the application uses the QtSql module.
+    \o Script plugins are deployed if the application uses the QtScript module.
+    \o The Phonon backend plugin is deployed if the application uses the \l{Phonon Module} {Phonon} module.
+    \o The svg icon plugin is deployed if the application uses the QtSvg module.
+    \o The accessibility plugin is always deployed.
+    \o Accessibility for Qt3Support is deployed if the application uses the Qt3Support module.
+    \endlist
+
+    macdeployqt supports the following options:
+    \list
+    \o -no-plugins: Skip plugin deployment 
+    \o -dmg       : Create a .dmg disk image 
+    \o -no-strip  : Don't run 'strip' on the binaries 
+    \endlist    
+*/
diff --git a/doc/src/deployment/qt-conf.qdoc b/doc/src/deployment/qt-conf.qdoc
new file mode 100644
index 0000000000..229fa4553a
--- /dev/null
+++ b/doc/src/deployment/qt-conf.qdoc
@@ -0,0 +1,135 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at http://qt.nokia.com/contact.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+    \page qt-conf.html
+
+    \title Using qt.conf
+
+    The \c qt.conf file overrides the hard-coded paths that are
+    compiled into the Qt library. These paths are accessible using the
+    QLibraryInfo class. Without \c qt.conf, the functions in
+    QLibraryInfo return these hard-coded paths; otherwise they return
+    the paths as specified in \c qt.conf.
+
+    Without \c qt.conf, the Qt libraries will use the hard-coded paths
+    to look for plugins, translations, and so on. These paths may not
+    exist on the target system, or they may not be
+    accesssible. Because of this, you need \c qt.conf to make the Qt
+    libraries look elsewhere.
+
+    QLibraryInfo will load \c qt.conf from one of the following locations:
+
+    \list 1
+
+    \o \c :/qt/etc/qt.conf using the resource system
+
+    \o on Mac OS X, in the Resource directory inside the appliction
+    bundle, for example \c assistant.app/Contents/Resources/qt.conf
+
+    \o in the directory containing the application executable, i.e.
+    QCoreApplication::applicationDirPath() + QDir::separator() + "qt.conf"
+
+    \endlist
+
+    The \c qt.conf file is an INI text file, as described in the \l
+    {QSettings::Format}{QSettings} documentation. The file should have
+    a \c Paths group which contains the entries that correspond to
+    each value of the QLibraryInfo::LibraryLocation enum. See the
+    QLibraryInfo documentation for details on the meaning of the
+    various locations.
+
+    \table
+
+    \header \o Entry            \o Default Value
+
+    \row \o Prefix              \o QCoreApplication::applicationDirPath()
+    \row \o Documentation       \o \c doc
+    \row \o Headers             \o \c include
+    \row \o Libraries           \o \c lib
+    \row \o Binaries            \o \c bin
+    \row \o Plugins             \o \c plugins
+    \row \o Data                \o \c .
+    \row \o Translations        \o \c translations
+    \row \o Settings            \o \c .
+    \row \o Examples            \o \c .
+    \row \o Demos               \o \c .
+
+    \endtable
+
+    Absolute paths are used as specified in the \c qt.conf file. All
+    paths are relative to the \c Prefix. On Windows and X11, the \c
+    Prefix is relative to the directory containing the application
+    executable (QCoreApplication::applicationDirPath()). On Mac OS X,
+    the \c Prefix is relative to the \c Contents in the application
+    bundle. For example, \c application.app/Contents/plugins/ is the
+    default location for loading Qt plugins. Note that the plugins
+    need to be placed in specific sub-directories under the
+    \c{plugins} directory (see \l{How to Create Qt Plugins} for
+    details).
+
+    For example, a \c qt.conf file could contain the following:
+
+    \snippet doc/src/snippets/code/doc_src_qt-conf.qdoc 0
+
+    Subgroups of the \c Paths group may be used to specify locations
+    for specific versions of the Qt libraries. Such subgroups are of
+    the form \c Paths/x.y.z, where x is the major version of the Qt
+    libraries, y the minor, and z the patch level. The subgroup that
+    most closely matches the current Qt version is used. If no
+    subgroup matches, the \c Paths group is used as the fallback. The
+    minor and patch level values may be omitted, in which case they
+    default to zero.
+
+    For example, given the following groups:
+
+    \snippet doc/src/snippets/code/doc_src_qt-conf.qdoc 1
+
+    The current version will be matched as shown:
+
+    \list
+    \o 4.0.1 matches \c Paths/4
+    \o 4.1.5 matches \c Paths/4.1
+    \o 4.6.3 matches \c Paths/4.2.5
+    \o 5.0.0 matches \c Paths
+    \o 6.0.2 matches \c Paths/6
+    \endlist
+*/
diff --git a/doc/src/deployment/qtconfig.qdoc b/doc/src/deployment/qtconfig.qdoc
new file mode 100644
index 0000000000..2e02fe6040
--- /dev/null
+++ b/doc/src/deployment/qtconfig.qdoc
@@ -0,0 +1,56 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at http://qt.nokia.com/contact.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+    \page qtconfig.html
+    \title Configuring Qt
+    \ingroup qttools
+    \keyword qtconfig
+
+    The \c qtconfig tool allows users to customize the default settings for
+    Qt applications on a per-user basis, enabling features such as the widget
+    style to be changed without requiring applications to be recompiled.
+
+    \c qtconfig is available on X11 platforms and should be installed alongside
+    the \l{Qt's Tools}{other tools} supplied with Qt.
+
+    \image qtconfig-appearance.png
+*/