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.
author: Volker Hilsheimer <volker.hilsheimer@nokia.com> 2009-08-17 18:37:42 +0200
committer: Volker Hilsheimer <volker.hilsheimer@nokia.com> 2009-08-17 18:37:42 +0200
commit: 911557fcf7dedc002e689a0d66efd2b77e044bd1 (patch)
tree: a66138f008c27f39e5306dc6f2df01c129e11988 /doc/src/development
parent: 285d4b12cb937a5672d6eb15781f03d249f8cfc1 (diff)
16 files changed, 10483 insertions, 0 deletions
diff --git a/doc/src/development/activeqt-dumpcpp.qdoc b/doc/src/development/activeqt-dumpcpp.qdoc
new file mode 100644
index 0000000000..8c743a11c9
--- /dev/null
+++ b/doc/src/development/activeqt-dumpcpp.qdoc
@@ -0,0 +1,143 @@
+/****************************************************************************
+**
+** 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 activeqt-dumpcpp.html
+    \title The dumpcpp Tool (ActiveQt)
+
+    \ingroup activeqt-tools
+
+    \keyword dumpcpp
+
+    The \c dumpcpp tool generates a C++ namespace for a type library.
+
+    To generate a C++ namespace for a type library, call \c dumpcpp with the following 
+    command line parameters:
+
+    \table
+    \header
+    \i Option
+    \i Result
+    \row
+    \i input
+    \i Generate documentation for \e input. \e input can specify a type library file or a type 
+    library ID, or a CLSID or ProgID for an object
+    \row
+    \i -o file
+    \i Writes the class declaration to \e {file}.h and meta object infomation to \e {file}.cpp
+    \row
+    \i -n namespace
+    \i Generate a C++ namespace \e namespace
+    \row
+    \i -nometaobject
+    \i Do not generate a .cpp file with the meta object information. 
+    The meta object is then generated in runtime.
+    \row
+    \i -getfile libid
+    \i Print the filename for the typelibrary \e libid to stdout
+    \row
+    \i -compat
+    \i Generate namespace with dynamicCall-compatible API
+    \row
+    \i -v
+    \i Print version information
+    \row
+    \i -h
+    \i Print help
+    \endtable
+
+    \c dumpcpp can be integrated into the \c qmake build system. In your .pro file, list the type 
+    libraries you want to use in the TYPELIBS variable:
+
+    \snippet examples/activeqt/qutlook/qutlook.pro 0
+
+    The generated namespace will declare all enumerations, as well as one QAxObject subclass 
+    for each \c coclass and \c interface declared in the type library. coclasses marked with 
+    the \c control attribute will be wrapped by a QAxWidget subclass.
+
+    Those classes that wrap creatable coclasses  (i.e. coclasses that are not marked 
+    as \c noncreatable) have a default constructor; this is typically a single class 
+    of type \c Application. 
+
+    \snippet doc/src/snippets/code/doc_src_activeqt-dumpcpp.qdoc 0
+
+    All other classes can only be created by passing an IDispatch interface pointer 
+    to the constructor; those classes should however not be created explicitly. 
+    Instead, use the appropriate API of already created objects.
+
+    \snippet doc/src/snippets/code/doc_src_activeqt-dumpcpp.qdoc 1
+
+    All coclass wrappers also have one constructors taking an interface wrapper class
+    for each interface implemented.
+
+    \snippet doc/src/snippets/code/doc_src_activeqt-dumpcpp.qdoc 2
+
+    You have to create coclasses to be able to connect to signals of the subobject.
+    Note that the constructor deletes the interface object, so the following will
+    cause a segmentation fault:
+
+    \snippet doc/src/snippets/code/doc_src_activeqt-dumpcpp.qdoc 3
+
+    If the return type is of a coclass or interface type declared in another type 
+    library you have to include the namespace header for that other type library 
+    before including the header for the namespace you want to use (both header have 
+    to be generated with this tool).
+
+    By default, methods and property returning subobjects will use the type as in 
+    the type library. The caller of the function is responsible for deleting or 
+    reparenting the object returned. If the \c -compat switch is set, properties 
+    and method returning a COM object have the return type \c IDispatch*, and 
+    the namespace will not declare wrapper classes for interfaces. 
+
+    In this case, create the correct wrapper class explicitly:
+
+    \snippet doc/src/snippets/code/doc_src_activeqt-dumpcpp.qdoc 4
+
+    You can of course use the IDispatch* returned directly, in which case you have to 
+    call \c Release() when finished with the interface.
+
+    All classes in the namespace are tagged with a macro that allows you to export
+    or import them from a DLL. To do that, declare the macro to expand to 
+    \c __declspec(dllimport/export) before including the header file.
+
+    To build the tool you must first build the QAxContainer library.
+    Then run your make tool in \c tools/dumpcpp.
+*/
diff --git a/doc/src/development/activeqt-dumpdoc.qdoc b/doc/src/development/activeqt-dumpdoc.qdoc
new file mode 100644
index 0000000000..55ab2d7844
--- /dev/null
+++ b/doc/src/development/activeqt-dumpdoc.qdoc
@@ -0,0 +1,83 @@
+/****************************************************************************
+**
+** 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 activeqt-dumpdoc.html
+    \title The dumpdoc Tool (ActiveQt)
+
+    \ingroup activeqt-tools
+
+    \keyword dumpdoc
+
+    The \c dumpdoc tool generates Qt-style documentation for any
+    COM object and writes it into the file specified.
+
+    Call \c dumpdoc with the following command line parameters:
+
+    \table
+    \header
+    \i Option
+    \i Result
+    \row
+    \i -o file
+    \i Writes output to \e file
+    \row
+    \i object
+    \i Generate documentation for \e object
+    \row
+    \i -v
+    \i Print version information
+    \row
+    \i -h
+    \i Print help
+    \endtable
+
+    \e object must be an object installed on the local machine (ie.
+    remote objects are not supported), and can include subobjects
+    accessible through properties, ie.
+    \c Outlook.Application/Session/CurrentUser
+
+    The generated file will be an HTML file using Qt documentation
+    style.
+
+    To build the tool you must first build the QAxContainer library.
+    Then run your make tool in \c tools/dumpdoc.
+*/
diff --git a/doc/src/development/activeqt-idc.qdoc b/doc/src/development/activeqt-idc.qdoc
new file mode 100644
index 0000000000..974eddcd53
--- /dev/null
+++ b/doc/src/development/activeqt-idc.qdoc
@@ -0,0 +1,82 @@
+/****************************************************************************
+**
+** 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 activeqt-idc.html
+    \title IDC - The Interface Description Compiler (ActiveQt)
+
+    \ingroup activeqt-tools
+
+    \keyword idc
+
+    The IDC tool is part of the ActiveQt build system and makes
+    it possible to turn any Qt binary into a full COM object server 
+    with only a few lines of code.
+
+    IDC understands the following command line parameters:
+
+    \table
+    \header
+    \i Option
+    \i Result
+    \row
+    \i dll -idl idl -version x.y
+    \i Writes the IDL of the server \e dll to the file \e idl. The
+       type library wll have version x.y.
+    \row
+    \i dll -tlb tlb
+    \i Replaces the type library in \e dll with \e tlb
+    \row
+    \i -v
+    \i Print version information
+    \row
+    \i -regserver dll
+    \i Register the COM server \e dll
+    \row
+    \i -unregserver
+    \i Unregister the COM server \e dll
+    \endtable
+
+    It is usually never necessary to invoke IDC manually, as the \c
+    qmake build system takes care of adding the required post 
+    processing steps to the build process. See the  \l{ActiveQt}
+    documentation for details.
+*/
diff --git a/doc/src/development/activeqt-testcon.qdoc b/doc/src/development/activeqt-testcon.qdoc
new file mode 100644
index 0000000000..9fcfed6665
--- /dev/null
+++ b/doc/src/development/activeqt-testcon.qdoc
@@ -0,0 +1,77 @@
+/****************************************************************************
+**
+** 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 activeqt-testcon.html
+    \title testcon - An ActiveX Test Container (ActiveQt)
+
+    \ingroup activeqt-tools
+
+    \keyword testcon
+
+    This application implements a generic test container for ActiveX
+    controls. You can insert ActiveX controls installed on your
+    system, and execute methods and modify properties. The container
+    will log information about events and property changes as well
+    as debug output in the log window.
+
+    Parts of the code use internals of the Qt meta object and ActiveQt 
+    framework and are not recommended to be used in application code.
+
+    Use the application to view the slots, signals and porperties 
+    available through the QAxWidget class when instantiated with a 
+    certain ActiveX, and to test ActiveX controls you implement or
+    want to use in your Qt application.
+
+    The application can load and execute script files in JavaScript, 
+    VBScript, Perl and Python (if installed) to automate the controls 
+    loaded. Example script files using the QAxWidget2 class are available 
+    in the \c scripts subdirectory.
+
+    Note that the qmake project of this example includes a resource file
+    \c testcon.rc with a version resource. This is required by some
+    ActiveX controls (ie. Shockwave ActiveX Controls), which might crash
+    or misbehave otherwise if such version information is missing.
+
+    To build the tool you must first build the QAxContainer and the
+    QAxServer libraries. Then run your make  tool in \c tools/testcon
+    and run the resulting \c testcon.exe.
+*/
diff --git a/doc/src/development/assistant-manual.qdoc b/doc/src/development/assistant-manual.qdoc
new file mode 100644
index 0000000000..b26efccdd5
--- /dev/null
+++ b/doc/src/development/assistant-manual.qdoc
@@ -0,0 +1,810 @@
+/****************************************************************************
+**
+** 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 assistant-manual.html
+    \title Qt Assistant Manual
+    \ingroup qttools
+
+    \startpage {index.html}{Qt Reference Documentation}
+    \nextpage Qt Assistant in More Detail
+
+    \keyword Qt Assistant
+
+    This document introduces \QA, a tool for presenting on-line
+    documentation. The document is divided into the following sections:
+
+    Table of contents:
+
+    \list
+    \o \l{The One-Minute Guide to Using Qt Assistant}
+    \o \l{Qt Assistant in More Detail}
+    \o \l{Using Qt Assistant as a Custom Help Viewer}
+    \endlist
+
+    \chapter The One-Minute Guide to Using Qt Assistant
+
+    Once you have installed Qt, \QA should be ready to run:
+
+    \list
+    \o On Windows, \QA is available as a menu option on the Qt menu.
+    \o On Mac OS X, \QA is installed in the /Developer/Applications/Qt directory.
+    \o On Unix/Linux, open a terminal, type \c{assistant} and press \key{Enter}.
+    \endlist
+
+    When you start up \QA, you will be presented with a standard main window
+    application, with a menu bar and toolbar. Below these, on the left hand
+    side are navigation windows called \e{Contents}, \e{Index} and \e{Bookmarks}.
+    On the right, taking up most of the space, is the \e{Documentation} window.
+    By default, \QA loads the Qt reference documentation along with the manuals
+    of other Qt tools, like \QD or \QL.
+
+    \QA works in a similar way to a Web browser. If you click hyperlinks
+    (cross-references), the \e{Documentation} window will present the relevant
+    page. You can bookmark pages of particular interest and you can click the
+    \gui{Previous} and \gui{Next} toolbar buttons to navigate within the pages
+    you have visited.
+
+    Although \QA can be used just like a Web browser to navigate through
+    the documentation, \QA offers a powerful means of navigation that Web
+    browsers do not provide. \QA uses an advanced full text search engine
+    to index all the pages in each compressed help file so that you can
+    search for particular words and phrases.
+
+    To perform an index search, click the \gui{Index} tab on the Sidebar
+    (or press \key{Alt+I}). In the \gui{'Look For'} line edit enter a word;
+    e.g., 'homedirpath'. As you type, words are found and highlighted in a list
+    beneath the line edit. If the highlighted text matches what you're
+    looking for, double click it, (or press \key{Enter}) and the
+    \e{Documentation} window will display the relevant page. You rarely have
+    to type in the whole word before \QA finds a match. Note that for some
+    words there may be more than one possible page that is relevant.
+
+    \QA also provides full text searching for finding specific words in
+    the documentation. To activate the full text search, either press \key(Alt+S)
+    or click on the \gui{Search} tab in the \e{Documentation} window. Then
+    enter the term you're looking for and hit the \gui{Search} button. All
+    documents containing the specified term will then be listed in the list box
+    below.
+*/
+
+/*!
+    \page assistant-details.html
+    \title Qt Assistant in More Detail
+
+    \contentspage {Qt Assistant Manual}{Contents}
+    \previouspage Qt Assistant Manual
+    \nextpage Using Qt Assistant as a Custom Help Viewer
+
+    \tableofcontents
+
+    \img assistant-assistant.png
+
+    \section1 Command Line Options
+
+    \QA handles the following command line options:
+
+    \table
+        \header
+            \o Command Line Option
+            \o Brief Description
+        \row
+            \o -collectionFile <file.qhc>
+            \o Uses the specified collection file instead of the default one.
+        \row
+            \o -showUrl URL
+            \o Shows the document referenced by URL.
+        \row
+            \o -enableRemoteControl
+            \o Enables \QA to be remotly controlled.
+        \row
+            \o -show <widget>
+            \o Shows the specified dockwidget which can be "contents", "index",
+            "bookmarks" or "search".
+        \row
+            \o -hide <widget>
+            \o Hides the specified dockwidget which can be "contents", "index",
+            "bookmarks" or "search.
+        \row
+            \o -activate <widget>
+            \o Activates the specified dockwidget which can be "contents",
+            "index", "bookmarks" or "search.
+        \row
+            \o -register <doc.qch>
+            \o Registers the specified compressed help file in the given help
+            collection.
+        \row
+            \o -unregister <doc.qch>
+            \o Unregisters the specified compressed help file from the given
+            collection file.
+        \row
+            \o -setCurrentFilter filter
+            \o Sets the given filter as the active filter.
+        \row
+            \o -quiet
+            \o Doesn't show any error, warning or success messages.
+    \endtable
+
+    \section1 Tool Windows
+
+    \img assistant-dockwidgets.png
+
+    The tool windows provide four ways to navigate the documentation:
+
+    \list
+    \o The \gui{Contents} window presents a table of contents implemented as a
+    tree view for the documentation that is available. If you click an item,
+    its documentation will appear in the \e{Documentation} window. If you double
+    click an item or click on the control to the left of it, the item's sub-items
+    will appear. Click a sub-item to make its page appear in the \e{Documentation}
+    window. Click on the control next to an open item to hide its sub-items.
+    \o The \gui{Index} window is used to look up key words or phrases.
+    See \l{The One-Minute Guide to Using Qt Assistant} for how to use this
+    window.
+    \o The \gui{Bookmarks} window lists any bookmarks you have made. Double
+    click a bookmark to make its page appear in the \e{Documentation} window.
+    The \gui{Bookmarks} window provides a context menu with \gui{Show Item},
+    \gui{Delete Item} as well as \gui{Rename Item}. Click in the main menu
+    \menu{Bookmark|Add Bookmark...} (or press \key{Ctrl+B}) to bookmark the
+    page that is currently showing in the \e{Documentation} window. Right click
+    a bookmark in the list to rename or delete the highlighted bookmark.
+    \endlist
+
+    If you want the \gui{Documentation} window to use as much space as possible,
+    you can easily group, move or hide the tool windows. To group the windows,
+    drag one on top of the other and release the mouse. If one or all tool
+    windows are not shown, press \key{Alt+C}, \key{Alt+I} or \key{Alt+O} to show
+    the required window.
+
+    The tool windows can be docked into the main window, so you can drag them
+    to the top, left, right or bottom of \e{Qt Assistant's} window, or you can
+    drag them outside \QA to float them as independent windows.
+
+    \section1 Documentation Window
+
+    \img assistant-docwindow.png
+
+    The \gui{Documentation} window lets you create a tab for each
+    documentation page that you view. Click the \gui{Add Tab} button and a new
+    tab will appear with the page name as the tab's caption. This makes it
+    convenient to switch between pages when you are working with different
+    documentation. You can delete a tab by clicking the \gui{Close Tab} button
+    located on the right side of the \gui{Documentation} window.
+
+    \section1 Toolbars
+
+    \img assistant-toolbar.png
+
+    The main toolbar provides fast access to the most common actions.
+
+    \table
+    \header \o Action \o Description \o Menu Item \o Shortcut
+    \row \o \gui{Previous} \o Takes you to the previous page in the history.
+         \o \menu{Go|Previous} \o \key{Alt+Left Arrow}
+    \row \o \gui{Next} \o Takes you to the next page in the history.
+         \o \menu{Go|Next} \o \key{Alt+Right Arrow}
+    \row \o \gui{Home}
+         \o Takes you to the home page as specified in the Preferences Dialog.
+         \o \menu{Go|Home} \o \key{Ctrl+Home}.
+    \row \o \gui{Sync with Table of Contents}
+         \o Synchronizes the \gui{Contents} tool window with the page currently
+            shown in the \gui{Documentation} window.
+         \o \menu{Go|Sync with Table of Contents} \o
+    \row \o \gui{Copy} \o Copies any selected text to the clipboard.
+         \o \menu{Edit|Copy} \o \key{Ctrl+C}
+    \row \o \gui{Print} \o Opens the \gui{Print} dialog.
+         \o \menu{File|Print} \o \key{Ctrl+P}
+    \row \o \gui{Find in Text} \o Opens the \gui{Find Text} dialog.
+         \o \menu{Edit|Find in Text} \o \key{Ctrl+F}
+    \row \o \gui{Zoom in}
+         \o Increases the font size used to display text in the current tab.
+         \o \menu{View|Zoom in} \o \key{Ctrl++}
+    \row \o \gui{Zoom out}
+         \o Decreases the font size used to display text in the current tab.
+         \o \menu{View|Zoom out} \o \key{Ctrl+-}
+    \row \o \gui{Normal Size}
+         \o Resets the font size to its normal size in the current tab.
+         \o \menu{View|Normal Size} \o \key{Ctrl+0}
+    \endtable
+
+    \img assistant-address-toolbar.png
+
+    The address toolbar provides a fast way to enter a specific URL for a
+    documentation file. By default, the address toolbar is not shown, so it
+    has to be activated via \menu{View|Toolbars|Address Toolbar}.
+
+    \img assistant-filter-toolbar.png
+
+    The filter toolbar allows you to apply a filter to the currently installed
+    documentation. As with the address toolbar, the filter toolbar is not visible
+    by default and has to be activated via \menu{View|Toolbars|Filter Toolbar}.
+
+    \section1 Menus
+
+    \section2 File Menu
+
+    \list
+    \o \menu{File|Page Setup...} invokes a dialog allowing you to define
+    page layout properties, such as margin sizes, page orientation and paper size.
+    \o \menu{File|Print Preview...} provides a preview of the printed pages.
+    \o \menu{File|Print...} opens the \l{#Print Dialog}{\gui{Print} dialog}.
+    \o \menu{File|New Tab} opens a new empty tab in the \gui{Documentation}
+    window.
+    \o \menu{File|Close Tab} closes the current tab of the
+    \gui{Documentation} window.
+    \o \menu{File|Exit} closes the \QA application.
+    \endlist
+
+    \section2 Edit Menu
+
+    \list
+    \o \menu{Edit|Copy} copies any selected text to the clipboard.
+    \o \menu{Edit|Find in Text} invokes the \l{#Find Text Control}{\gui{Find Text}
+    control} at the lower end of the \gui{Documentation} window.
+    \o \menu{Edit|Find Next} looks for the next occurance of the specified
+    text in the \gui{Find Text} control.
+    \o \menu{Edit|Find Previous} looks for the previous occurance of
+    the specified text in the \l{#Find Text Control}{\gui{Find Text} control}.
+    \o \menu{Edit|Preferences} invokes the \l{#Preferences Dialog}{\gui{Preferences} dialog}.
+    \endlist
+
+    \section2 View Menu
+
+    \list
+    \o \menu{View|Zoom in} increases the font size in the current tab.
+    \o \menu{View|Zoom out} decreases the font size in the current tab.
+    \o \menu{View|Normal Size} resets the font size in the current tab.
+    \o \menu{View|Contents} toggles the display of the \gui{Contents} tool window.
+    \o \menu{View|Index} toggles the display of the \gui{Index} tool window.
+    \o \menu{View|Bookmarks} toggles the display of the \gui{Bookmarks} tool window.
+    \o \menu{View|Search} toggles the display of the Search in the \gui{Documentation} window.
+    \endlist
+
+    \section2 Go Menu
+
+    \list
+    \o \menu{Go|Home} goes to the home page.
+    \o \menu{Go|Back} displays the previous page in the history.
+    \o \menu{Go|Forward} displays the next page in the history.
+    \o \menu{Go|Sync with Table of Contents} syncs the \gui{Contents} tool window to the currently shown page.
+    \o \menu{Go|Next Page} selects the next tab in the \gui{Documentation} window.
+    \o \menu{Go|Previous Page} selects the previous tab in the \gui{Documentation} window.
+    \endlist
+
+    \section2 Bookmarks Menu
+
+    \list
+    \o \menu{Bookmarks|Add} adds the current page to the list of bookmarks.
+    \endlist
+
+    \section1 Dialogs
+
+    \section2 Print Dialog
+
+    This dialog is platform-specific. It gives access to various printer
+    options and can be used to print the document shown in the current tab.
+
+    \section2 Preferences Dialog
+
+    \img assistant-preferences-fonts.png
+
+    The \menu{Fonts} page allows you to change the font family and font sizes of the
+    browser window displaying the documentation or the application itself.
+
+    \img assistant-preferences-filters.png
+
+    The \menu{Filters} page lets you create and remove documentation
+    filters. To add a new filter, click the \gui{Add} button, specify a
+    filter name in the pop-up dialog and click \gui{OK}, then select
+    the filter attributes in the list box on the right hand side.
+    You can delete a filter by selecting it and clicking the \gui{Remove}
+    button.
+
+    \img assistant-preferences-documentation.png
+
+    The \menu{Documentation} page lets you install and remove compressed help
+    files. Click the \gui{Install} button and choose the path of the compressed
+    help file (*.qch) you would like to install.
+    To delete a help file, select a documentation set in the list and click
+    \gui{Remove}.
+
+    \img assistant-preferences-options.png
+
+    The \menu{Options} page lets you specify the homepage \QA will display when
+    you click the \gui{Home} button in \QA's main user interface. You can specify
+    the hompage by typing it here or clicking on one of the buttons below the
+    textbox. \gui{Current Page} sets the currently displayed page as your home
+    page while \gui{Restore to default} will reset your home page to the default
+    home page.
+
+    \section1 Find Text Control
+
+    This control is used to find text in the current page. Enter the text you want
+    to find in the line edit. The search is incremental, meaning that the most
+    relevant result is shown as you enter characters into the line edit.
+
+    If you check the \gui{Whole words only} checkbox, the search will only consider
+    whole words; for example, if you search for "spin" with this checkbox checked it will
+    not match "spinbox", but will match "spin". If you check the \gui{Case sensitive}
+    checkbox then, for example, "spin" will match "spin" but not "Spin". You can
+    search forwards or backwards from your current position in the page by clicking
+    the \gui{Previous} or \gui{Next} buttons. To hide the find control, either click the
+    \gui{Close} button or hit the \key{Esc} key.
+
+    \section1 Filtering Help Contents
+
+    \QA allows you to install any kind of documentation as long as it is organized
+    in Qt compressed help files (*.qch). For example, it is possible to install the
+    Qt reference documentation for Qt 4.4.0 and Qt 4.4.1 at the same time. In many
+    respects, this is very convenient since only one version of \QA is needed.
+    However, at the same time it becomes more complicated when performing tasks like
+    searching the index because nearly every keyword is defined in Qt 4.4.0 as well
+    as in Qt 4.4.1. This means that \QA will always ask the user to choose which one
+    should be displayed.
+
+    We use documentation filters to solve this issue. A filter is identified by its
+    name, and contains a list of filter attributes. An attribute is just a string and
+    can be freely chosen. Attributes are defined by the documentation itself, this
+    means that every documentation set usually has one or more attributes.
+
+    For example, the Qt 4.4.0 \QA documentation defines the attributes \c {assistant},
+    \c{tools} and \c{4.4.0}, \QD defines \c{designer}, \c{tools} and \c{4.4.0}.
+    The filter to display all tools would then define only the attribute
+    \c{tools} since this attribute is part of both documentation sets.
+    Adding the attribute \c{assistant} to the filter would then only show \QA
+    documentation since the \QD documentation does not contain this
+    attribute. Having an empty list of attributes in a filter will match all
+    documentation; i.e., it is equivalent to requesting unfiltered documentation.
+
+    \section1 Full Text Searching
+
+    \img assistant-search.png
+
+    \QA provides a powerful full text search engine. To search
+    for certain words or text, click the \gui{Search} tab in the \gui{Documentation}
+    window. Then enter the text you want to look for and press \key{Enter}
+    or click the \gui{Search} button. The search is not case sensitive, so,
+    for example, Foo, fOo and FOO are all treated as the same. The following are
+    examples of common search patterns:
+
+    \list
+    \o \c deep -- lists all the documents that contain the word 'deep'
+    \o \c{deep*} -- lists all the documents that contain a word beginning
+    with 'deep'
+    \o \c{deep copy} -- lists all documents that contain both 'deep' \e
+    and 'copy'
+    \o \c{"deep copy"} -- list all documents that contain the phrase 'deep copy'
+    \endlist
+
+    It is also possible to use the \gui{Advanced search} to get more flexibility.
+    You can specify some words so that hits containing these are excluded from the
+    result, or you can search for an exact phrase. Searching for similar words will
+    give results like these:
+
+    \list
+    \o \c{QStin} -- lists all the documents with titles that are similar, such as \c{QString}
+    \o \c{QSting} -- lists all the documents with titles that are similar, such as \c{QString}
+    \o \c{QStrin} -- lists all the documents with titles that are similar, such as \c{QString}
+    \endlist
+
+    Options can be combined to improve the search results.
+
+    The list of documents found is ordered according to the number of
+    occurrences of the search text which they contain, with those containing
+    the highest number of occurrences appearing first. Simply click any
+    document in the list to display it in the \gui{Documentation} window.
+
+    If the documentation has changed \mdash for example, if documents have been added
+    or removed \mdash \QA will index them again.
+
+*/
+
+/*!
+    \page assistant-custom-help-viewer.html
+    \title Using Qt Assistant as a Custom Help Viewer
+
+    \contentspage {Qt Assistant Manual}{Contents}
+    \previouspage Qt Assistant in More Detail
+
+    Using \QA as custom help viewer requires more than just being able to
+    display custom documentation. It is equally important that the
+    appearance of \QA can be customized so that it is seen as a
+    application-specific help viewer rather than \QA. This is achieved by
+    changing the window title or icon, as well as some application-specific
+    menu texts and actions. The complete list of possible customizations
+    can be found in the \l{Creating a Custom Help Collection File} section.
+
+    Another requirement of a custom help viewer is the ability to receive
+    actions or commands from the application it provides help for. This is
+    especially important when the application offers context sensitive help.
+    When used in this way, the help viewer may need to change its contents
+    depending on the state the application is currently in. This means that
+    the application has to communicate the current state to the help viewer.
+    The section about \l{Using Qt Assistant Remotely} explains how this can
+    be done.
+
+    \tableofcontents
+
+    The \l{Simple Text Viewer Example}{Simple Text Viewer} example uses the
+    techniques described in this document to show how to use \QA as a custom
+    help viewer for an application.
+
+    \warning In order to ship Qt Assistant in your application, it is crucial
+    that you include the sqlite plugin. For more information on how to include
+    plugins in your application, refer to the \l{Deploying Qt Applications}
+    {deployment documentation}.
+
+    \section1 Qt Help Collection Files
+
+    The first important point to know about \QA is that it stores all
+    settings related to its appearance \e and a list of installed
+    documentation in a help collection file. This means, when starting \QA
+    with different collection files, \QA may look totally different. This
+    complete separation of settings makes it possible to deploy \QA as a
+    custom help viewer for more than one application on one machine
+    without risk of interference between different instances of \QA.
+
+    To apply a certain help collection to \QA, specify the respective
+    collection file on the command line when starting it. For example:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 8
+
+    However, storing all settings in one collection file raises some problems.
+    The collection file is usually installed in the same directory as the
+    application itself, or one of its subdirectories. Depending on the
+    directory and the operating system, the user may not have any permissions
+    to modify this file which would happen when the user settings are stored.
+    Also, it may not even be possible to give the user write permissions;
+    e.g., when the file is located on a read-only medium like a CD-ROM.
+
+    Even if it is possible to give everybody the right to store their settings
+    in a globally available collection file, the settings from one user would
+    be overwritten by another user when exiting \QA.
+
+    To solve this dilemma, \QA creates user specific collection files which
+    are more or less copied from the original collection file. The user-specific
+    collection file will be saved in a subdirectory of the path returned by
+    QDesktopServices::DataLocation. The subdirectory, or \e{cache directory}
+    within this user-specific location, can be defined in the help collection
+    project file. For example:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 7
+
+    So, when calling
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 8
+
+    \QA actually uses the collection file:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 9
+
+    There is no need ever to start \QA with the user specific collection
+    file. Instead, the collection file shipped with the application should
+    always be used. Also, when adding or removing documentation from the
+    collection file (see next section) always use the normal collection file.
+    \QA will take care of synchronizing the user collection files when the
+    list of installed documentation has changed.
+
+    \section1 Displaying Custom Documentation
+
+    Before \QA is able to show documentation, it has to know where it can
+    find the actual documentation files, meaning that it has to know the
+    location of the Qt compressed help file (*.qch). As already mentioned,
+    \QA stores references to the compressed help files in the currently used
+    collection file. So, when creating a new collection file you can list
+    all compressed help files \QA should display.
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 5
+
+    Sometimes, depending on the application for which \QA acts as a
+    help viewer, more documentation needs to be added over time; for
+    example, when installing more application components or plugins.
+    This can be done manually by starting \QA, opening the \gui{Edit|Preferences}
+    dialog and navigating to the \gui{Documentation} tab page. Then click
+    the \gui{Add...} button, select a Qt compressed help file (*.qch)
+    and press \gui{Open}. However, this approach has the disadvantage
+    that every user has to do it manually to get access to the new
+    documentation.
+
+    The prefered way of adding documentation to an already existing collection
+    file is to use the \c{-register} command line flag of \QA. When starting
+    \QA with this flag, the documentation will be added and \QA will
+    exit right away displaying a message if the registration was successful
+    or not.
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 6
+
+    The \c{-quiet} flag can be passed on to \QA to prevent it from writing
+    out the status message.
+
+    \bold{Note:} \QA will show the documentation in the contents view in the same
+    order as it was registered.
+
+
+    \section1 Changing the Appearance of Qt Assistant
+
+    The appearance of \QA can be changed by passing different command line options
+    on startup. However, these command line options only allow to show or hide
+    specific widgets, like the contents or index view. Other customizations, such
+    as changing the application title or icon, or disabling the filter functionality,
+    can be done by creating a custom help collection file.
+
+    \section2 Creating a Custom Help Collection File
+
+    The help collection file (*.qhc) used by \QA is created when running the
+    \c qcollectiongenerator tool on a help collection project file (*.qhcp).
+    The project file format is XML and supports the following tags:
+
+    \table
+        \header
+            \o Tag
+            \o Brief Description
+        \row
+            \o \c{<title>}
+            \o This property is used to specify a window title for \QA.
+        \row
+            \o \c{<homePage>}
+            \o This tag specifies which page should be display when
+            pressing the home button in \QA's main user interface.
+        \row
+            \o \c{<startPage>}
+            \o This tag specifies which page \QA should initially
+            display when the help collection is used.
+        \row
+            \o \c{<currentFilter>}
+            \o This tag specifies the \l{Qt Assistant in More Detail#Preferences Dialog}{filter}
+            that is initially used.
+            If this filter is not specified, the documentation will not be filtered. This has
+            no impact if only one documentation set is installed.
+        \row
+            \o \c{<applicationIcon>}
+            \o This tag describes an icon that will be used instead of the normal \QA
+            application icon. This is specified as a relative path from the directory
+            containing the collection file.
+        \row
+            \o \c{<enableFilterFunctionality>}
+            \o This tag is used to enable or disable user accessible filter functionality,
+            making it possible to prevent the user from changing any filter when running \QA.
+            It does not mean that the internal filter functionality is completely disabled.
+            Set the value to \c{false} if you want to disable the filtering. If the filter
+            toolbar should be shown by default, set the attribute \c{visible} to \c{true}.
+        \row
+            \o \c{<enableDocumentationManager>}
+            \o This tag is used to specify whether the documentation manager should be shown
+            in the preferences dialog. Disabling the Documentation Manager allows you to limit
+            \QA to display a specific documentation set or make it impossible for the end user
+            to accidentally remove or install documentation. To hide the documentation manager,
+            set the tag value to \c{false}.
+        \row
+            \o \c{<enableAddressBar>}
+            \o This tag describes if the address bar can be shown. By default it is
+            enabled; if you want to disable it set the tag value to \c{false}. If the
+            address bar functionality is enabled, the address bar can be shown by setting the
+            tag attribute \c{visible} to \c{true}.
+        \row
+            \o \c{<aboutMenuText>, <text>}
+            \o The \c{aboutMenuText} tag lists texts for different languages which will
+            later appear in the \menu{Help} menu; e.g., "About Application". A text is
+            specified within the \c{text} tags; the \c{language} attribute takes the two
+            letter language name. The text is used as the default text if no language
+            attribute is specified.
+        \row
+            \o \c{<aboutDialog>, <file>, <icon>}
+            \o The \c{aboutDialog} tag can be used to specify the text for the \gui{About}
+            dialog that can be opened from the \menu{Help} menu. The text is taken from the
+            file in the \c{file} tags. It is possible to specify a different file or any
+            language. The icon defined by the \c{icon} tags is applied to any language.
+        \row
+            \o \c{<cacheDirectory>}
+            \o Specified as a path relative to the directory given by
+            QDesktopServices::DataLocation, the cache path is used to store index files
+            needed for the full text search and a copy of the collection file.
+            The copy is needed because \QA stores all its settings in the collection file;
+            i.e., it must be writable for the user.
+    \endtable
+
+    In addition to those \QA specific tags, the tags for generating and registering
+    documentation can be used. See \l{The Qt Help Framework#Creating a Qt Help Collection}
+    {Qt Help Collection} documentation for more information.
+
+    An example of a help collection file that uses all the available tags is shown below:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 1
+
+    To create the binary collection file, run the \c qcollectiongenerator tool:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 10
+
+    To test the generated collection file, start \QA in the following way:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 8
+
+    \section1 Using Qt Assistant Remotely
+
+    Even though the help viewer is a standalone application, it will mostly
+    be launched by the application it provides help for. This approach
+    gives the application the possibility to ask for specific help contents
+    to be displayed as soon as the help viewer is started. Another advantage
+    with this approach is that the application can communicate with the
+    help viewer process and can therefore request other help contents to be
+    shown depending on the current state of the application.
+
+    So, to use \QA as the custom help viewer of your application, simply
+    create a QProcess and specify the path to the Assistant executable. In order
+    to make Assistant listen to your application, turn on its remote control
+    functionality by passing the \c{-enableRemoteControl} command line option.
+
+    \warning The trailing '\0' must be appended separately to the QByteArray,
+    e.g., \c{QByteArray("command" + '\0')}.
+
+    The following example shows how this can be done:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 2
+
+    Once \QA is running, you can send commands by using the stdin channel of
+    the process. The code snippet below shows how to tell \QA to show a certain
+    page in the documentation.
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 3
+
+    The following commands can be used to control \QA:
+
+    \table
+        \header
+            \o Command
+            \o Brief Description
+        \row
+            \o \c{show <Widget>}
+            \o Shows the dock widget specified by <Widget>. If the widget
+            is already shown and this command is sent again, the widget will be
+            activated, meaning that it will be raised and given the input focus.
+            Possible values for <Widget> are "contents", "index", "bookmarks" or "search".
+        \row
+            \o \c{hide <Widget>}
+            \o Hides the dock widget specified by <Widget>. Possible values for
+            <Widget> are "contents", "index", "bookmarks" and "search".
+        \row
+            \o \c{setSource <Url>}
+            \o Displays the given <Url>. The URL can be absolute or relative
+            to the currently displayed page. If the URL is absolute, it has to
+            be a valid Qt help system URL; i.e., starting with "qthelp://".
+        \row
+            \o \c{activateKeyword <Keyword>}
+            \o Inserts the specified <Keyword> into the line edit of the
+            index dock widget and activates the corresponding item in the
+            index list. If such an item has more than one link associated
+            with it, a topic chooser will be shown.
+        \row
+            \o \c{activateIdentifier <Id>}
+            \o Displays the help contents for the given <Id>. An ID is unique
+            in each namespace and has only one link associated to it, so the
+            topic chooser will never pop up.
+        \row
+            \o \c{syncContents}
+            \o Selects the item in the contents widget which corresponds to
+            the currently displayed page.
+        \row
+            \o \c{setCurrentFilter}
+            \o Selects the specified filter and updates the visual representation
+            accordingly.
+        \row
+            \o \c{expandToc <Depth>}
+            \o Expands the table of contents tree to the given depth. If depth
+            is less than 1, the tree will be collapsed completely.
+    \endtable
+
+    If you want to send several commands within a short period of time, it is
+    recommended that you write only a single line to the stdin of the process
+    instead of one line for every command. The commands have to be separated by
+    a semicolon, as shown in the following example:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 4
+
+    \section1 Compatibility with Old Formats
+
+    In older versions of Qt, the help system was based on Document Content File
+    (DCF) and Qt Assistant Documentation Profile (ADP) formats. In contrast,
+    Qt Assistant and the help system used in Qt 4.4 use the formats described
+    earlier in this manual.
+
+    Unfortunately, the old file formats are not compatible with the new ones.
+    In general, the differences are not that big \mdash in most cases is the old
+    format is just a subset of the new one. One example is the \c namespace tag in
+    the Qt Help Project format, which was not part of the old format, but plays a vital
+    role in the new one. To help you to move to the new file format, we have created
+    a conversion wizard.
+
+    The wizard is started by executing \c qhelpconverter. It guides you through the
+    conversion of different parts of the file and generates a new \c qch or \c qhcp
+    file.
+
+    Once the wizard is finished and the files created, run the \c qhelpgenerator
+    or the \c qcollectiongenerator tool to generate the binary help files used by \QA.
+*/
+
+/*
+\section2 Modifying \QA with Command Line Options
+
+    Different help collections can be shown by simply passing the help collection
+    path to \QA. For example:
+
+    \snippet doc/src/snippets/code/doc_src_assistant-manual.qdoc 0
+
+    Other available options the can be passed on the command line.
+
+    \table
+        \header
+            \o Command Line Option
+            \o Brief Description
+        \row
+            \o -collectionFile <file.qhc>
+            \o Uses the specified collection file instead of the default one.
+        \row
+            \o -showUrl URL
+            \o Shows the document referenced by URL.
+        \row
+            \o -enableRemoteControl
+            \o Enables \QA to be remotly controlled.
+        \row
+            \o -show <widget>
+            \o Shows the specified dockwidget which can be "contents", "index",
+            "bookmarks" or "search".
+        \row
+            \o -hide <widget>
+            \o Hides the specified dockwidget which can be "contents", "index",
+            "bookmarks" or "search.
+        \row
+            \o -activate <widget>
+            \o Activates the specified dockwidget which can be "contents",
+            "index", "bookmarks" or "search.
+        \row
+            \o -register <doc.qch>
+            \o Registers the specified compressed help file in the given help
+            collection.
+        \row
+            \o -unregister <doc.qch>
+            \o Unregisters the specified compressed help file from the given
+            collection file.
+        \row
+            \o -quiet
+            \o Doesn't show any error, warning or success messages.
+    \endtable
+    */
diff --git a/doc/src/development/debug.qdoc b/doc/src/development/debug.qdoc
new file mode 100644
index 0000000000..f0fe128b3e
--- /dev/null
+++ b/doc/src/development/debug.qdoc
@@ -0,0 +1,243 @@
+/****************************************************************************
+**
+** 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 debug.html
+    \title Debugging Techniques
+
+    Here we present some useful hints to help you with debugging your
+    Qt-based software.
+
+    \tableofcontents
+
+    \section1 Configuring Qt for Debugging
+
+    When \l{Installation}{configuring Qt for installation}, it is possible
+    to ensure that it is built to include debug symbols that can make it
+    easier to track bugs in applications and libraries. However, on some
+    platforms, building Qt in debug mode will cause applications to be larger
+    than desirable.
+
+    \section2 Debugging in Mac OS X and Xcode
+
+    \section3 Debugging With/Without Frameworks
+
+    The basic stuff you need to know about debug libraries and
+    frameworks is found at developer.apple.com in: 
+    \l{http://developer.apple.com/technotes/tn2004/tn2124.html#SECDEBUGLIB}
+    {Apple Technicle Note TN2124} Qt follows that. 
+
+    When you build Qt, frameworks are built by default, and inside the
+    framework you will find both a release and a debug version (e.g.,
+    QtCore and QtCore_debug). If you pass the \c{-no-framework} flag
+    when you build Qt, two dylibs are built for each Qt library (e.g.,
+    libQtCore.4.dylib and libQtCore_debug.4.dylib).
+
+    What happens when you link depends on whether you use frameworks
+    or not. We don't see a compelling reason to recommend one over the
+    other.
+
+    \section4 With Frameworks:
+
+    Since the release and debug libraries are inside the framework,
+    the app is simply linked against the framework. Then when you run
+    in the debugger, you will get either the release version or the
+    debug version, depending on whether you set \c{DYLD_IMAGE_SUFFIX}.
+    If you don't set it, you get the release version by default (i.e.,
+    non _debug). If you set \c{DYLD_IMAGE_SUFFIX=_debug}, you get the
+    debug version.
+
+    \section4 Without Frameworks:
+
+    When you tell \e{qmake} to generate a Makefile with the debug
+    config, it will link against the _debug version of the libraries
+    and generate debug symbols for the app. Running this program in
+    GDB will then work like running GDB on other platforms, and you
+    will be able to trace inside Qt.
+
+    \section3 Debug Symbols and Size
+
+    The amount of space taken up by debug symbols generated by GCC can
+    be excessively large. However, with the release of Xcode 2.3 it is
+    now possible to use Dwarf symbols which take up a significantly
+    smaller amount of space.  To enable this feature when configuring
+    Qt, pass the \c{-dwarf-2} option to the configure script.
+
+    This is not enabled by default because previous versions of Xcode
+    will not work with the compiler flag used to implement this
+    feature. Mac OS X 10.5 will use dwarf-2 symbols by default.
+
+    dwarf-2 symbols contain references to source code, so the size of
+    the final debug application should compare favorably to a release
+    build.
+
+    \omit
+    Although it is not necessary to build Qt with debug symbols to use the
+    other techniques described in this document, certain features are only
+    available when Qt is configured for debugging.
+    \endomit
+
+    \section1 Command Line Options Recognized by Qt
+
+    When you run a Qt application, you can specify several
+    command-line options that can help with debugging. These are
+    recognized by QApplication.
+
+    \table
+    \header \o Option \o Description
+    \row \o \c -nograb
+         \o The application should never grab \link QWidget::grabMouse()
+            the mouse\endlink or \link QWidget::grabKeyboard() the
+            keyboard \endlink. This option is set by default when the
+            program is running in the \c gdb debugger under Linux.
+    \row \o \c -dograb
+         \o Ignore any implicit or explicit \c{-nograb}. \c -dograb wins over
+            \c -nograb even when \c -nograb is last on the command line.
+    \row \o \c -sync
+         \o Runs the application in X synchronous mode. Synchronous mode
+            forces the X server to perform each X client request
+            immediately and not use buffer optimization. It makes the
+            program easier to debug and often much slower. The \c -sync
+            option is only valid for the X11 version of Qt.
+    \endtable
+
+    \section1 Warning and Debugging Messages
+
+    Qt includes four global functions for writing out warning and debug
+    text. You can use them for the following purposes:
+
+    \list
+    \o qDebug() is used for writing custom debug output.
+    \o qWarning() is used to report warnings and recoverable errors in
+       your application.
+    \o qCritical() is used for writing critical error mesages and
+       reporting system errors.
+    \o qFatal() is used for writing fatal error messages shortly before exiting.
+    \endlist
+
+    If you include the <QtDebug> header file, the \c qDebug() function
+    can also be used as an output stream. For example:
+
+    \snippet doc/src/snippets/code/doc_src_debug.qdoc 0
+
+    The Qt implementation of these functions prints the text to the
+    \c stderr output under Unix/X11 and Mac OS X. With Windows, if it
+    is a console application, the text is sent to console; otherwise, it
+    is sent to the debugger. You can take over these functions by
+    installing a message handler using qInstallMsgHandler().
+
+    If the \c QT_FATAL_WARNINGS environment variable is set,
+    qWarning() exits after printing the warning message. This makes
+    it easy to obtain a backtrace in the debugger.
+
+    Both qDebug() and qWarning() are debugging tools. They can be
+    compiled away by defining \c QT_NO_DEBUG_OUTPUT and \c
+    QT_NO_WARNING_OUTPUT during compilation.
+
+    The debugging functions QObject::dumpObjectTree() and
+    QObject::dumpObjectInfo() are often useful when an application
+    looks or acts strangely. More useful if you use \l{QObject::setObjectName()}{object names}
+    than not, but often useful even without names.
+
+    \section1 Providing Support for the qDebug() Stream Operator
+
+    You can implement the stream operator used by qDebug() to provide
+    debugging support for your classes. The class that implements the
+    stream is \c QDebug. The functions you need to know about in \c
+    QDebug are \c space() and \c nospace(). They both return a debug
+    stream; the difference between them is whether a space is inserted
+    between each item. Here is an example for a class that represents
+    a 2D coordinate.
+
+    \snippet doc/src/snippets/qdebug/qdebugsnippet.cpp 0
+
+    Integration of custom types with Qt's meta-object system is covered
+    in more depth in the \l{Creating Custom Qt Types} document.
+
+    \section1 Debugging Macros
+
+    The header file \c <QtGlobal> contains some debugging macros and
+    \c{#define}s.
+
+    Three important macros are:
+    \list
+    \o \l{Q_ASSERT()}{Q_ASSERT}(cond), where \c cond is a boolean
+       expression, writes the warning "ASSERT: '\e{cond}' in file xyz.cpp, line
+       234" and exits if \c cond is false.
+    \o \l{Q_ASSERT_X()}{Q_ASSERT_X}(cond, where, what), where \c cond is a
+       boolean expression, \c where a location, and \c what a message,
+       writes the warning: "ASSERT failure in \c{where}: '\c{what}', file xyz.cpp, line 234"
+       and exits if \c cond is false.
+    \o \l{Q_CHECK_PTR()}{Q_CHECK_PTR}(ptr), where \c ptr is a pointer.
+       Writes the warning "In file xyz.cpp, line 234: Out of memory" and
+       exits if \c ptr is 0.
+    \endlist
+
+    These macros are useful for detecting program errors, e.g. like this:
+
+    \snippet doc/src/snippets/code/doc_src_debug.qdoc 1
+
+    Q_ASSERT(), Q_ASSERT_X(), and Q_CHECK_PTR() expand to nothing if
+    \c QT_NO_DEBUG is defined during compilation. For this reason,
+    the arguments to these macro should not have any side-effects.
+    Here is an incorrect usage of Q_CHECK_PTR():
+
+    \snippet doc/src/snippets/code/doc_src_debug.qdoc 2
+
+    If this code is compiled with \c QT_NO_DEBUG defined, the code in
+    the Q_CHECK_PTR() expression is not executed and \e alloc returns
+    an unitialized pointer.
+
+    The Qt library contains hundreds of internal checks that will
+    print warning messages when a programming error is detected. We
+    therefore recommend that you use a debug version of Qt when
+    developing Qt-based software.
+
+    \section1 Common Bugs
+
+    There is one bug that is so common that it deserves mention here:
+    If you include the Q_OBJECT macro in a class declaration and
+    run \link moc.html the meta-object compiler\endlink (\c{moc}),
+    but forget to link the \c{moc}-generated object code into your
+    executable, you will get very confusing error messages. Any link
+    error complaining about a lack of \c{vtbl}, \c{_vtbl}, \c{__vtbl}
+    or similar is likely to be a result of this problem.
+*/
diff --git a/doc/src/development/designer-manual.qdoc b/doc/src/development/designer-manual.qdoc
new file mode 100644
index 0000000000..5d8587a60e
--- /dev/null
+++ b/doc/src/development/designer-manual.qdoc
@@ -0,0 +1,2836 @@
+/****************************************************************************
+**
+** 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 designer-manual.html
+
+    \title Qt Designer Manual
+    \ingroup qttools
+    \keyword Qt Designer
+
+    \QD is Qt's tool for designing and building graphical user
+    interfaces (GUIs) from Qt components. You can compose and customize your
+    widgets or dialogs in a what-you-see-is-what-you-get (WYSIWYG) manner, and
+    test them using different styles and resolutions.
+
+    Widgets and forms created with \QD integrated seamlessly with programmed
+    code, using Qt's signals and slots mechanism, that lets you easily assign
+    behavior to graphical elements. All properties set in \QD can be changed
+    dynamically within the code. Furthermore, features like widget promotion
+    and custom plugins allow you to use your own components with \QD.
+
+    If you are new to \QD, you can take a look at the
+    \l{Getting To Know Qt Designer} document. For a quick tutorial on how to
+    use \QD, refer to \l{A Quick Start to Qt Designer}.
+
+    Qt Designer 4.5 boasts a long list of improvements. For a detailed list of
+    what is new, refer \l{What's New in Qt Designer 4.5}.
+
+    \image designer-multiple-screenshot.png
+
+    For more information on using \QD, you can take a look at the following
+    links:
+
+    \list
+        \o  \l{Qt Designer's Editing Modes}
+            \list
+                \o  \l{Qt Designer's Widget Editing Mode}{Widget Editing Mode}
+                \o  \l{Qt Designer's Signals and Slots Editing Mode}
+                      {Signals and Slots Editing Mode}
+                \o  \l{Qt Designer's Buddy Editing Mode}
+                      {Buddy Editing Mode}
+                \o  \l{Qt Designer's Tab Order Editing Mode}
+                      {Tab Order Editing Mode}
+            \endlist
+        \o  \l{Using Layouts in Qt Designer}
+        \o  \l{Saving, Previewing and Printing Forms in Qt Designer}
+        \o  \l{Using Containers in Qt Designer}
+        \o  \l{Creating Main Windows in Qt Designer}
+        \o  \l{Editing Resources with Qt Designer}
+        \o  \l{Using Stylesheets with Qt Designer}
+        \o  \l{Using a Designer UI File in Your Application}
+    \endlist
+
+    For advanced usage of \QD, you can refer to these links:
+
+    \list
+        \o  \l{Customizing Qt Designer Forms}
+        \o  \l{Using Custom Widgets with Qt Designer}
+        \o  \l{Creating Custom Widgets for Qt Designer}
+        \o  \l{Creating Custom Widget Extensions}
+        \o  \l{Qt Designer's UI File Format}
+    \endlist
+
+
+    \section1 Legal Notices
+
+    Some source code in \QD is licensed under specific highly permissive
+    licenses from the original authors. The Qt team gratefully acknowledges
+    these contributions to \QD and all uses of \QD should also acknowledge
+    these contributions and quote the following license statements in an
+    appendix to the documentation.
+
+    \list
+    \i \l{Implementation of the Recursive Shadow Casting Algorithm in Qt Designer}
+    \endlist
+*/
+
+
+
+/*!
+    \page designer-whats-new.html
+    \contentspage {Qt Designer Manual}{Contents}
+
+
+    \title What's New in Qt Designer 4.5
+
+    \section1 General Changes
+
+
+    \table
+        \header
+            \i  Widget Filter Box
+            \i  Widget Morphing
+            \i  Disambiguation Field
+        \row
+            \i  \inlineimage designer-widget-filter.png
+            \i  \inlineimage designer-widget-morph.png
+            \i  \inlineimage designer-disambiguation.png
+    \endtable
+
+    \list 1
+        \i  Displaying only icons in the \gui{Widget Box}: It is now possible
+            for the \gui{Widget Box} to display icons only. Simply select
+            \gui{Icon View} from the context menu.
+        \i  Filter for \gui{Widget Box}: A filter is now provided to quickly
+            locate the widget you need. If you use a particular widget
+            frequently, you can always add it to the
+            \l{Getting to Know Qt Designer#WidgetBox}{scratch pad}.
+        \i  Support for QButtonGroup: It is available via the context
+            menu of a selection of QAbstractButton objects.
+        \i  Improved support for item widgets: The item widgets' (e.g.,
+            QListWidget, QTableWidget, and QTreeWidget) contents dialogs have
+            been improved. You can now add translation comments and also modify
+            the header properties.
+        \i  Widget morphing: A widget can now be morphed from one type to
+            another with its layout and properties preserved. To begin, click
+            on your widget and select \gui{Morph into} from the context menu.
+        \i  Disambiguation field: The property editor now shows this extra
+            field under the \gui{accessibleDescription} property. This field
+            has been introduced to aid translators in the case of two source
+            texts being the same but used for different purposes. For example,
+            a dialog could have two \gui{Add} buttons for two different
+            reasons. \note To maintain compatibility, comments in UI files
+            created prior to Qt 4.5 will be listed in the \gui{Disambiguation}
+            field.
+    \endlist
+
+
+
+    \section1 Improved Shortcuts for the Editing Mode
+
+    \list
+        \i  The \key{Shift+Click} key combination now selects the ancestor for
+            nested layouts. This iterates from one ancestor to the other.
+
+        \i  The \key{Ctrl} key is now used to toggle and copy drag. Previously
+            this was done with the \key{Shift} key but is now changed to
+            conform to standards.
+
+        \i  The left mouse button does rubber band selection for form windows;
+            the middle mouse button does rubber band selection everywhere.
+    \endlist
+
+
+    \section1 Layouts
+    \list
+        \i  It is now possible to switch a widget's layout without breaking it
+            first. Simply select the existing layout and change it to another
+            type using the context menu or the layout buttons on the toolbar.
+
+        \i  To quickly populate a \gui{Form Layout}, you can now use the
+            \gui{Add form layout row...} item available in the context menu or
+            double-click on the red layout.
+    \endlist
+
+
+    \section1 Support for Embedded Design
+
+    \table
+        \header
+            \i  Comboboxes to Select a Device Profile
+        \row
+            \i  \inlineimage designer-embedded-preview.png
+    \endtable
+
+    It is now possible to specify embedded device profiles, e.g., Style, Font,
+    Screen DPI, resolution, default font, etc., in \gui{Preferences}. These
+    settings will affect the \gui{Form Editor}. The profiles will also be
+    visible with \gui{Preview}.
+
+
+    \section1 Related Classes
+
+    \list
+        \i  QUiLoader \mdash forms loaded with this class will now react to
+            QEvent::LanguageChange if QUiLoader::setLanguageChangeEnabled() or
+            QUiLoader::isLanguageChangeEnabled() is set to true.
+
+        \i  QDesignerCustomWidgetInterface \mdash the
+            \l{QDesignerCustomWidgetInterface::}{domXml()} function now has new
+            attributes for its \c{<ui>} element. These attributes are
+            \c{language} and \c{displayname}. The \c{language} element can be
+            one of the following "", "c++", "jambi". If this element is
+            specified, it must match the language in which Designer is running.
+            Otherwise, this element will not be available. The \c{displayname}
+            element represents the name that will be displayed in the
+            \gui{Widget Box}. Previously this was hardcoded to be the class
+            name.
+
+        \i  QWizard \mdash QWizard's page now has a string \c{id} attribute that
+            can be used to fill in enumeration values to be used by the
+            \c{uic}. However, this attribute has no effect on QUiLoader.
+    \endlist
+*/
+
+
+/*!
+    \page designer-to-know.html
+    \contentspage {Qt Designer Manual}{Contents}
+
+
+    \title Getting to Know Qt Designer
+
+    \tableofcontents
+
+    \image designer-screenshot.png
+
+    \section1 Launching Designer
+
+    The way that you launch \QD depends on your platform:
+
+    \list
+        \i On Windows, click the Start button, under the \gui Programs submenu,
+           open the \gui{Qt 4} submenu and click \gui Designer.
+        \i On Unix or Linux, you might find a \QD icon on the desktop
+           background or in the desktop start menu under the \gui Programming
+           or \gui Development submenus. You can launch \QD from this icon.
+           Alternatively, you can type \c{designer} in a terminal window.
+        \i On Mac OS X, double click on \QD in \gui Finder.
+    \endlist
+
+    \section1 The User Interface
+
+    When used as a standalone application, \QD's user interface can be
+    configured to provide either a multi-window user interface (the default
+    mode), or it can be used in docked window mode. When used from within an
+    integrated development environment (IDE) only the multi-window user
+    interface is available. You can switch modes in the \gui Preferences dialog
+    from the \gui Edit menu.
+
+    In multi-window mode, you can arrange each of the tool windows to suit your
+    working style. The main window consists of a menu bar, a tool bar, and a
+    widget box that contains the widgets you can use to create your user
+    interface.
+
+    \target MainWindow
+    \table
+        \row
+            \i \inlineimage designer-main-window.png
+            \i \bold{Qt Designer's Main Window}
+
+        The menu bar provides all the standard actions for managing forms,
+        using the clipboard, and accessing application-specific help.
+        The current editing mode, the tool windows, and the forms in use can
+        also be accessed via the menu bar.
+
+        The tool bar displays common actions that are used when editing a form.
+        These are also available via the main menu.
+
+        The widget box provides common widgets and layouts that are used to
+        design components. These are grouped into categories that reflect their
+        uses or features.
+    \endtable
+
+    Most features of \QD are accessible via the menu bar, the tool bar, or the
+    widget box. Some features are also available through context menus that can
+    be opened over the form windows. On most platforms, the right mouse is used
+    to open context menus.
+
+    \target WidgetBox
+    \table
+        \row
+            \i \inlineimage designer-widget-box.png
+            \i \bold{Qt Designer's Widget Box}
+
+        The widget box provides a selection of standard Qt widgets, layouts,
+        and other objects that can be used to create user interfaces on forms.
+        Each of the categories in the widget box contain widgets with similar
+        uses or related features.
+
+        \note Since Qt 4.4, new widgets have been included, e.g.,
+        QPlainTextEdit, QCommandLinkButton, QScrollArea, QMdiArea, and
+        QWebView.
+
+        You can display all of the available objects in a category by clicking
+        on the handle next to the category label. When in
+        \l{Qt Designer's Widget Editing Mode}{Widget Editing
+        Mode}, you can add objects to a form by dragging the appropriate items
+        from the widget box onto the form, and dropping them in the required
+        locations.
+
+        \QD provides a scratch pad feature that allows you to collect
+        frequently used objects in a separate category. The scratch pad
+        category can be filled with any widget currently displayed in a form
+        by dragging them from the form and dropping them onto the widget box.
+        These widgets can be used in the same way as any other widgets, but
+        they can also contain child widgets. Open a context menu over a widget
+        to change its name or remove it from the scratch pad.
+    \endtable
+
+
+    \section1 The Concept of Layouts in Qt
+
+    A layout is used to arrange and manage the elements that make up a user
+    interface. Qt provides a number of classes to automatically handle layouts
+    -- QHBoxLayout, QVBoxLayout, QGridLayout, and QFormLayout. These classes
+    solve the challenge of laying out widgets automatically, providing a user
+    interface that behaves predictably. Fortunately knowledge of the layout
+    classes is not required to arrange widgets with \QD. Instead, select one of
+    the \gui{Lay Out Horizontally}, \gui{Lay Out in a Grid}, etc., options from
+    the context menu.
+
+    Each Qt widget has a recommended size, known as \l{QWidget::}{sizeHint()}.
+    The layout manager will attempt to resize a widget to meet its size hint.
+    In some cases, there is no need to have a different size. For example, the
+    height of a QLineEdit is always a fixed value, depending on font size and
+    style. In other cases, you may require the size to change, e.g., the width
+    of a QLineEdit or the width and height of item view widgets. This is where
+    the widget size constraints -- \l{QWidget::minimumSize()}{minimumSize} and
+    \l{QWidget::maximumSize()}{maximumSize} constraints come into play. These
+    are properties you can set in the property editor. For example, to override
+    the default \l{QWidget::}{sizeHint()}, simply set
+    \l{QWidget::minimumSize()}{minimumSize} and \l{QWidget::maximumSize()}
+    {maximumSize} to the same value. Alternatively, to use the current size as
+    a size constraint value, choose one of the \gui{Size Constraint} options
+    from the widget's context menu. The layout  will then ensure that those
+    constraints are met. To control the size of your widgets via code, you can
+    reimplement \l{QWidget::}{sizeHint()} in your code.
+
+    The screenshot below shows the breakdown of a basic user interface designed
+    using a grid. The coordinates on the screenshot show the position of each
+    widget within the grid.
+
+    \image addressbook-tutorial-part3-labeled-layout.png
+
+    \note Inside the grid, the QPushButton objects are actually nested. The
+    buttons on the right are first placed in a QVBoxLayout; the buttons at the
+    bottom are first placed in a QHBoxLayout. Finally, they are put into
+    coordinates (1,2) and (3,1) of the QGridLayout.
+
+    To visualize, imagine the layout as a box that shrinks as much as possible,
+    attempting to \e squeeze your widgets in a neat arrangement, and, at the
+    same time, maximize the use of available space.
+
+    Qt's layouts help when you:
+
+    \list 1
+        \i  Resize the user face to fit different window sizes.
+        \i  Resize elements within the user interface to suit different
+            localizations.
+        \i  Arrange elements to adhere to layout guidelines for different
+            platforms.
+    \endlist
+
+    So, you no longer have to worry about rearranging widgets for different
+    platforms, settings, and languages.
+
+    The example below shows how different localizations can affect the user
+    interface. When a localization requires more space for longer text strings
+    the Qt layout automatically scales to accommodate this, while ensuring that
+    the user interface looks presentable and still matches the platform
+    guidelines.
+
+    \table
+        \header
+            \i  A Dialog in English
+            \i  A Dialog in French
+        \row
+            \i  \image designer-english-dialog.png
+            \i  \image designer-french-dialog.png
+    \endtable
+
+    The process of laying out widgets consists of creating the layout hierarchy
+    while setting as few widget size constraints as possible.
+
+    For a more technical perspective on Qt's layout classes, refer to the
+    \l{Layout Management} documentation.
+*/
+
+
+/*!
+    \page designer-quick-start.html
+    \contentspage {Qt Designer Manual}{Contents}
+
+
+    \title A Quick Start to Qt Designer
+
+    Using \QD involves \bold four basic steps:
+
+    \list 1
+        \o  Choose your form and objects
+        \o  Lay the objects out on the form
+        \o  Connect the signals to the slots
+        \o  Preview the form
+    \endlist
+
+    \image rgbController-screenshot.png
+
+    Suppose you would like to design a small widget (see screenshot above) that
+    contains the controls needed to manipulate Red, Green and Blue (RGB) values
+    -- a type of widget that can be seen everywhere in image manipulation
+    programs.
+
+    \table
+    \row
+    \i \inlineimage designer-choosing-form.png
+    \i \bold{Choosing a Form}
+
+    You start by choosing \gui Widget from the \gui{New Form} dialog.
+    \endtable
+
+
+    \table
+    \row
+    \i  \inlineimage rgbController-arrangement.png
+    \i  \bold{Placing Widgets on a Form}
+
+    Drag three labels, three spin boxes and three vertical sliders on to your
+    form. To change the label's default text, simply double-click on it. You
+    can arrange them according to how you would like them to be laid out.
+    \endtable
+
+    To ensure that they are laid out exactly like this in your program, you
+    need to place these widgets into a layout. We will do this in groups of
+    three. Select the "RED" label. Then, hold down \key Ctrl while you select
+    its corresponding spin box and slider. In the \gui{Form} menu, select
+    \gui{Lay Out in a Grid}.
+
+    \table
+        \row
+            \i \inlineimage rgbController-form-gridLayout.png
+            \i \inlineimage rgbController-selectForLayout.png
+    \endtable
+
+
+    Repeat the step for the other two labels along with their corresponding
+    spin boxes and sliders as well.
+
+    The next step is to combine all three layouts into one \bold{main layout}.
+    The main layout is the top level widget's (in this case, the QWidget)
+    layout. It is important that your top level widget has a layout; otherwise,
+    the widgets on your window will not resize when your window is resized. To
+    set the layout, \gui{Right click} anywhere on your form, outside of the
+    three separate layouts, and select \gui{Lay Out Horizontally}.
+    Alternatively, you could also select \gui{Lay Out in a Grid} -- you will
+    still see the same arrangement (shown below).
+
+    \image rgbController-final-layout.png
+
+    \note Main layouts cannot be seen on the form. To check if you have a main
+    layout installed, try resizing your form; your widgets should resize
+    accordingly. Alternatively, you can take a look at \QD's
+    \gui{Object Inspector}. If your top level widget does not have a layout,
+    you will see the broken layout icon next to it,
+    \inlineimage rgbController-no-toplevel-layout.png
+    .
+
+    When you click on the slider and drag it to a certain value, you want the
+    spin box to display the slider's position. To accomplish this behavior, you
+    need to connect the slider's \l{QAbstractSlider::}{valueChanged()} signal
+    to the spin box's \l{QSpinBox::}{setValue()} slot. You also need to make
+    the reverse connections, e.g., connect the spin box's \l{QSpinBox::}
+    {valueChanged()} signal to the slider's \l{QAbstractSlider::value()}
+    {setValue()} slot.
+
+    To do this, you have to switch to \gui{Edit Signals/Slots} mode, either by
+    pressing \key{F4} or something \gui{Edit Signals/Slots} from the \gui{Edit}
+    menu.
+
+    \table
+        \row
+            \i \inlineimage rgbController-signalsAndSlots.png
+            \i \bold{Connecting Signals to Slots}
+
+        Click on the slider and drag the cursor towards the spin box. The
+        \gui{Configure Connection} dialog, shown below, will pop up. Select the
+        correct signal and slot and click \gui OK.
+    \endtable
+
+    \image rgbController-configure-connection1.png
+
+    Repeat the step (in reverse order), clicking on the spin box and dragging
+    the cursor towards the slider, to connect the spin box's
+    \l{QSpinBox::}{valueChanged()} signal to the slider's
+    \l{QAbstractSlider::value()}{setValue()} slot.
+
+    You can use the screenshot below as a guide to selecting the correct signal
+    and slot.
+
+    \image rgbController-configure-connection2.png
+
+    Now that you have successfully connected the objects for the "RED"
+    component of the RGB Controller, do the same for the "GREEN" and "BLUE"
+    components as well.
+
+    Since RGB values range between 0 and 255, we need to limit the spin box
+    and slider to that particular range.
+
+    \table
+        \row
+            \i \inlineimage rgbController-property-editing.png
+            \i \bold{Setting Widget Properties}
+
+        Click on the first spin box. Within the \gui{Property Editor}, you will
+        see \l{QSpinBox}'s properties. Enter "255" for the
+        \l{QSpinBox::}{maximum} property. Then, click on the first vertical
+        slider, you will see \l{QAbstractSlider}'s properties. Enter "255" for
+        the \l{QAbstractSlider::}{maximum} property as well. Repeat this
+        process for the remaining  spin boxes and sliders.
+    \endtable
+
+    Now, we preview your form to see how it would look in your application -
+    press \key{Ctrl + R} or select \gui Preview from the \gui Form menu. Try
+    dragging the slider - the spin box will mirror its value too (and vice
+    versa). Also, you can resize it to see how the layouts that are used to
+    manage the child widgets, respond to different window sizes.
+*/
+
+
+/*!
+    \page designer-editing-mode.html
+    \previouspage Getting to Know Qt Designer
+    \contentspage {Qt Designer Manual}{Contents}
+    \nextpage Using Layouts in Qt Designer
+
+    \title Qt Designer's Editing Modes
+
+    \QD provides four editing modes: \l{Qt Designer's Widget Editing Mode}
+    {Widget Editing Mode}, \l{Qt Designer's Signals and Slots Editing Mode}
+    {Signals and Slots Editing Mode}, \l{Qt Designer's Buddy Editing Mode}
+    {Buddy Editing Mode} and \l{Qt Designer's Tab Order Editing Mode}
+    {Tab Order Editing Mode}. When working with \QD, you will always be in one
+    of these four modes. To switch between modes, simply select it from the
+    \gui{Edit} menu or the toolbar. The table below describes these modes in
+    further detail.
+
+    \table
+        \header \i  \i  \bold{Editing Modes}
+        \row
+            \i  \inlineimage designer-widget-tool.png
+            \i  In \l{Qt Designer's Widget Editing Mode}{Edit} mode, we can
+                change the appearance of the form, add layouts, and edit the
+                properties of each widget. To switch to this mode, press
+                \key{F3}. This is \QD's default mode.
+
+        \row
+            \i  \inlineimage designer-connection-tool.png
+            \i  In \l{Qt Designer's Signals and Slots Editing Mode}
+                {Signals and Slots} mode, we can connect widgets together using
+                Qt's signals and slots mechanism. To switch to this mode, press
+                \key{F4}.
+
+        \row
+            \i  \inlineimage designer-buddy-tool.png
+            \i  In \l{Qt Designer's Buddy Editing Mode}{Buddy Editing Mode},
+                buddy widgets can be assigned to label widgets to help them
+                handle keyboard focus correctly.
+
+        \row
+            \i  \inlineimage designer-tab-order-tool.png
+            \i  In \l{Qt Designer's Tab Order Editing Mode}
+                {Tab Order Editing Mode}, we can set the order in which widgets
+                receive the keyboard focus.
+    \endtable
+
+*/
+
+
+/*!
+    \page designer-widget-mode.html
+    \previouspage Qt Designer's Editing Modes
+    \contentspage {Qt Designer Manual}{Contents}
+    \nextpage Qt Designer's Signals and Slots Editing Mode
+
+    \title Qt Designer's Widget Editing Mode
+
+    \image designer-editing-mode.png
+
+    In the Widget Editing Mode, objects can be dragged from the main window's
+    widget box to a form, edited, resized, dragged around on the form, and even
+    dragged between forms. Object properties can be modified interactively, so
+    that changes can be seen immediately. The editing interface is intuitive
+    for simple operations, yet it still supports Qt's powerful layout
+    facilities.
+
+
+    \tableofcontents
+
+    To create and edit new forms, open the \gui File menu and select
+    \gui{New Form...} or press \key{Ctrl+N}. Existing forms can also be edited
+    by selecting \gui{Open Form...} from the \gui File menu or pressing
+    \key{Ctrl+O}.
+
+    At any point, you can save your form by selecting the \gui{Save From As...}
+    option from the \gui File menu. The UI files saved by \QD contain
+    information about the objects used, and any details of signal and slot
+    connections between them.
+
+
+    \section1 Editing A Form
+
+    By default, new forms are opened in widget editing mode. To switch to Edit
+    mode from another mode, select \gui{Edit Widgets} from the \gui Edit menu
+    or press the \key F3 key.
+
+    Objects are added to the form by dragging them from the main widget box
+    and dropping them in the desired location on the form. Once there, they
+    can be moved around simply by dragging them, or using the cursor keys.
+    Pressing the \key Ctrl key at the same time moves the selected widget
+    pixel by pixel, while using the cursor keys alone make the selected widget
+    snap to the grid when it is moved. Objects can be selected by clicking on
+    them with the left mouse button. You can also use the \key Tab key to
+    change the selection.
+
+    ### Screenshot of widget box, again
+
+    The widget box contains objects in a number of different categories, all of
+    which can be placed on the form as required. The only objects that require
+    a little more preparation are the \gui Container widgets. These are
+    described in further detail in the \l{Using Containers in Qt Designer}
+    chapter.
+
+
+    \target SelectingObjects
+    \table
+        \row
+            \i  \inlineimage designer-selecting-widget.png
+            \i  \bold{Selecting Objects}
+
+        Objects on the form are selected by clicking on them with the left
+        mouse button. When an object is selected, resize handles are shown at
+        each corner and the midpoint of each side, indicating that it can be
+        resized.
+
+        To select additional objects, hold down the \key Shift key and click on
+        them. If more than one object is selected, the current object will be
+        displayed with resize handles of a different color.
+
+        To move a widget within a layout, hold down \key Shift and \key Control
+        while dragging the widget. This extends the selection to the widget's
+        parent layout.
+
+        Alternatively, objects can be selected in the
+        \l{The Object Inspector}{Object Inspector}.
+    \endtable
+
+    When a widget is selected, normal clipboard operations such as cut, copy,
+    and paste can be performed on it. All of these operations can be done and
+    undone, as necessary.
+
+    The following shortcuts can be used:
+
+    \target ShortcutsForEditing
+    \table
+        \header \i Action       \i Shortcut     \i Description
+        \row
+            \i Cut
+            \i \key{Ctrl+X}
+            \i Cuts the selected objects to the clipboard.
+        \row
+            \i Copy
+            \i \key{Ctrl+C}
+            \i Copies the selected objects to the clipboard.
+        \row
+            \i Paste
+            \i \key{Ctrl+V}
+            \i Pastes the objects in the clipboard onto the form.
+        \row
+            \i Delete
+            \i \key Delete
+            \i Deletes the selected objects.
+        \row
+            \i Clone object
+            \i \key{Ctrl+drag} (leftmouse button)
+            \i Makes a copy of the selected object or group of objects.
+        \row
+            \i Preview
+            \i \key{Ctrl+R}
+            \i Shows a preview of the form.
+    \endtable
+
+    All of the above actions (apart from cloning) can be accessed via both the
+    \gui Edit menu and the form's context menu. These menus also provide
+    funcitons for laying out objects as well as a \gui{Select All} function to
+    select all the objects on the form.
+
+    Widgets are not unique objects; you can make as many copies of them as you
+    need. To quickly duplicate a widget, you can clone it by holding down the
+    \key Ctrl key and dragging it. This allows widgets to be copied and placed
+    on the form more quickly than with clipboard operations.
+
+
+    \target DragAndDrop
+    \table
+        \row
+            \i \inlineimage designer-dragging-onto-form.png
+            \i \bold{Drag and Drop}
+
+        \QD makes extensive use of the drag and drop facilities provided by Qt.
+        Widgets can be dragged from the widget box and dropped onto the form.
+
+        Widgets can also be "cloned" on the form: Holding down \key Ctrl and
+        dragging the widget creates a copy of the widget that can be dragged to
+        a new position.
+
+        It is also possible to drop Widgets onto the \l {The Object Inspector}
+        {Object Inspector} to handle nested layouts easily.
+    \endtable
+
+    \QD allows selections of objects to be copied, pasted, and dragged between
+    forms. You can use this feature to create more than one copy of the same
+    form, and experiment with different layouts in each of them.
+
+
+    \section2 The Property Editor
+
+    The Property Editor always displays properties of the currently selected
+    object on the form. The available properties depend on the object being
+    edited, but all of the widgets provided have common properties such as
+    \l{QObject::}{objectName}, the object's internal name, and
+    \l{QWidget::}{enabled}, the property that determines whether an
+    object can be interacted with or not.
+
+
+    \target EditingProperties
+    \table
+        \row
+            \i \inlineimage designer-property-editor.png
+            \i \bold{Editing Properties}
+
+        The property editor uses standard Qt input widgets to manage the
+        properties of jbects on the form. Textual properties are shown in line
+        edits, integer properties are displayed in spinboxes, boolean
+        properties are displayed in check boxes, and compound properties such
+        as colors and sizes are presented in drop-down lists of input widgets.
+
+        Modified properties are indicated with bold labels. To reset them, click
+        the arrow button on the right.
+
+        Changes in properties are applied to all selected objects that have the
+        same property.
+    \endtable
+
+    Certain properties are treated specially by the property editor:
+
+    \list
+        \o Compound properties -- properties that are made up of more than one
+           value -- are represented as nodes that can be expanded, allowing
+           their values to be edited.
+        \o Properties that contain a choice or selection of flags are edited
+           via combo boxes with checkable items.
+        \o Properties that allow access to rich data types, such as QPalette,
+           are modified using dialogs that open when the properties are edited.
+           QLabel and the widgets in the \gui Buttons section of the widget box
+           have a \c text property that can also be edited by double-clicking
+           on the widget or by pressing \gui F2. \QD interprets the backslash
+           (\\) character specially, enabling newline (\\n) characters to be
+           inserted into the text; the \\\\ character sequence is used to
+           insert a single backslash into the text. A context menu can also be
+           opened while editing, providing another way to insert special
+           characters and newlines into the text.
+    \endlist
+
+
+    \section2 Dynamic Properties
+
+    The property editor can also be used to add new
+    \l{QObject#Dynamic Properties}{dynamic properties} to both standard Qt
+    widgets and to forms themselves. Since Qt 4.4, dynamic properties are added
+    and removed via the property editor's toolbar, shown below.
+
+    \image designer-property-editor-toolbar.png
+
+    To add a dynamic property, clcik on the \gui Add button
+    \inlineimage designer-property-editor-add-dynamic.png
+    . To remove it, click on the \gui Remove button
+    \inlineimage designer-property-editor-remove-dynamic.png
+     instead. You can also sort the properties alphabetically and change the
+    color groups by clickinig on the \gui Configure button
+    \inlineimage designer-property-editor-configure.png
+    .
+
+    \section2 The Object Inspector
+    \table
+        \row
+            \i  \inlineimage designer-object-inspector.png
+            \i  \bold{The Object Inspector}
+
+        The \gui{Object Inspector} displays a hierarchical list of all the
+        objects on the form that is currently being edited. To show the child
+        objects of a container widget or a layout, click the handle next to the
+        object label.
+
+        Each object on a form can be selected by clicking on the corresponding
+        item in the \gui{Object Inspector}. Right-clicking opens the form's
+        context menu. These features can be useful if you have many overlapping
+        objects. To locate an object in the \gui{Object Inspector}, use
+        \key{Ctrl+F}.
+
+        Since Qt 4.4, double-clicking on the object's name allows you to change
+        the object's name with the in-place editor.
+
+        Since Qt 4.5, the \gui{Object Inspector} displays the layout state of
+        the containers. The broken layout icon ###ICON is displayed if there is
+        something wrong with the layouts.
+
+    \endtable
+*/
+
+
+/*!
+    \page designer-layouts.html
+    \previouspage Qt Designer's Widget Editing Mode
+    \contentspage
+    \nextpage Qt Designer's Signals and Slots Editing Mode
+
+    \title Using Layouts in Qt Designer
+
+    Before a form can be used, the objects on the form need to be placed into
+    layouts. This ensures that the objects will be displayed properly when the
+    form is previewed or used in an application. Placing objects in a layout
+    also ensures that they will be resized correctly when the form is resized.
+
+
+    \tableofcontents
+
+    \section1 Applying and Breaking Layouts
+
+    The simplest way to manage objects is to apply a layout to a group of
+    existing objects. This is achieved by selecting the objects that you need
+    to manage and applying one of the standard layouts using the main toolbar,
+    the \gui Form menu, or the form's context menu.
+
+    Once widgets have been inserted into a layout, it is not possible to move
+    and resize them individually because the layout itself controls the
+    geometry of each widget within it, taking account of the hints provided by
+    spacers. Instead, you must either break the layout and adjust each object's
+    geometry manually, or you can influence the widget's geometry by resizing
+    the layout.
+
+    To break the layout, press \key{Ctrl+0} or choose \gui{Break Layout} from
+    the form's context menu, the \gui Form menu or the main toolbar. You can
+    also add and remove spacers from the layout to influence the geometries of
+    the widgets.
+
+
+    \target InsertingObjectsIntoALayout
+    \table
+        \row
+            \i  \inlineimage designer-layout-inserting.png
+            \i  \bold{Inserting Objects into a Layout}
+
+        Objects can be inserted into an existing layout by dragging them from
+        their current positions and dropping them at the required location. A
+        blue cursor is displayed in the layout as an object is dragged over
+        it to indicate where the object will be added.
+    \endtable
+
+
+    \section2 Setting A Top Level Layout
+
+    The form's top level layout can be set by clearing the slection (click the
+    left mouse button on the form itself) and applying a layout. A top level
+    layout is necessary to ensure that your widgets will resize correctly when
+    its window is resized. To check if you have set a top level layout, preview
+    your widget and attempt to resize the window by dragging the size grip.
+
+    \table
+        \row
+            \i  \inlineimage designer-set-layout.png
+            \i  \bold{Applying a Layout}
+
+        To apply a layout, you can select your choice of layout from the
+        toolbar shown on the left, or from the context menu shown below.
+    \endtable
+
+    \image designer-set-layout2.png
+
+
+    \section2 Horizontal and Vertical Layouts
+
+    The simplest way to arrange objects on a form is to place them in a
+    horizontal or vertical layout. Horizontal layouts ensure that the widgets
+    within are aligned horizontally; vertical layouts ensure that they are
+    aligned vertically.
+
+    Horizontal and vertical layouts can be combined and nested to any depth.
+    However, if you need more control over the placement of objects, consider
+    using the grid layout.
+
+
+    \section3 The Grid Layout
+
+    Complex form layouts can be created by placing objects in a grid layout.
+    This kind of layout gives the form designer much more freedom to arrange
+    widgets on the form, but can result in a much less flexible layout.
+    However, for some kinds of form layout, a grid arrangement is much more
+    suitable than a nested arrangement of horizontal and vertical layouts.
+
+
+    \section3 Splitter Layouts
+
+    Another common way to manage the layout of objects on a form is to place
+    them in a splitter. These splitters arrange the objects horizontally or
+    vertically in the same way as normal layouts, but also allow the user to
+    adjust the amount of space allocated to each object.
+
+    \image designer-splitter-layout.png
+
+    Although QSplitter is a container widget, \QD treats splitter objects as
+    layouts that are applied to existing widgets. To place a group of widgets
+    into a splitter, select them
+    \l{Qt Designer's Widget Editing Mode#SelectingObjects}{as described here}
+    then apply the splitter layout by using the appropriate toolbar button,
+    keyboard shortcut, or \gui{Lay out} context menu entry.
+
+
+    \section3 The Form Layout
+
+    Since Qt 4.4, another layout class has been included -- QFormLayout. This
+    class manages widgets in a two-column form; the left column holds labels
+    and the right column holds field widgets such as line edits, spin boxes,
+    etc. The QFormLayout class adheres to various platform look and feel
+    guidelines and supports wrapping for long rows.
+
+    \image designer-form-layout.png
+
+    The UI file above results in the previews shown below.
+
+    \table
+        \header
+            \i  Windows XP
+            \i  Mac OS X
+            \i  Cleanlooks
+        \row
+            \i  \inlineimage designer-form-layout-windowsXP.png
+            \i  \inlineimage designer-form-layout-macintosh.png
+            \i  \inlineimage designer-form-layout-cleanlooks.png
+    \endtable
+
+
+    \section2 Shortcut Keys
+
+    In addition to the standard toolbar and context menu entries, there is also
+    a set of keyboard shortcuts to apply layouts on widgets.
+
+    \target LayoutShortcuts
+    \table
+        \header
+            \i  Layout
+            \i  Shortcut
+            \i  Description
+        \row
+            \i  Horizontal
+            \i  \key{Ctrl+1}
+            \i  Places the selected objects in a horizontal layout.
+        \row
+            \i  Vertical
+            \i  \key{Ctrl+2}
+            \i  Places the selected objects in a vertical layout.
+        \row
+            \i  Grid
+            \i  \key{Ctrl+5}
+            \i  Places the selected objects in a grid layout.
+        \row
+            \i  Form
+            \i  \key{Ctrl+6}
+            \i  Places the selected objects in a form layout.
+        \row
+            \i  Horizontal splitter
+            \i  \key{Ctrl+3}
+            \i  Creates a horizontal splitter and places the selected objects
+                inside it.
+        \row
+            \i  Vertical splitter
+            \i  \key{Ctrl+4}
+            \i  Creates a vertical splitter and places the selected objects
+                inside it.
+        \row
+            \i  Adjust size
+            \i  \key{Ctrl+J}
+            \i  Adjusts the size of the layout to ensure that each child object
+                has sufficient space to display its contents. See
+                QWidget::adjustSize() for more information.
+    \endtable
+
+    \note \key{Ctrl+0} is used to break a layout.
+
+*/
+
+
+/*!
+    \page designer-preview.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Using Layouts in Qt Designer
+    \nextpage Qt Designer's Buddy Editing Mode
+    \title Saving, Previewing and Printing Forms in Qt Designer
+
+    Although \QD's forms are accurate representations of the components being
+    edited, it is useful to preview the final appearance while editing. This
+    feature can be activated by opening the \gui Form menu and selecting
+    \gui Preview, or by pressing \key{Ctrl+R} when in the form.
+
+    \image designer-dialog-preview.png
+
+    The preview shows exactly what the final component will look like when used
+    in an application.
+
+    Since Qt 4.4, it is possible to preview forms with various skins - default
+    skins, skins created with Qt Style Sheets or device skins. This feature
+    simulates the effect of calling \c{QApplication::setStyleSheet()} in the
+    application.
+
+    To preview your form with skins, open the \gui Edit menu and select
+    \gui{Preferences...}
+
+    You will see the dialog shown below:
+
+    \image designer-preview-style.png
+
+    The \gui{Print/Preview Configuration} checkbox must be checked to activate
+    previews of skins. You can select the styles provided from the \gui{Style}
+    drop-down box.
+
+    \image designer-preview-style-selection.png
+
+    Alternatively, you can preview custom style sheet created with Qt Style
+    Sheets. The figure below shows an example of Qt Style Sheet syntax and the
+    corresponding output.
+
+    \image designer-preview-stylesheet.png
+
+    Another option would be to preview your form with device skins. A list of
+    generic device skins are available in \QD, however, you may also use
+    other QVFB skins with the \gui{Browse...} option.
+
+    \image designer-preview-deviceskin-selection.png
+
+
+    \section1 Viewing the Form's Code
+
+    Since Qt 4.4, it is possible to view code generated by the User Interface
+    Compiler (uic) for the \QD form.
+
+    \image designer-form-viewcode.png
+
+    Select \gui{View Code...} from the \gui{Form} menu and a dialog with the
+    generated code will be displayed. The screenshot below is an example of
+    code generated by the \c{uic}.
+
+    \image designer-code-viewer.png
+
+    \section1 Saving and Printing the Form
+
+    Forms created in \QD can be saved to an image or printed.
+
+    \table
+    \row
+    \i \inlineimage designer-file-menu.png
+    \i \bold{Saving Forms}
+
+    To save a form as an image, choose the \gui{Save Image...} option. The file
+    will be saved in \c{.png} format.
+
+    \bold{Printing Forms}
+
+    To print a form, select the \gui{Print...} option.
+
+    \endtable
+*/
+
+
+/*!
+    \page designer-connection-mode.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Using Layouts in Qt Designer
+    \nextpage Qt Designer's Buddy Editing Mode
+
+
+    \title Qt Designer's Signals and Slots Editing Mode
+
+    \image designer-connection-mode.png
+
+    In \QD's signals and slots editing mode, you can connect objects in a form
+    together using Qt's signals and slots mechanism. Both widgets and layouts
+    can be connected via an intuitive connection interface, using the menu of
+    compatible signals and slots provided by \QD. When a form is saved, all
+    connections are preserved so that they will be ready for use when your
+    project is built.
+
+
+    \tableofcontents
+
+    For more information on Qt's signals and sltos mechanism, refer to the
+    \l{Signals and Slots} document.
+
+
+    \section1 Connecting Objects
+
+    To begin connecting objects, enter the signals and slots editing mode by
+    opening the \gui Edit menu and selecting \gui{Edit Signals/Slots}, or by
+    pressing the \key F4 key.
+
+    All widgets and layouts on the form can be connected together. However,
+    spacers just provide spacing hints to layouts, so they cannot be connected
+    to other objects.
+
+
+    \target HighlightedObjects
+    \table
+        \row
+            \i  \inlineimage designer-connection-highlight.png
+            \i  \bold{Highlighted Objects}
+
+        When the cursor is over an object that can be used in a connection, the
+        object will be highlighted.
+    \endtable
+
+    To make a connectionn, press the left mouse button and drag the cursor
+    towards the object you want to connect it to. As you do this, a line will
+    extend from the source object to the cursor. If the cursor is over another
+    object on the form, the line will end with an arrow head that points to the
+    destination object. This indicates that a connection will be made between
+    the two objects when you release the mouse button.
+
+    You can abandon the connection at any point while you are dragging the
+    connection path by pressing \key{Esc}.
+
+    \target MakingAConnection
+    \table
+        \row
+            \i  \inlineimage designer-connection-making.png
+            \i  \bold{Making a Connection}
+
+        The connection path will change its shape as the cursor moves around
+        the form. As it passes over objects, they are highlighted, indicating
+        that they can be used in a signal and slot connection. Release the
+        mouse button to make the connection.
+    \endtable
+
+    The \gui{Configure Connection} dialog (below) is displayed, showing signals
+    from the source object and slots from the destination object that you can
+    use.
+
+    \image designer-connection-dialog.png
+
+    To complete the connection, select a signal from the source object and a
+    slot from the destination object, then click \key OK. Click \key Cancel if
+    you wish to abandon the connection.
+
+    \note If the \gui{Show all signals and slots} checkbox is selected, all
+    available signals from the source object will be shown. Otherwise, the
+    signals and slots inherited from QWidget will be hidden.
+
+    You can make as many connections as you like between objects on the form;
+    it is possible to connect signals from objects to slots in the form itself.
+    As a result, the signal and slot connections in many dialogs can be
+    completely configured from within \QD.
+
+    \target ConnectingToTheForm
+    \table
+        \row
+            \i  \inlineimage designer-connection-to-form.png
+            \i  \bold{Connecting to a Form}
+
+        To connect an object to the form itself, simply position the cursor
+        over the form and release the mouse button. The end point of the
+        connection changes to the electrical "ground" symbol.
+    \endtable
+
+
+    \section1 Editing and Deleting Connections
+
+    By default, connection paths are created with two labels that show the
+    signal and slot involved in the connection. These labels are usually
+    oriented along the line of the connection. You can move them around inside
+    their host widgets by dragging the red square at each end of the connection
+    path.
+
+    \target ConnectionEditor
+    \table
+        \row
+            \i  \inlineimage designer-connection-editor.png
+            \i  \bold{The Signal/Slot Editor}
+
+        The signal and slot used in a connection can be changed after it has
+        been set up. When a connection is configured, it becomes visible in
+        \QD's signal and slot editor where it can be further edited. You can
+        also edit signal/slot connections by double-clicking on the connection
+        path or one of its labels to display the Connection Dialog.
+    \endtable
+
+    \target DeletingConnections
+    \table
+        \row
+            \i  \inlineimage designer-connection-editing.png
+            \i  \bold{Deleting Connections}
+
+        The whole connection can be selected by clicking on any of its path
+        segments. Once selected, a connection can be deleted with the
+        \key Delete key, ensuring that it will not be set up in the UI
+        file.
+    \endtable
+*/
+
+
+/*!
+    \page designer-buddy-mode.html
+    \contentspage{Qt Designer Manual}{Contents}
+    \previouspage Qt Designer's Signals and Slots Editing Mode
+    \nextpage Qt Designer's Tab Order Editing Mode
+
+    \title Qt Designer's Buddy Editing Mode
+
+    \image designer-buddy-mode.png
+
+    One of the most useful basic features of Qt is the support for buddy
+    widgets. A buddy widget accepts the input focus on behalf of a QLabel when
+    the user types the label's shortcut key combination. The buddy concept is
+    also used in Qt's \l{Model/View Programming}{model/view} framework.
+
+
+    \section1 Linking Labels to Buddy Widgets
+
+    To enter buddy editing mode, open the \gui Edit menu and select
+    \gui{Edit Buddies}. This mode presents the widgets on the form in a similar
+    way to \l{Qt Designer's Signals and Slots Editing Mode}{signals and slots
+    editing mode} but in this mode, connections must start at label widgets.
+    Ideally, you should connect each label widget that provides a shortcut with
+    a suitable input widget, such as a QLineEdit.
+
+
+    \target MakingBuddies
+    \table
+        \row
+            \i  \inlineimage designer-buddy-making.png
+            \i  \bold{Making Buddies}
+
+        To define a buddy widget for a label, click on the label, drag the
+        connection to another widget on the form, and release the mouse button.
+        The connection shown indicates how input focus is passed to the buddy
+        widget. You can use the form preview to test the connections between
+        each label and its buddy.
+    \endtable
+
+
+    \section1 Removing Buddy Connections
+
+    Only one buddy widget can be defined for each label. To change the buddy
+    used, it is necessary to delete any existing buddy connection before you
+    create a new one.
+
+    Connections between labels and their buddy widgets can be deleted in the
+    same way as signal-slot connections in signals and slots editing mode:
+    Select the buddy connection by clicking on it and press the \key Delete
+    key. This operation does not modify either the label or its buddy in any
+    way.
+*/
+
+
+/*!
+    \page designer-tab-order.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Qt Designer's Buddy Editing Mode
+    \nextpage Using Containers in Qt Designer
+
+    \title Qt Designer's Tab Order Editing Mode
+
+    \image designer-tab-order-mode.png
+
+    Many users expect to be able to navigate between widgets and controls
+    using only the keyboard. Qt lets the user navigate between input widgets
+    with the \key Tab and \key{Shift+Tab} keyboard shortcuts. The default
+    \e{tab order} is based on the order in which widgets are constructed.
+    Although this order may be sufficient for many users, it is often better
+    to explicitly specify the tab order to make your application easier to
+    use.
+
+
+    \section1 Setting the Tab Order
+
+    To enter tab order editing mode, open the \gui Edit menu and select
+    \gui{Edit Tab Order}. In this mode, each input widget in the form is shown
+    with a number indicating its position in the tab order. So, if the user
+    gives the first input widget the input focus and then presses the tab key,
+    the focus will move to the second input widget, and so on.
+
+    The tab order is defined by clicking on each of the numbers in the correct
+    order. The first number you click will change to red, indicating the
+    currently edited position in the tab order chain. The widget associated
+    with the number will become the first one in the tab order chain. Clicking
+    on another widget will make it the second in the tab order, and so on.
+
+    Repeat this process until you are satisfied with the tab order in the form
+    -- you do not need to click every input widget if you see that the
+    remaining widgets are already in the correct order. Numbers, for which you
+    already set the order, change to green, while those which are not clicked
+    yet, remain blue.
+
+    If you make a mistake, simply double click outside of any number or choose
+    \gui{Restart} from the form's context menu to start again. If you have many
+    widgets on your form and would like to change the tab order in the middle or
+    at the end of the tab order chain, you can edit it at any position. Press
+    \key{Ctrl} and click the number from which you want to start.
+    Alternatively, choose \gui{Start from Here} in the context menu.
+
+*/
+
+
+/*!
+    \page designer-using-containers.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Qt Designer's Tab Order Editing Mode
+    \nextpage Creating Main Windows in Qt Designer
+
+
+    \title Using Containers in Qt Designer
+
+    Container widgets provide high level control over groups of objects on a
+    form. They can be used to perform a variety of functions, such as managing
+    input widgets, providing paged and tabbed layouts, or just acting as
+    decorative containers for other objects.
+
+    \image designer-widget-morph.png
+
+    \QD provides visual feedback to help you place objects inside your
+    containers. When you drag an object from the widget box (or elsewhere) on
+    the form, each container will be highlighted when the cursor is positioned
+    over it. This indicates that you can drop the object inside, making it a
+    child object of the container. This feedback is important because it is
+    easy to place objects close to containers without actually placing them
+    inside. Both widgets and spacers can be used inside containers.
+
+    Stacked widgets, tab widgets, and toolboxes are handled specially in \QD.
+    Normally, when adding pages (tabs, pages, compartments) to these containers
+    in your own code, you need to supply existing widgets, either as
+    placeholders or containing child widgets. In \QD, these are automatically
+    created for you, so you can add child objects to each page straight away.
+
+    Each container typically allows its child objects to be arranged in one or
+    more layouts. The type of layout management provided depends on each
+    container, although setting the layout is usually just a matter of
+    selecting the container by clicking it, and applying a layout. The table
+    below shows a list of available containers.
+
+    \table
+        \row
+            \i  \inlineimage designer-containers-frame.png
+            \i  \bold Frames
+
+        Frames are used to enclose and group widgets, as well as to provide
+        decoration. They are used as the foundation for more complex
+        containers, but they can also be used as placeholders in forms.
+
+        The most important properties of frames are \c frameShape,
+        \c frameShadow, \c lineWidth, and \c midLineWidth. These are described
+        in more detail in the QFrame class description.
+
+        \row
+            \i  \inlineimage designer-containers-groupbox.png
+            \i  \bold{Group Boxes}
+
+        Group boxes are usually used to group together collections of
+        checkboxes and radio buttons with similar purposes.
+
+        Among the significant properties of group boxes are \c title, \c flat,
+        \c checkable, and \c checked. These are demonstrated in the
+        \l{widgets/groupbox}{Group Box} example, and described in the QGroupBox
+        class documentation. Each group box can contain its own layout, and
+        this is necessary if it contains other widgets. To add a layout to the
+        group box, click inside it and apply the layout as usual.
+
+        \row
+            \i  \inlineimage designer-containers-stackedwidget.png
+            \i  \bold{Stacked Widgets}
+
+        Stacked widgets are collections of widgets in which only the topmost
+        layer is visible. Control over the visible layer is usually managed by
+        another widget, such as combobox, using signals and slots.
+
+        \QD shows arrows in the top-right corner of the stack to allow you to
+        see all the widgets in the stack when designing it. These arrows do not
+        appear in the preview or in the final component. To navigate between
+        pages in the stack, select the stacked widget and use the
+        \gui{Next Page} and \gui{Previous Page} entries from the context menu.
+        The \gui{Insert Page} and \gui{Delete Page} context menu options allow
+        you to add and remove pages.
+
+        \row
+            \i  \inlineimage designer-containers-tabwidget.png
+            \i  \bold{Tab Widgets}
+
+        Tab widgets allow the developer to split up the contents of a widget
+        into different labelled sections, only one of which is displayed at any
+        given time. By default, the tab widget contains two tabs, and these can
+        be deleted or renamed as required. You can also add additional tabs.
+
+        To delete a tab:
+        \list
+            \o  Click on its label to make it the current tab.
+            \o  Select the tab widget and open its context menu.
+            \o  Select \gui{Delete Page}.
+        \endlist
+
+        To add a new tab:
+        \list
+            \o  Select the tab widget and open its context menu.
+            \o  Select \gui{Insert Page}.
+            \o  You can add a page before or after the \e current page. \QD
+                will create a new widget for that particular tab and insert it
+                into the tab widget.
+            \o  You can set the title of the current tab by changing the
+                \c currentTabText property in the \gui{Property Editor}.
+        \endlist
+
+        \row
+            \i  \inlineimage designer-containers-toolbox.png
+            \i  \bold{ToolBox Widgets}
+
+        Toolbox widgets provide a series of pages or compartments in a toolbox.
+        They are handled in a way similar to stacked widgets.
+
+        To rename a page in a toolbox, make the toolbox your current pange and
+        change its \c currentItemText property from the \gui{Property Editor}.
+
+        To add a new page, select \gui{Insert Page} from the toolbox widget's
+        context menu. You can add the page before or after the current page.
+
+        To delete a page, select \gui{Delete Page} from the toolbox widget's
+        context menu.
+
+        \row
+            \i  \inlineimage designer-containers-dockwidget.png
+            \i  \bold{Dock Widgets}
+
+        Dock widgets are floating panels, often containing input widgets and
+        more complex controls, that are either attached to the edges of the
+        main window in "dock areas", or floated as independent tool windows.
+
+        Although dock widgets can be added to any type of form, they are
+        typically used with forms created from the
+        \l{Creating Main Windows in Qt Designer}{main window template}.
+
+    \endtable
+*/
+
+
+/*!
+    \page designer-creating-mainwindows.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Using Containers in Qt Designer
+    \nextpage Editing Resources with Qt Designer
+
+    \title Creating Main Windows in Qt Designer
+
+    \QD can be used to create user interfaces for different purposes, and
+    it provides different kinds of form templates for each user interface. The
+    main window template is used to create application windows with menu bars,
+    toolbars, and dock widgets.
+
+    \omit
+    \image designer-mainwindow-example.png
+    \endomit
+
+    Create a new main window by opening the \gui File menu and selecting the
+    \gui{New Form...} option, or by pressing \key{Ctrl+N}. Then, select the
+    \gui{Main Window} template. This template provides a main application
+    window containing a menu bar and a toolbar by default -- these can be
+    removed if they are not required.
+
+    If you remove the menu bar, a new one can be created by selecting the
+    \gui{Create Menu Bar} option from the context menu, obtained by
+    right-clicking within the main window form.
+
+    An application can have only \bold one menu bar, but \bold several
+    toolbars.
+
+
+    \section1 Menus
+
+    Menus are added to the menu bar by modifying the \gui{Type Here}
+    placeholders. One of these is always present for editing purposes, and
+    will not be displayed in the preview or in the finished window.
+
+    Once created, the properties of a menu can be accessed using the
+    \l{Qt Designer's Widget Editing Mode#The Property Editor}{Property Editor},
+    and each menu can be accessed for this purpose via the
+    \l{Qt Designer's Widget Editing Mode#The Object Inspector}{The Object Inspector}.
+
+    Existing menus can be removed by opening a context menu over the label in
+    the menu bar, and selecting \gui{Remove Menu 'menu_name'}.
+
+
+    \target CreatingAMenu
+    \table
+        \row
+            \i  \inlineimage designer-creating-menu1.png
+            \i  \inlineimage designer-creating-menu2.png
+            \i  \bold{Creating a Menu}
+
+        Double-click the placeholder item to begin editing. The menu text,
+        displayed using a line edit, can be modified.
+
+        \row
+            \i  \inlineimage designer-creating-menu3.png
+            \i  \inlineimage designer-creating-menu4.png
+            \i  Insert the required text for the new menu. Inserting an
+                ampersand character (&) causes the letter following it to be
+                used as a mnemonic for the menu.
+
+        Press \key Return or \key Enter to accept the new text, or press
+        \key Escape to reject it. You can undo the editing operation later if
+        required.
+    \endtable
+
+    Menus can also be rearranged in the menu bar simply by dragging and
+    dropping them in the preferred location. A vertical red line indicates the
+    position where the menu will be inserted.
+
+    Menus can contain any number of entries and separators, and can be nested
+    to the required depth. Adding new entries to menus can be achieved by
+    navigating the menu structure in the usual way.
+
+    \target CreatingAMenuEntry
+    \table
+        \row
+            \i  \inlineimage designer-creating-menu-entry1.png
+            \i  \inlineimage designer-creating-menu-entry2.png
+            \i  \bold{Creating a Menu Entry}
+
+        Double-click the \gui{new action} placeholder to begin editing, or
+        double-click \gui{new separator} to insert a new separator line after
+        the last entry in the menu.
+
+        The menu entry's text is displayed using a line edit, and can be
+        modified.
+
+        \row
+            \i  \inlineimage designer-creating-menu-entry3.png
+            \i  \inlineimage designer-creating-menu-entry4.png
+            \i  Insert the required text for the new entry, optionally using
+                the ampersand character (&) to mark the letter to use as a
+                mnemonic for the entry.
+
+        Press \key Return or \key Enter to accept the new text, or press
+        \key Escape to reject it. The action created for this menu entry will
+        be accessible via the \l{#TheActionEditor}{Action Editor}, and any
+        associated keyboard shortcut can be set there.
+    \endtable
+
+    Just like with menus, entries can be moved around simply by dragging and
+    dropping them in the preferred location. When an entry is dragged over a
+    closed menu, the menu will open to allow it to be inserted there. Since
+    menu entries are based on actions, they can also be dropped onto toolbars,
+    where they will be displayed as toolbar buttons.
+
+
+    \section1 Toolbars
+
+
+    ### SCREENSHOT
+
+    Toolbars ared added to a main window in a similar way to the menu bar:
+    Select the \gui{Add Tool Bar} option from the form's context menu.
+    Alternatively, if there is an existing toolbar in the main window, you can
+    click the arrow on its right end to create a new toolbar.
+
+    Toolbar buttons are created using the action system to populate each
+    toolbar, rather than by using specific button widgets from the widget box.
+    Since actions can be represented by menu entries and toolbar buttons, they
+    can be moved between menus and toolbars. To share an action between a menu
+    and a toolbar, drag its icon from the \l{#TheActionEditor}{Action Editor}
+    to the toolbar rather than from the menu where its entry is located.
+
+    New actions for menus and toolbars can be created in the
+    \l{#TheActionEditor}{Action Editor}.
+
+
+    \section1 Actions
+
+    With the menu bar and the toolbars in place, it's time to populate them
+    with action: \QD provides an action editor to simplify the creation and
+    management of actions.
+
+
+    \target TheActionEditor
+    \table
+        \row
+            \i  \inlineimage designer-action-editor.png
+            \i  \bold{The Action Editor}
+
+        Enable the action editor by opening the \gui Tools menu, and switching
+        on the \gui{Action Editor} option.
+
+        The action editor allows you to create \gui New actions and \gui Delete
+        actions. It also provides a search function, \gui Filter, using the
+        action's text.
+
+        \QD's action editor can be viewed in the classic \gui{Icon View} and
+        \gui{Detailed View}. The screenshot below shows the action editor in
+        \gui{Detailed View}. You can also copy and paste actions between menus,
+        toolbars and forms.
+    \endtable
+
+    To create an action, use the action editor's \gui New button, which will
+    then pop up an input dialog. Provide the new action with a \gui Text --
+    this is the text that will appear in a menu entry and as the action's
+    tooltip. The text is also automatically added to an "action" prefix,
+    creating the action's \gui{Object Name}.
+
+    In addition, the dialog provides the option of selecting an \gui Icon for
+    the action, as well as removing the current icon.
+
+    Once the action is created, it can be used wherever actions are applicable.
+
+
+    \target AddingAnAction
+    \table
+        \row
+            \i  \inlineimage designer-adding-menu-action.png
+            \i  \inlineimage designer-adding-toolbar-action.png
+            \i  \bold{Adding an Action}
+
+        To add an action to a menu or a toolbar, simply press the left mouse
+        button over the action in the action editor, and drag it to the
+        preferred location.
+
+        \QD provides highlighted guide lines that tell you where the action
+        will be added. Release the mouse button to add the action when you have
+        found the right spot.
+    \endtable
+
+
+    \section1 Dock Widgets
+
+    Since dock widgets are \l{Using Containers in Qt Designer}
+    {container widgets}, they can be added to a form in the usuasl way. Once
+    added to a form, dock widgets are not placed in any particular dock area by
+    default; you need to set the \gui{docked} property to true for each widget
+    and choose an appropriate value for its \gui{dockWidgetArea} property.
+
+    \target AddingADockWidget
+    \table
+        \row
+            \i  \inlineimage designer-adding-dockwidget.png
+            \i  \bold{Adding a Dock Widget}
+
+        To add a dock widget, simply drag one from the \gui Containers section
+        of the widget box, and drop it onto the main form area. Just like other
+        widgets, its properties can be modified with the \gui{Property Editor}.
+
+        Dock widgets can be optionally floated as indpendent tool windows.
+        Hence, it is useful to give them window titles by setting their
+        \gui{windowTitle} property. This also helps to identify them on the
+        form.
+
+    \endtable
+*/
+
+
+/*!
+    \page designer-resources.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Creating Main Windows in Qt Designer
+    \nextpage Using Stylesheets with Qt Designer
+
+    \title Editing Resources with Qt Designer
+
+    \image designer-resources-editing.png
+
+    \QD fully supports the \l{The Qt Resource System}{Qt Resource System},
+    enabling resources to be specified together with forms as they are
+    designed. To aid designers and developers manage resources for their
+    applications, \QD's resource editor allows resources to be defined on a
+    per-form basis. In other words, each form can have a separate resource
+    file.
+
+    \section1 Defining a Resource File
+
+    To specify a resource file you must enable the resource editor by opening
+    the \gui Tools menu, and switching on the \gui{Resource Browser} option.
+
+    \target ResourceFiles
+    \table
+        \row
+            \i  \inlineimage designer-resource-browser.png
+            \i  \bold{Resource Files}
+
+        Within the resource browser, you can open existing resource files or
+        create new ones. Click the \gui{Edit Resources} button
+        \inlineimage designer-edit-resources-button.png
+         to edit your resources. To reload resources, click on the \gui Reload
+        button
+        \inlineimage designer-reload-resources-button.png
+        .
+    \endtable
+
+
+    Once a resource file is loaded, you can create or remove entries in it
+    using the given \gui{Add Files}
+    \inlineimage designer-add-resource-entry-button.png
+    and \gui{Remove Files}
+    \inlineimage designer-remove-resource-entry-button.png
+     buttons, and specify resources (e.g., images) using the \gui{Add Files}
+    button
+    \inlineimage designer-add-files-button.png
+    . Note that these resources must reside within the current resource file's
+    directory or one of its subdirectories.
+
+
+    \target EditResource
+    \table
+        \row
+            \i  \inlineimage designer-edit-resource.png
+            \i  \bold{Editing Resource Files}
+
+        Press the
+        \inlineimage designer-add-resource-entry-button.png
+         button to add a new resource entry to the file. Then use the
+        \gui{Add Files} button
+        \inlineimage designer-add-files-button.png
+         to specify the resource.
+
+        You can remove resources by selecting the corresponding entry in the
+        resource editor, and pressing the
+        \inlineimage designer-remove-resource-entry-button.png
+         button.
+    \endtable
+
+
+    \section1 Using the Resources
+
+    Once the resources are defined you can use them actively when composing
+    your form. For example, you might want to create a tool button using an
+    icon specified in the resource file.
+
+    \target UsingResources
+    \table
+        \row
+            \i  \inlineimage designer-resources-using.png
+            \i  \bold{Using Resources}
+
+        When changing properties with values that may be defined within a
+        resource file, \QD's property editor allows you to specify a resource
+        in addition to the option of selecting a source file in the ordinary
+        way.
+
+        \row
+            \i  \inlineimage designer-resource-selector.png
+            \i  \bold{Selecting a Resource}
+
+        You can open the resource selector by clicking \gui{Choose Resource...}
+        to add resources any time during the design process.
+
+\omit
+... check with Friedemann
+To quickly assign icon pixmaps to actions or pixmap properties, you may
+drag the pixmap from the resource editor to the action editor, or to the
+pixmap property in the property editor.
+\endomit
+
+    \endtable
+*/
+
+
+/*!
+    \page designer-stylesheet.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Editing Resources with Qt Designer
+    \nextpage Using a Designer UI File in Your Application
+
+    \title Using Stylesheets with Qt Designer
+
+    Since Qt 4.2, it is possible to edit stylesheets in \QD with the stylesheet
+    editor.
+
+    \target UsingStylesheets
+    \table
+        \row
+            \i \inlineimage designer-stylesheet-options.png
+            \bold{Setting a Stylesheet}
+
+            The stylesheet editor can be accessed by right-clicking a widget
+            and selecting \gui{Change styleSheet...}
+
+        \row
+            \i \inlineimage designer-stylesheet-usage.png
+    \endtable
+
+*/
+
+
+/*!
+    \page designer-using-a-ui-file.html
+    \previouspage Using Stylesheets with Qt Designer
+    \contentspage {Qt Designer Manual}{Contents}
+    \nextpage Using Custom Widgets with Qt Designer
+
+    \title Using a Designer UI File in Your Application
+
+    With Qt's integrated build tools, \l{qmake Manual}{qmake} and \l uic, the
+    code for user interface components created with \QD is automatically
+    generated when the rest of your application is built. Forms can be included
+    and used directly from your application. Alternatively, you can use them to
+    extend subclasses of standard widgets. These forms can be processed at
+    compile time or at run time, depending on the approach used.
+
+
+    \tableofcontents
+    \section1 Compile Time Form Processing
+
+    A compile time processed form can be used in your application with one of
+    the following approaches:
+
+    \list
+        \o  The Direct Approach: you construct a widget to use as a placeholder
+            for the component, and set up the user interface inside it.
+        \o  The Single Inheritance Approach: you subclass the form's base class
+            (QWidget or QDialog, for example), and include a private instance
+            of the form's user interface object.
+        \o  The MultipleInheritance Approach: you subclass both the form's base
+            class and the form's user interface object. This allows the widgets
+            defined in the form to be used directly from within the scope of
+            the subclass.
+    \endlist
+
+
+    \section2 The Direct Approach
+
+    To demonstrate how to use user interface (UI) files straight from
+    \QD, we create a simple Calculator Form application. This is based on the
+    original \l{Calculator Form Example}{Calculator Form} example.
+
+    The application consists of one source file, \c main.cpp and a UI
+    file.
+
+    The \c{calculatorform.ui} file designed with \QD is shown below:
+
+    \image directapproach-calculatorform.png
+
+    We will use \c qmake to build the executable, so we need to write a
+    \c{.pro} file:
+
+    \snippet doc/src/snippets/uitools/calculatorform/calculatorform.pro 0
+
+    The special feature of this file is the \c FORMS declaration that tells
+    \c qmake which files to process with \c uic. In this case, the
+    \c calculatorform.ui file is used to create a \c ui_calculatorform.h file
+    that can be used by any file listed in the \c SOURCES declaration. To
+    ensure that \c qmake generates the \c ui_calculatorform.h file, we need to
+    include it in a file listed in \c SOURCES. Since we only have \c main.cpp,
+    we include it there:
+
+    \snippet doc/src/snippets/uitools/calculatorform/main.cpp 0
+
+    This include is an additional check to ensure that we do not generate code
+    for UI files that are not used.
+
+    The \c main function creates the calculator widget by constructing a
+    standard QWidget that we use to host the user interface described by the
+    \c calculatorform.ui file.
+
+    \snippet doc/src/snippets/uitools/calculatorform/main.cpp 1
+
+    In this case, the \c{Ui::CalculatorForm} is an interface description object
+    from the \c ui_calculatorform.h file that sets up all the dialog's widgets
+    and the connections between its signals and slots.
+
+    This approach provides a quick and easy way to use simple, self-contained
+    components in your applications, but many componens created with \QD will
+    require close integration with the rest of the application code. For
+    instance, the \c CalculatorForm code provided above will compile and run,
+    but the QSpinBox objects will not interact with the QLabel as we need a
+    custom slot to carry out the add operation and display the result in the
+    QLabel. To achieve this, we need to subclass a standard Qt widget (known as
+    the single inheritance approach).
+
+
+    \section2 The Single Inheritance Approach
+
+    In this approach, we subclass a Qt widget and set up the user interface
+    from within the constructor. Components used in this way expose the widgets
+    and layouts used in the form to the Qt widget subclass, and provide a
+    standard system for making signal and slot connections between the user
+    interface and other objects in your application.
+
+    This approach is used in the \l{Calculator Form Example}{Calculator Form}
+    example.
+
+    To ensure that we can use the user interface, we need to include the header
+    file that \c uic generates before referring to \c{Ui::CalculatorForm}:
+
+    \snippet examples/designer/calculatorform/calculatorform.h 0
+
+    This means that the \c{.pro} file must be updated to include
+    \c{calculatorform.h}:
+
+    \snippet examples/designer/calculatorform/calculatorform.pro 0
+
+    The subclass is defined in the following way:
+
+    \snippet examples/designer/calculatorform/calculatorform.h 1
+
+    The important feature of the class is the private \c ui object which
+    provides the code for setting up and managing the user interface.
+
+    The constructor for the subclass constructs and configures all the widgets
+    and layouts for the dialog just by calling the \c ui object's \c setupUi()
+    function. Once this has been done, it is possible to modify the user
+    interface as needed.
+
+    \snippet examples/designer/calculatorform/calculatorform.cpp 0
+
+    We can connect signals and slots in user interface widgets in the usual
+    way, taking care to prefix the \c ui object to each widget used.
+
+    The advantages of this approach are its simple use of inheritance to
+    provide a QWidget-based interface, and its encapsulation of the user
+    interface widget variables within the \c ui data member. We can use this
+    method to define a number of user interfaces within the same widget, each
+    of which is contained within its own namespace, and overlay (or compose)
+    them. This approach can be used to create individual tabs from existing
+    forms, for example.
+
+
+    \section2 The Multiple Inheritance Approach
+
+    Forms created with \QD can be subclassed together with a standard
+    QWidget-based class. This approach makes all the user interface components
+    defined in the form directly accessible within the scope of the subclass,
+    and enables signal and slot connections to be made in the usual way with
+    the \l{QObject::connect()}{connect()} function.
+
+    This approach is used in the \l{Multiple Inheritance Example}
+    {Multiple Inheritance} example.
+
+    We need to include the header file that \c uic generates from the
+    \c calculatorform.ui file:
+
+    \snippet examples/uitools/multipleinheritance/calculatorform.h 0
+
+    The class is defined in a similar way to the one used in the
+    \l{The Single Inheritance Approach}{single inheritance approach}, except that
+    this time we inherit from \e{both} QWidget and \c{Ui::CalculatorForm}:
+
+    \snippet examples/uitools/multipleinheritance/calculatorform.h 1
+
+    We inherit \c{Ui::CalculatorForm} privately to ensure that the user
+    interface objects are private in our subclass. We can also inherit it with
+    the \c public or \c protected keywords in the same way that we could have
+    made \c ui public or protected in the previous case.
+
+    The constructor for the subclass performs many of the same tasks as the
+    constructor used in the \l{The Single Inheritance Approach}
+    {single inheritance} example:
+
+    \snippet examples/uitools/multipleinheritance/calculatorform.cpp 0
+
+    In this case, the widgets used in the user interface can be accessed in the
+    same say as a widget created in code by hand. We no longer require the
+    \c{ui} prefix to access them.
+
+    Subclassing using multiple inheritance gives us more direct access to the
+    contents of the form, is slightly cleaner than the single inheritance
+    approach, but does not conveniently support composition of multiple user
+    interfaces.
+
+
+    \section1 Run Time Form Processing
+
+    Alternatively, forms can be processed at run time, producing dynamically-
+    generated user interfaces. This can be done using the QtUiTools module
+    that provides the QUiLoader class to handle forms created with \QD.
+
+
+    \section2 The UiTools Approach
+
+    A resource file containing a UI file is required to process forms at
+    run time. Also, the application needs to be configured to use the QtUiTools
+    module. This is done by including the following declaration in a \c qmake
+    project file, ensuring that the application is compiled and linked
+    appropriately.
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 0
+
+    The QUiLoader class provides a form loader object to construct the user
+    interface. This user interface can be retrieved from any QIODevice, e.g.,
+    a QFile object, to obtain a form stored in a project's resource file. The
+    QUiLoader::load() function constructs the form widget using the user
+    interface description contained in the file.
+
+    The QtUiTools module classes can be included using the following directive:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 1
+
+    The QUiLoader::load() function is invoked as shown in this code from the
+    \l{Text Finder Example}{Text Finder} example:
+
+    \snippet examples/uitools/textfinder/textfinder.cpp 4
+
+    In a class that uses QtUiTools to build its user interface at run time, we
+    can locate objects in the form using qFindChild(). For example, in the
+    follownig code, we locate some components based on their object names and
+    widget types:
+
+    \snippet examples/uitools/textfinder/textfinder.cpp 1
+
+    Processing forms at run-time gives the developer the freedom to change a
+    program's user interface, just by changing the UI file. This is useful
+    when customizing programs to suit various user needs, such as extra large
+    icons or a different colour scheme for accessibility support.
+
+
+    \section1 Automatic Connections
+
+    The signals and slots connections defined for compile time or run time
+    forms can either be set up manually or automatically, using QMetaObject's
+    ability to make connections between signals and suitably-named slots.
+
+    Generally, in a QDialog, if we want to process the information entered by
+    the user before accepting it, we need to connect the clicked() signal from
+    the \gui OK button to a custom slot in our dialog. We will first show an
+    example of the dialog in which the slot is connected by hand then compare
+    it with a dialog that uses automatic connection.
+
+
+    \section2 A Dialog Without Auto-Connect
+
+    We define the dialog in the same way as before, but now include a slot in
+    addition to the constructor:
+
+    \snippet doc/src/snippets/designer/noautoconnection/imagedialog.h 0
+
+    The \c checkValues() slot will be used to validate the values provided by
+    the user.
+
+    In the dialog's constructor we set up the widgets as before, and connect
+    the \gui Cancel button's \l{QPushButton::clicked()}{clicked()} signal to
+    the dialog's reject() slot. We also disable the
+    \l{QPushButton::autoDefault}{autoDefault} property in both buttons to
+    ensure that the dialog does not interfere with the way that the line edit
+    handles return key events:
+
+    \snippet doc/src/snippets/designer/noautoconnection/imagedialog.cpp 0
+    \dots
+    \snippet doc/src/snippets/designer/noautoconnection/imagedialog.cpp 1
+
+    We connect the \gui OK button's \l{QPushButton::clicked()}{clicked()}
+    signal to the dialog's checkValues() slot which we implement as follows:
+
+    \snippet doc/src/snippets/designer/noautoconnection/imagedialog.cpp 2
+
+    This custom slot does the minimum necessary to ensure that the data
+    entered by the user is valid - it only accepts the input if a name was
+    given for the image.
+
+    \section2 Widgets and Dialogs with Auto-Connect
+
+    Although it is easy to implement a custom slot in the dialog and connect
+    it in the constructor, we could instead use QMetaObject's auto-connection
+    facilities to connect the \gui OK button's clicked() signal to a slot in
+    our subclass. \c{uic} automatically generates code in the dialog's
+    \c setupUi() function to do this, so we only need to declare and
+    implement a slot with a name that follows a standard convention:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 2
+
+    Using this convention, we can define and implement a slot that responds to
+    mouse clicks on the \gui OK button:
+
+    \snippet doc/src/snippets/designer/autoconnection/imagedialog.h 0
+
+    Another example of automatic signal and slot connection would be the
+    \l{Text Finder Example}{Text Finder} with its \c{on_findButton_clicked()}
+    slot.
+
+    We use QMetaObject's system to enable signal and slot connections:
+
+    \snippet examples/uitools/textfinder/textfinder.cpp 2
+
+    This enables us to implement the slot, as shown below:
+
+    \snippet examples/uitools/textfinder/textfinder.cpp 6
+    \dots
+    \snippet examples/uitools/textfinder/textfinder.cpp 8
+
+    Automatic connection of signals and slots provides both a standard naming
+    convention and an explicit interface for widget designers to work to. By
+    providing source code that implements a given interface, user interface
+    designers can check that their designs actually work without having to
+    write code themselves.
+*/
+
+
+/*!
+    \page designer-customizing-forms.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Using Stylesheets with Qt Designer
+    \nextpage Using Custom Widgets with Qt Designer
+
+    \title Customizing Qt Designer Forms
+
+    \image designer-form-settings.png
+
+    When saving a form in \QD, it is stored as a UI file. Several form
+    settings, for example the grid settings or the margin and spacing for the
+    default layout, are stored along with the form's components. These settings
+    are used when the \l uic generates the form's C++ code. For more
+    information on how to use forms in your application, see the
+    \l{Using a Designer UI File in Your Application} section.
+
+
+    \section1 Modifying the Form Settings
+
+    To modify the form settings, open the \gui Form menu and select \gui{Form
+    Settings...}
+
+    In the forms settings dialog you can specify the \gui Author of the form.
+
+    You can also alter the margin and spacing properties for the form's default
+    layout (\gui {Layout Default}). These default layout properties will be
+    replaced by the corresponding \gui {Layout Function}, if the function is
+    specified, when \c uic generates code for the form. The form settings
+    dialog lets you specify functions for both the margin and the spacing.
+
+    \target LayoutFunction
+    \table
+    \row
+    \i \inlineimage designer-form-layoutfunction.png
+    \i \bold{Layout Function}
+
+    The default layout properties will be replaced by the corresponding
+    \gui{Layout Function}, when \c uic generates code for the form. This is
+    useful when different environments requires different layouts for the same
+    form.
+
+    To specify layout functions for the form's margin and spacing, check the
+    \gui{Layout Function} group box to enable the line edits.
+    \endtable
+
+    You can also specify the form's \gui{Include Hints}; i.e., provide a list
+    of the header files which will then be included in the form window's
+    associated UI file. Header files may be local, i.e., relative to the
+    project's directory, \c "mywidget.h", or global, i.e. part of Qt or the
+    compilers standard libraries: \c <QtGui/QWidget>.
+
+    Finally, you can specify the function used to load pixmaps into the form
+    window (the \gui {Pixmap Function}).
+*/
+
+
+/*!
+    \page designer-using-custom-widgets.html
+    \contentspage {Qt Designer Manual}{Contents}
+    \previouspage Customizing Qt Designer Forms
+    \nextpage Creating Custom Widgets for Qt Designer
+
+    \title Using Custom Widgets with Qt Designer
+
+    \QD can display custom widgets through its extensible plugin mechanism,
+    allowing the range of designable widgets to be extended by the user and
+    third parties. This feature also allows \QD to optionally support
+    \l{Qt3Support}{Qt 3 compatibility widgets}. Alternatively, it is possible
+    to use existing widgets as placeholders for widget classes that provide
+    similar APIs.
+
+    Widgets from the Qt3Support library are made available via in \QD's support
+    for custom widgets.
+
+
+    \section1 Handling Custom Widgets
+
+    Although \QD supports all of the standard Qt widgets, and can be configured
+    to handle widgets supplied in the Qt3Support library, some specialized
+    widgets may not be available as standard for a number of reasons:
+
+    \list
+        \i Custom widgets may not be available at the time the user interface
+           is being designed.
+        \i Custom widgets may be platform-specific, and designers may be
+           developing the user interface on a different platform to end users.
+        \i The source code for a custom widget is not available, or the user
+           interface designers are unable to use the widget for non-technical
+           reasons.
+    \endlist
+
+    In the above situations, it is still possible to design forms with the aim
+    of using custom widgets in the application. To achieve this, we can use
+    the widget promotion feature of \QD.
+
+    In all other cases, where the source code to the custom widgets is
+    available, we can adapt the custom widget for use with \QD.
+
+
+    \section2 Promoting Widgets
+
+    \image designer-promoting-widgets.png
+
+    If some forms must be designed, but certain custom widgets are unavailble
+    to the designer, we can substitute similar widgets to represent the missing
+    widgets. For example, we might represent instances of a custom push button
+    class, \c MyPushButton, with instances of QPushButton and promote these to
+    \c MyPushButton so that \l{uic.html}{uic} generates suitable code for this
+    missing class.
+
+    When choosing a widget to use as a placeholder, it is useful to compare the
+    API of the missing widget with those of standard Qt widgets. For
+    specialized widgets that subclass standard classes, the obvious choice of
+    placeholder is the base class of the custom widget; for example, QSlider
+    might be used for specialized QSlider subclasses.
+
+    For specialized widgets that do not share a common API with standard Qt
+    widgets, it is worth considering adapting a custom widget for use in \QD.
+    If this is not possible then QWidget is the obvious choice for a
+    placeholder widget since it is the lowest common denominator for all
+    widgets.
+
+    To add a placeholder, select an object of a suitable base class and choose
+    \gui{Promote to ...} from the form's context menu. After entering the class
+    name and header file in the lower part of the dialog, choose \gui{Add}. The
+    placeholder class will now appear along with the base class in the upper
+    list. Click the \gui{Promote} button to accept this choice.
+
+    Now, when the form's context menu is opened over objects of the base class,
+    the placeholder class will appear in the \gui{Promote to} submenu, allowing
+    for convenient promotion of objects to that class.
+
+    A promoted widget can be reverted to its base class by choosing
+    \gui{Demote to} from the form's context menu.
+
+
+    \section2 User Defined Custom Widgets
+
+    \image worldtimeclockplugin-example.png
+
+    Custom widgets can be adapted for use with \QD, giving designers the
+    opportunity to configure the user interface using the actual widgets that
+    will be used in an application rather than placeholder widgets. The process
+    of creating a custom widget plugin is described in the
+    \l{Creating Custom Widgets for Qt Designer} chapter of this manual.
+
+    To use a plugin created in this way, it is necessary to ensure that the
+    plugin is located on a path that \QD searches for plugins. Generally,
+    plugins stored in \c{$QTDIR/plugins/designer} will be loaded when \QD
+    starts. Further information on building and installing plugins can be found
+    \l{Creating Custom Widgets for Qt Designer#BuildingandInstallingthePlugin}
+    {here}. You can also refer to the \l{How to Create Qt Plugins}
+    {Plugins HOWTO} document for information about creating plugins.
+*/
+
+
+/*!
+    \page designer-creating-custom-widgets.html
+    \previouspage Using Custom Widgets with Qt Designer
+    \contentspage {Qt Designer Manual}{Contents}
+    \nextpage Creating Custom Widget Extensions
+
+    \title Creating Custom Widgets for Qt Designer
+
+    \QD's plugin-based architecture allows user-defined and third party custom
+    widgets to be edited just like you do with standard Qt widgets. All of the
+    custom widget's features are made available to \QD, including widget
+    properties, signals, and slots. Since \QD uses real widgets during the form
+    design process, custom widgets will appear the same as they do when
+    previewed.
+
+    \image worldtimeclockplugin-example.png
+
+    The \l QtDesigner module provides you with the ability to create custom
+    widgets in \QD.
+
+
+    \section1 Getting Started
+
+    To integrate a custom widget with \QD, you require a suitable description
+    for the widget and an appropriate \c{.pro} file.
+
+
+    \section2 Providing an Interface Description
+
+    To inform \QD about the type of widget you want to provide, create a
+    subclass of QDesignerCustomWidgetInterface that describes the various
+    properties your widget exposes. Most of these are supplied by functions
+    that are pure virtual in the base class, because only the author of the
+    plugin can provide this information.
+
+    \table
+        \header
+            \o  Function
+            \o  Description of the return value
+        \row
+            \o  \c name()
+            \o  The name of the class that provides the widget.
+        \row
+            \o  \c group()
+            \o  The group in \QD's widget box that the widget belongs to.
+        \row
+            \o  \c toolTip()
+            \o  A short description to help users identify the widget in \QD.
+        \row
+            \o  \c whatsThis()
+            \o  A longer description of the widget for users of \QD.
+        \row
+            \o  \c includeFile()
+            \o  The header file that must be included in applications that use
+                this widget. This information is stored in UI files and will
+                be used by \c uic to create a suitable \c{#includes} statement
+                in the code it generates for the form containing the custom
+                widget.
+        \row
+            \o  \c icon()
+            \o  An icon that can be used to represent the widget in \QD's
+                widget box.
+        \row
+            \o  \c isContainer()
+            \o  True if the widget will be used to hold child widgets;
+                false otherwise.
+        \row
+            \o  \c createWidget()
+            \o  A QWidget pointer to an instance of the custom widget,
+                constructed with the parent supplied.
+                \note createWidget() is a factory function responsible for
+                creating the widget only. The custom widget's properties will
+                not be available until load() returns.
+        \row
+            \o  \c domXml()
+            \o  A description of the widget's properties, such as its object
+                name, size hint, and other standard QWidget properties.
+        \row
+            \o  \c codeTemplate()
+            \o  This function is reserved for future use by \QD.
+    \endtable
+
+    Two other virtual functions can also be reimplemented:
+
+    \table
+        \row
+            \o  \c initialize()
+            \o  Sets up extensions and other features for custom widgets. Custom
+                container extensions (see QDesignerContainerExtension) and task
+                menu extensions (see QDesignerTaskMenuExtension) should be set
+                up in this function.
+        \row
+            \o  \c isInitialized()
+            \o  Returns true if the widget has been initialized; returns false
+                otherwise. Reimplementations usually check whether the
+                \c initialize() function has been called and return the result
+                of this test.
+    \endtable
+
+
+    \section2 Notes on the \c{domXml()} Function
+
+    The \c{domXml()} function returns a UI file snippet that is used by
+    \QD's widget factory to create a custom widget and its applicable
+    properties.
+
+    Since Qt 4.4, \QD's widget box allows for a complete UI file to
+    describe \bold one custom widget. The UI file can be loaded using the
+    \c{<ui>} tag. Specifying the <ui> tag allows for adding the <customwidget>
+    element that contains additional information for custom widgets. The
+    \c{<widget>} tag is sufficient if no additional information is required
+
+    If the custom widget does not provide a reasonable size hint, it is
+    necessary to specify a default geometry in the string returned by the
+    \c domXml() function in your subclass. For example, the
+    \c AnalogClockPlugin provided by the \l{designer/customwidgetplugin}
+    {Custom Widget Plugin} example, defines a default widgetgeometry in the
+    following way:
+
+    \dots
+    \snippet examples/designer/customwidgetplugin/customwidgetplugin.cpp 11
+    \dots
+
+    An additional feature of the \c domXml() function is that, if it returns
+    an empty string, the widget will not be installed in \QD's widget box.
+    However, it can still be used by other widgets in the form. This feature
+    is used to hide widgets that should not be explicitly created by the user,
+    but are required by other widgets.
+
+    
+    A complete custom widget specification looks like:
+    
+    \code
+<ui language="c++"> displayname="MyWidget">
+    <widget class="widgets::MyWidget" name="mywidget"/>
+    <customwidgets>
+        <customwidget>
+            <class>widgets::MyWidget</class>
+            <addpagemethod>addPage</addpagemethod>
+            <propertyspecifications>
+                <stringpropertyspecification name="fileName" notr="true" type="singleline"
+                <stringpropertyspecification name="text" type="richtext"
+            </propertyspecifications>
+        </customwidget>
+    </customwidgets>
+</ui>
+    \endcode
+
+    Attributes of the \c{<ui>} tag:
+        \table
+        \header
+            \o  Attribute
+            \o  Presence
+            \o  Values
+            \o  Comment
+        \row
+            \o  \c{language}
+            \o  optional
+            \o  "c++", "jambi"
+            \o  This attribute specifies the language the custom widget is intended for.
+                It is mainly there to prevent C++-plugins from appearing in Qt Jambi.
+        \row
+            \o \c{displayname}
+            \o optional
+            \o Class name
+            \o The value of the attribute appears in the Widget box and can be used to
+                strip away namespaces.
+    \endtable
+
+    The \c{<addpagemethod>} tag tells \QD and \l uic which method should be used to
+    add pages to a container widget. This applies to container widgets that require
+    calling a particular method to add a child rather than adding the child by passing
+    the parent. In particular, this is relevant for containers that are not a
+    a subclass of the containers provided in \QD, but are based on the notion
+    of \e{Current Page}. In addition,  you need to provide a container extension
+    for them.
+
+    The \c{<propertyspecifications>} element can contain a list of property meta information.
+    Currently, properties of type string are supported. For these properties, the
+    \c{<stringpropertyspecification>} tag can be used. This tag has the following attributes:
+
+
+    \table
+        \header
+            \o  Attribute
+            \o  Presence
+            \o  Values
+            \o  Comment
+        \row
+            \o  \c{name}
+            \o  required
+            \o  Name of the property
+        \row
+            \o \c{type}
+            \o required
+            \o See below table
+            \o The value of the attribute determines how the property editor will handle them.
+        \row
+            \o \c{notr}
+            \o optional
+            \o "true", "false"
+            \o If the attribute is "true", the value is not meant to be translated.
+    \endtable
+
+    Values of the \c{type} attribute of the string property:
+
+    \table
+        \header
+            \o  Value
+            \o  Type
+        \row
+            \o \c{"richtext"}
+            \o Rich text.
+        \row
+            \o \c{"multiline"}
+            \o Multi-line plain text.
+        \row
+            \o \c{"singleline"}
+            \o Single-line plain text.
+        \row
+            \o \c{"stylesheet"}
+            \o A CSS-style sheet.
+        \row
+            \o \c{"objectname"}
+            \o An object name (restricted set of valid characters).
+        \row
+            \o \c{"url"}
+            \o URL, file name.
+    \endtable
+
+    \section1 Plugin Requirements
+
+    In order for plugins to work correctly on all platforms, you need to ensure
+    that they export the symbols needed by \QD.
+
+    First of all, the plugin class must be exported in order for the plugin to
+    be loaded by \QD. Use the Q_EXPORT_PLUGIN2() macro to do this. Also, the
+    QDESIGNER_WIDGET_EXPORT macro must be used to define each custom widget class
+    within a plugin, that \QD will instantiate.
+
+
+    \section1 Creating Well Behaved Widgets
+
+    Some custom widgets have special user interface features that may make them
+    behave differently to many of the standard widgets found in \QD.
+    Specifically, if a custom widget grabs the keyboard as a result of a call
+    to QWidget::grabKeyboard(), the operation of \QD will be affected.
+
+    To give custom widgets special behavior in \QD, provide an implementation
+    of the initialize() function to configure the widget construction process
+    for \QD specific behavior. This function will be called for the first time
+    before any calls to createWidget() and could perhaps set an internal flag
+    that can be tested later when \QD calls the plugin's createWidget()
+    function.
+
+
+    \target BuildingandInstallingthePlugin
+    \section1 Building and Installing the Plugin
+
+    \section2 A Simple Plugin
+
+    The \l{Custom Widget Plugin Example} demonstrates a simple \QD plugin.
+
+    The \c{.pro} file for a plugin must specify the headers and sources for
+    both the custom widget and the plugin interface. Typically, this file only
+    has to specify that the plugin's project is to be built as a library, but
+    with specific plugin support for \QD. This is done with the following
+    declarations:
+
+    \snippet examples/designer/customwidgetplugin/customwidgetplugin.pro 1
+
+    If Qt is configured to build in both debug and release modes, \QD will be
+    built in release mode. When this occurs, it is necessary to ensure that
+    plugins are also built in release mode. To do this, include the following
+    declaration in the plugin's \c{.pro} file:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 3
+
+    If plugins are built in a mode that is incompatible with \QD, they will
+    not be loaded and installed. For more information about plugins, see the
+    \l{plugins-howto.html}{Plugins HOWTO} document.
+
+    It is also necessary to ensure that the plugin is installed together with
+    other \QD widget plugins:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 4
+
+    The \c $[QT_INSTALL_PLUGINS] variable is a placeholder to the location of
+    the installed Qt plugins. You can configure \QD to look for plugins in
+    other locations by setting the \c QT_PLUGIN_PATH environment variable
+    before running the application.
+
+    \note \QD will look for a \c designer subdirectory in each path supplied.
+
+    See QCoreApplication::libraryPaths() for more information about customizing
+    paths for libraries and plugins with Qt applications.
+
+    \section2 Splitting up the Plugin
+
+    In a real world scenario, you do not want to have dependencies of the
+    application making use of the custom widgets to the \QD headers and
+    libraries as introduced by the simple approach explained above.
+
+    There are two ways to resolve this:
+
+    \list
+        \i Create a \c{.pri} file that contains the headers sources and sources
+           of the custom widget:
+
+           \code
+           INCLUDEPATH += $$PWD
+           HEADERS += $$PWD/analogclock.h
+           SOURCES += $$PWD/analogclock.cpp
+           \endcode
+
+           This file would then be included by the \c{.pro} file of the plugin and
+           the application:
+
+           \code
+           include(customwidget.pri)
+           \endcode
+
+           Running \c{qmake -Wall} on the \c{.pro} files causes a warning to be
+           printed if an included \c{.pri} file cannot be found.
+
+        \i Create a standalone shared library containing the custom widgets only
+           as described in
+           \l{sharedlibrary.html}{Creating Shared Libraries}.
+
+           This library would then be used by the application as well as by the
+           \QD plugin. Care must be taken to ensure that the plugin can locate
+          the library at run-time.
+    \endlist
+
+    \section1 Related Examples
+
+    For more information on using custom widgets in \QD, refer to the
+    \l{designer/customwidgetplugin}{Custom Widget Plugin} and
+    \l{designer/worldtimeclockplugin}{World Time Clock Plugin} examples for more
+    information about using custom widgets in \QD. Also, you can use the
+    QDesignerCustomWidgetCollectionInterface class to combine several custom
+    widgets into a single library.
+*/
+
+
+/*!
+    \page designer-creating-custom-widgets-extensions.html
+    \previouspage Creating Custom Widgets for Qt Designer
+    \nextpage Qt Designer's UI File Format
+    \contentspage {Qt Designer Manual}{Contents}
+
+    \title Creating Custom Widget Extensions
+
+    Once you have a custom widget plugin for \QD, you can provide it with the
+    expected behavior and functionality within \QD's workspace, using custom
+    widget extensions.
+
+
+    \section1 Extension Types
+
+    There are several available types of extensions in \QD. You can use all of
+    these extensions in the same pattern, only replacing the respective
+    extension base class.
+
+    QDesignerContainerExtension is necessary when implementing a custom
+    multi-page container.
+
+    \table
+        \row
+            \i  \inlineimage designer-manual-taskmenuextension.png
+            \i  \bold{QDesignerTaskMenuExtension}
+
+        QDesignerTaskMenuExtension is useful for custom widgets. It provides an
+        extension that allows you to add custom menu entries to \QD's task
+        menu.
+
+        The \l{designer/taskmenuextension}{Task Menu Extension} example
+        illustrates how to use this class.
+
+        \row
+            \i  \inlineimage designer-manual-containerextension.png
+            \i  \bold{QDesignerContainerExtension}
+
+        QDesignerContainerExtension is necessary when implementing a custom
+        multi-page container. It provides an extension that allows you to add
+        and delete pages for a multi-page container plugin in \QD.
+
+        The \l{designer/containerextension}{Container Extension} example
+        further explains how to use this class.
+
+        \note It is not possible to add custom per-page properties for some
+        widgets (e.g., QTabWidget) due to the way they are implemented.
+    \endtable
+
+    \table
+        \row
+            \i  \inlineimage designer-manual-membersheetextension.png
+            \i  \bold{QDesignerMemberSheetExtension}
+
+        The QDesignerMemberSheetExtension class allows you to manipulate a
+        widget's member functions displayed when connecting signals and slots.
+
+        \row
+            \i  \inlineimage designer-manual-propertysheetextension.png
+            \i  \bold{QDesignerPropertySheetExtension,
+                QDesignerDynamicPropertySheetExtension}
+
+        These extension classes allow you to control how a widget's properties
+        are displayed in \QD's property editor.
+    \endtable
+
+\omit
+     \row
+        \o
+        \o \bold {QDesignerScriptExtension}
+
+         The QDesignerScriptExtension class allows you to define script
+         snippets that are executed when a form is loaded. The extension
+         is primarily intended to be used to set up the internal states
+         of custom widgets.
+    \endtable
+\endomit
+
+
+    \QD uses the QDesignerPropertySheetExtension and the
+    QDesignerMemberSheetExtension classes to feed its property and signal and
+    slot editors. Whenever a widget is selected in its workspace, \QD will
+    query for the widget's property sheet extension; likewise, whenever a
+    connection between two widgets is requested, \QD will query for the
+    widgets' member sheet extensions.
+
+    \warning All widgets have default property and member sheets. If you
+    implement custom property sheet or member sheet extensions, your custom
+    extensions will override the default sheets.
+
+
+    \section1 Creating an Extension
+
+    To create an extension you must inherit both QObject and the appropriate
+    base class, and reimplement its functions. Since we are implementing an
+    interface, we must ensure that it is made known to the meta object system
+    using the Q_INTERFACES() macro in the extension class's definition. For
+    example:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 7
+
+    This enables \QD to use the qobject_cast() function to query for supported
+    interfaces using a QObject pointer only.
+
+
+    \section1 Exposing an Extension to Qt Designer
+
+    In \QD the extensions are not created until they are required. For this
+    reason, when implementing extensions, you must subclass QExtensionFactory
+    to create a class that is able to make instances of your extensions. Also,
+    you must register your factory with \QD's extension manager; the extension
+    manager handles the construction of extensions.
+
+    When an extension is requested, \QD's extension manager will run through
+    its registered factories calling QExtensionFactory::createExtension() for
+    each of them until it finds one that is able to create the requested
+    extension for the selected widget. This factory will then make an instance
+    of the extension.
+
+    \image qtdesignerextensions.png
+
+
+    \section2 Creating an Extension Factory
+
+    The QExtensionFactory class provides a standard extension factory, but it
+    can also be used as an interface for custom extension factories.
+
+    The purpose is to reimplement the QExtensionFactory::createExtension()
+    function, making it able to create your extension, such as a
+     \l{designer/containerextension}{MultiPageWidget} container extension.
+
+    You can either create a new QExtensionFactory and reimplement the
+    QExtensionFactory::createExtension() function:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 8
+
+    or you can use an existing factory, expanding the
+    QExtensionFactory::createExtension() function to enable the factory to
+    create your custom extension as well:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 9
+
+
+    \section2 Accessing Qt Designer's Extension Manager
+
+    When implementing a custom widget plugin, you must subclass the
+    QDesignerCustomWidgetInterface to expose your plugin to \QD. This is
+    covered in more detail in the
+    \l{Creating Custom Widgets for Qt Designer} section. The registration of
+    an extension factory is typically made in the
+    QDesignerCustomWidgetInterface::initialize() function:
+
+    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 10
+
+    The \c formEditor parameter in the
+    QDesignerCustomWidgetInterface::initialize() function is a pointer to \QD's
+    current QDesignerFormEditorInterface object. You must use the
+    QDesignerFormEditorInterface::extensionManager() function to retrieve an
+    interface to \QD's extension manager. Then you use the
+    QExtensionManager::registerExtensions() function to register your custom
+    extension factory.
+
+
+    \section1 Related Examples
+
+    For more information on creating custom widget extensions in \QD, refer to
+    the \l{designer/taskmenuextension}{Task Menu Extension} and
+    \l{designer/containerextension}{Container Extension} examples.
+*/
+
+
+/*!
+    \page designer-ui-file-format.html
+    \previouspage Creating Custom Widget Extensions
+    \contentspage {Qt Designer Manual}{Contents}
+
+    \title Qt Designer's UI File Format
+
+    The \c UI file format used by \QD is described by the
+    \l{http://www.w3.org/XML/Schema}{XML schema} presented below,
+    which we include for your convenience. Be aware that the format
+    may change in future Qt releases.
+
+    \quotefile tools/designer/data/ui4.xsd
+*/
+
+
+/*!
+    \page designer-recursive-shadow-casting.html
+    \title Implementation of the Recursive Shadow Casting Algorithm in Qt Designer
+    \contentspage {Qt Designer Manual}{Contents}
+
+    \ingroup licensing
+    \brief License information for contributions to specific parts of the Qt
+    Designer source code.
+
+    \legalese
+    Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies). \BR
+    Copyright (C) 2005 Bjoern Bergstroem
+
+    Permission is hereby granted, free of charge, to any person obtaining
+    a copy of this software and associated documentation files (the
+    "Software"), to deal in the Software without restriction, including
+    without limitation the rights to use, modify, market, reproduce,
+    grant sublicenses and distribute subject to the following conditions:
+    The above copyright notice and this permission notice shall be
+    included in all copies or substantial portions of the Software. These
+    files are provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
+    WARRANTY OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
+    PURPOSE.
+    \endlegalese
+*/
diff --git a/doc/src/development/developing-on-mac.qdoc b/doc/src/development/developing-on-mac.qdoc
new file mode 100644
index 0000000000..dee6d4d3de
--- /dev/null
+++ b/doc/src/development/developing-on-mac.qdoc
@@ -0,0 +1,269 @@
+/****************************************************************************
+**
+** 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 developing-on-mac.html
+    \title Developing Qt Applications on Mac OS X
+    \brief A overview of items to be aware of when developing Qt applications
+        on Mac OS X
+    \ingroup platform-specific
+
+    \tableofcontents
+
+    Mac OS X is a UNIX platform and behaves similar to other Unix-like
+    platforms. The main difference is X11 is not used as the primary windowing
+    system. Instead, Mac OS X uses its own native windowing system that is
+    accessible through the Carbon and Cocoa APIs.  Application development on
+    Mac OS X is done using Xcode Tools, an optional install included on every
+    Mac with updates available from \l {http://developer.apple.com}{Apple's
+    developer website}. Xcode Tools includes Apple-modified versions of the GCC
+    compiler.
+
+
+    \section1 What Versions of Mac OS X are Supported?
+
+    As of Qt 4.6, Qt supports Mac OS X versions 10.4 and up. It is usually in
+    the best interest of the developer and user to be running the latest
+    updates to any version. We test internally against Mac OS X 10.4.11 as well
+    as the updated release of Mac OS X 10.5 and Mac OS X 10.6.
+
+    \section2 Carbon or Cocoa?
+    
+    Historically, Qt has used the Carbon toolkit, which supports 32-bit
+    applications on Mac OS X 10.4 and up. Qt 4.5 and up has support for the Cocoa
+    toolkit, which requires 10.5 and provides 64-bit support.
+
+    This detail is typically not important to Qt application developers.  Qt is
+    cross-platform across Carbon and Cocoa, and Qt applications behave
+    the same way when configured for either one. Eventually, the Carbon
+    version will be discontinued. This is something to keep in mind when you
+    consider writing code directly against native APIs.
+
+    The current binary for Qt is built in two flavors, 32-bit Carbon and full
+    universal Cocoa (32-bit and 64-bit). If you want a different setup for
+    Qt will use, you must build from scratch. Carbon or Cocoa is chosen when
+    configuring the package for building. The configure process selects Carbon
+    by default, to specify Cocoa use the \c{-cocoa} flag.  configure for a
+    64-bit architecture using one of the \c{-arch} flags (see \l{universal
+    binaries}{Universal Binaries}).
+
+    Currently, Apple's default GCC compiler is used by default (GCC 4.0.1 on
+    10.4 and 10.5, GCC 4.2 on 10.6). You can specify alternate compilers
+    though. For example, on Mac OS X 10.5, Apple's GCC 4.2 is also available
+    and selectable with the configure flag: \c{-platform macx-g++42}.  LLVM-GCC
+    support is available by passing in the \c{-platform macx-llvm} flag. GCC
+    3.x will \e not work. Though they may work, We do not support custom-built
+    GCC's.
+
+    The following table summarizes the different versions of Mac OS X and what
+    capabilities are used by Qt.
+
+    \table
+        \header
+            \o Mac OS X Version
+            \o Cat Name
+            \o Native API Used by Qt
+            \o Bits available to address memory
+            \o CPU Architecture Supported
+            \o Development Platform
+        \row
+            \o 10.4
+            \o Tiger
+            \o Carbon
+            \o 32
+            \o PPC/Intel
+            \o Yes
+        \row
+            \o 10.5
+            \o Leopard
+            \o Carbon
+            \o 32
+            \o PPC/Intel
+            \o Yes
+        \row
+            \o 10.5
+            \o Leopard
+            \o Cocoa
+            \o 32/64
+            \o PPC/Intel
+            \o Yes
+        \row
+            \o 10.6
+            \o Snow Leopard
+            \o Carbon
+            \o 32
+            \o PPC/Intel
+            \o Yes
+        \row
+            \o 10.6
+            \o Snow Leopard
+            \o Cocoa
+            \o 32/64
+            \o PPC/Intel
+            \o Yes
+    \endtable
+
+    \section2 Which One Should I Use?
+
+    Carbon and Cocoa both have their advantages and disadvantages. Probably the
+    easiest way to determine is to look at the version of Mac OS X you are
+    targetting.  If you are starting a new application and can target 10.5 and
+    up, then please consider Cocoa only. If you have an existing application or
+    need to target earlier versions of the operating system and do not need
+    access to 64-bit or newer Apple technologies, then Carbon is a good fit. If
+    your needs fall in between, you can go with a 64-bit Cocoa and 32-bit
+    Carbon universal application with the appropriate checks in your code to
+    choose the right path based on where you are running the application.
+
+    For Mac OS X 10.6, Apple has started recommending developers to build their
+    applications 64-bit. The main reason is that there is a small speed
+    increase due to the extra registers on Intel CPU's, all their machine
+    offerings have been 64-bit since 2007, and there is a cost for reading all
+    the 32-bit libraries into memory if everything else is 64-bit.  If you want
+    to follow this advice, there is only one choice, 64-bit Cocoa.
+
+    \target universal binaries
+    \section1 Universal Binaries
+
+    In 2006, Apple begin transitioning from PowerPC (PPC) to Intel (x86)
+    systems.  Both architectures are supported by Qt. The release of Mac OS X
+    10.5 in October 2007 added the possibility of writing and deploying 64-bit
+    GUI applications. Qt 4.5 and up supports both the 32-bit (PPC and x86) and
+    64-bit (PPC64 and x86-64) versions of PowerPC and Intel-based systems.
+
+    Universal binaries are used to bundle binaries for more than one
+    architecture into a single package, simplifying deployment and
+    distribution. When running an application the operating system will select
+    the most appropriate architecture. Universal binaries support the following
+    architectures; they can be added to the build at configure time using the
+    \c{-arch} arguments:
+
+    \table
+        \header
+            \o Architecture		
+            \o Flag
+        \row
+            \o Intel, 32-bit
+            \o \c{-arch x86}
+        \row
+            \o Intel, 64-bit
+            \o \c{-arch x86_64}
+        \row
+            \o PPC, 32-bit
+            \o \c{-arch ppc}
+        \row
+            \o PPC, 64-bit
+            \o \c{-arch ppc64}
+    \endtable
+
+    If there are no \c{-arch} flags specified, configure builds for the 32-bit
+    architecture, if you are currently on one. Universal binaries were initially
+    used to simplify the PPC to Intel migration. You can use \c{-universal} to
+    build for both the 32-bit Intel and PPC architectures.
+
+    \note The \c{-arch} flags at configure time only affect how Qt is built.
+    Applications are by default built for the 32-bit architecture you are
+    currently on. To build a universal binary, add the architectures to the
+    CONFIG variable in the .pro file:
+
+    \code
+    CONFIG += x86 ppc x86_64 ppc64
+    \endcode
+
+
+    \section1 Day-to-Day Application Development on OS X
+
+    On the command-line, applications can be built using \c qmake and \c make.
+    Optionally, \c qmake can generate project files for Xcode with
+    \c{-spec macx-xcode}. If you are using the binary package, \c qmake
+    generates Xcode projects by default; use \c{-spec macx-gcc} to generate
+    makefiles.
+
+    The result of the build process is an application bundle, which is a
+    directory structure that contains the actual application executable. The
+    application can be launched by double-clicking it in Finder, or by
+    referring directly to its executable from the command line, i. e.
+    \c{myApp.app/Contents/MacOS/myApp}.
+
+    If you wish to have a command-line tool that does not use the GUI (e.g.,
+    \c moc, \c uic or \c ls), you can tell \c qmake not to execute the bundle
+    creating steps by removing it from the \c{CONFIG} in your \c{.pro} file:
+
+    \code
+    CONFIG -= app_bundle
+    \endcode
+
+
+    \section1 Deployment - "Compile once, deploy everywhere"
+
+    In general, Qt supports building on one Mac OS X version and deploying on
+    all others, both forward and backwards. You can build on 10.4 Tiger and run
+    the same binary on 10.5 and up.
+
+    Some restrictions apply:
+
+    \list
+        \o  Some functions and optimization paths that exist in later versions
+            of Mac OS X will not be available if you build on an earlier
+            version of Mac OS X.
+        \o  The CPU architecture should match.
+        \o  Cocoa support is only available for Mac OS X 10.5 and up.
+    \endlist
+
+    Universal binaries can be used to provide a smorgasbord of configurations
+    catering to all possible architectures.
+
+    Mac applications are typically deployed as self-contained application
+    bundles. The application bundle contains the application executable as well
+    as dependencies such as the Qt libraries, plugins, translations and other
+    resources you may need. Third party libraries like Qt are normally not
+    installed system-wide; each application provides its own copy.
+
+    The most common way to distribute applications is to provide a compressed
+    disk image (.dmg file) that the user can mount in Finder. The Mac
+    deployment tool (macdeployqt) can be used to create the self-contained bundles, and
+    optionally also create a .dmg archive. See the
+    \l{Deploying an Application on Mac OS X}{Mac deployment guide} for more
+    information about deployment. It is also possible to use an installer
+    wizard. More information on this option can be found in
+    \l{http://developer.apple.com/mac/}{Apple's documentation}.
+*/
+
diff --git a/doc/src/development/developing-with-qt.qdoc b/doc/src/development/developing-with-qt.qdoc
new file mode 100644
index 0000000000..9fa224281f
--- /dev/null
+++ b/doc/src/development/developing-with-qt.qdoc
@@ -0,0 +1,74 @@
+/****************************************************************************
+**
+** 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 developing-with-qt.html
+    \title Cross Platform Development with Qt
+
+    Qt is provided with a set of build tools to help developers automate
+    the process of building and installing Qt applications.
+
+    \table 100%
+    \header \o Development \o Cross-Platform Issues \o Specific Tools
+    \row
+    \o
+     \list
+        \o \l {Debugging Techniques}
+        \o \l {Qt's Tools}
+        \o \l {The Qt Resource System}
+        \o \l {Using Precompiled Headers}
+    \endlist
+    \o
+    \list
+        \o \l {Cross Compiling Qt for Embedded Linux Applications}
+        \o \l {Deploying Qt Applications}
+        \o \l {Installation}{Installing Qt}
+        \o \l {Window System Specific Notes}
+    \endlist
+    \o
+    \list
+        \o \l lupdate and \l lrelease
+        \o \l {moc}{Meta-Object Compiler (moc)}
+        \o \l {User Interface Compiler (uic)}
+        \o \l {Resource Compiler (rcc)}
+    \endlist
+    \endtable
+*/
diff --git a/doc/src/development/moc.qdoc b/doc/src/development/moc.qdoc
new file mode 100644
index 0000000000..747c68d6a0
--- /dev/null
+++ b/doc/src/development/moc.qdoc
@@ -0,0 +1,335 @@
+/****************************************************************************
+**
+** 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 moc.html
+    \title Using the Meta-Object Compiler (moc)
+    \ingroup qttools
+    \keyword moc
+
+    The Meta-Object Compiler, \c moc, is the program that handles
+    \l{Meta-Object System}{Qt's C++ extensions}.
+
+    The \c moc tool reads a C++ header file. If it finds one or more
+    class declarations that contain the Q_OBJECT macro, it
+    produces a C++ source file containing the meta-object code for
+    those classes. Among other things, meta-object code is required
+    for the signals and slots mechanism, the run-time type information,
+    and the dynamic property system.
+
+    The C++ source file generated by \c moc must be compiled and
+    linked with the implementation of the class.
+
+    If you use \l qmake to create your makefiles, build rules will be
+    included that call the moc when required, so you will not need to
+    use the moc directly. For more background information on \c moc,
+    see \l{Why Doesn't Qt Use Templates for Signals and Slots?}
+
+    \section1 Usage
+
+    \c moc is typically used with an input file containing class
+    declarations like this:
+
+    \snippet doc/src/snippets/moc/myclass1.h 0
+
+    In addition to the signals and slots shown above, \c moc also
+    implements object properties as in the next example. The
+    Q_PROPERTY() macro declares an object property, while
+    Q_ENUMS() declares a list of enumeration types within the class
+    to be usable inside the \l{Qt's Property System}{property
+    system}.
+
+    In the following example, we declare a property of the
+    enumeration type \c Priority that is also called \c priority and
+    has a get function \c priority() and a set function \c
+    setPriority().
+
+    \snippet doc/src/snippets/moc/myclass2.h 0
+
+    The Q_FLAGS() macro declares enums that are to be used
+    as flags, i.e. OR'd together. Another macro, Q_CLASSINFO(),
+    allows you to attach additional name/value pairs to the class's
+    meta-object:
+
+    \snippet doc/src/snippets/moc/myclass3.h 0
+
+    The output produced by \c moc must be compiled and linked, just
+    like the other C++ code in your program; otherwise, the build
+    will fail in the final link phase. If you use \c qmake, this is
+    done automatically. Whenever \c qmake is run, it parses the
+    project's header files and generates make rules to invoke \c moc
+    for those files that contain a Q_OBJECT macro.
+
+    If the class declaration is found in the file \c myclass.h, the
+    moc output should be put in a file called \c moc_myclass.cpp.
+    This file should then be compiled as usual, resulting in an
+    object file, e.g., \c moc_myclass.obj on Windows. This object
+    should then be included in the list of object files that are
+    linked together in the final building phase of the program.
+
+    \section1 Writing Make Rules for Invoking \c moc
+
+    For anything but the simplest test programs, it is recommended
+    that you automate running the \c{moc}. By adding some rules to
+    your program's makefile, \c make can take care of running moc
+    when necessary and handling the moc output.
+
+    We recommend using the \l qmake makefile generation tool for
+    building your makefiles. This tool generates a makefile that does
+    all the necessary \c moc handling.
+
+    If you want to create your makefiles yourself, here are some tips
+    on how to include moc handling.
+
+    For Q_OBJECT class declarations in header files, here is a
+    useful makefile rule if you only use GNU make:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 0
+
+    If you want to write portably, you can use individual rules of
+    the following form:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 1
+
+    You must also remember to add \c moc_foo.cpp to your \c SOURCES
+    (substitute your favorite name) variable and \c moc_foo.o or \c
+    moc_foo.obj to your \c OBJECTS variable.
+
+    Both examples assume that \c $(DEFINES) and \c $(INCPATH) expand
+    to the define and include path options that are passed to the C++
+    compiler. These are required by \c moc to preprocess the source
+    files.
+
+    While we prefer to name our C++ source files \c .cpp, you can use
+    any other extension, such as \c .C, \c .cc, \c .CC, \c .cxx, and
+    \c .c++, if you prefer.
+
+    For Q_OBJECT class declarations in implementation (\c .cpp)
+    files, we suggest a makefile rule like this:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 2
+
+    This guarantees that make will run the moc before it compiles
+    \c foo.cpp. You can then put
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 3
+
+    at the end of \c foo.cpp, where all the classes declared in that
+    file are fully known.
+
+    \section1 Command-Line Options
+
+    Here are the command-line options supported by the moc:
+
+    \table
+    \header \o Option \o Description
+
+    \row
+    \o \c{-o<file>}
+    \o Write output to \c <file> rather than to standard output.
+
+    \row
+    \o \c{-f[<file>]}
+    \o Force the generation of an \c #include statement in the
+    output. This is the default for header files whose extension
+    starts with \c H or \c h. This option is useful if you have
+    header files that do not follow the standard naming conventions.
+    The \c <file> part is optional.
+
+    \row
+    \o \c -i
+    \o Do not generate an \c #include statement in the output.
+    This may be used to run the moc on on a C++ file containing one or
+    more class declarations. You should then \c #include the meta-object
+    code in the \c .cpp file.
+
+    \row
+    \o \c -nw
+    \o Do not generate any warnings. (Not recommended.)
+
+    \row
+    \o \c {-p<path>}
+    \o Makes the moc prepend \c {<path>/} to the file name in the
+    generated \c #include statement.
+
+    \row
+    \o \c {-I<dir>}
+    \o Add dir to the include path for header files.
+
+    \row
+    \o \c{-E}
+    \o Preprocess only; do not generate meta-object code.
+
+    \row
+    \o \c {-D<macro>[=<def>]}
+    \o Define macro, with optional definition.
+
+    \row
+    \o \c{-U<macro>}
+    \o Undefine macro.
+
+    \row
+    \o \c{@<file>}
+    \o Read additional command-line options from \c{<file>}.
+    Each line of the file is treated as a single option. Empty lines
+    are ignored. Note that this option is not supported within the
+    options file itself (i.e. an options file can't "include" another
+    file).
+
+    \row
+    \o \c{-h}
+    \o Display the usage and the list of options.
+
+    \row
+    \o \c {-v}
+    \o Display \c{moc}'s version number.
+
+    \row
+    \o \c{-Fdir}
+    
+    \o Mac OS X. Add the framework directory \c{dir} to the head of
+       the list of directories to be searched for header files. These
+       directories are interleaved with those specified by -I options
+       and are scanned in a left-to-right order (see the manpage for
+       gcc). Normally, use -F /Library/Frameworks/
+
+    \endtable
+
+    You can explicitly tell the moc not to parse parts of a header
+    file. \c moc defines the preprocessor symbol \c Q_MOC_RUN. Any
+    code surrounded by
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 4
+
+    is skipped by the \c moc.
+
+    \section1 Diagnostics
+
+    \c moc will warn you about a number of dangerous or illegal
+    constructs in the Q_OBJECT class declarations.
+
+    If you get linkage errors in the final building phase of your
+    program, saying that \c YourClass::className() is undefined or
+    that \c YourClass lacks a vtable, something has been done wrong.
+    Most often, you have forgotten to compile or \c #include the
+    moc-generated C++ code, or (in the former case) include that
+    object file in the link command. If you use \c qmake, try
+    rerunning it to update your makefile. This should do the trick.
+
+    \section1 Limitations
+
+    \c moc does not handle all of C++. The main problem is that class
+    templates cannot have signals or slots. Here is an example:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 5
+
+    Another limitation is that moc does not expand macros, so you
+    for example cannot use a macro to declare a signal/slot
+    or use one to define a base class for a QObject.
+
+    Less importantly, the following constructs are illegal. All of
+    them have alternatives which we think are usually better, so
+    removing these limitations is not a high priority for us.
+
+    \section2 Multiple Inheritance Requires QObject to Be First
+
+    If you are using multiple inheritance, \c moc assumes that the
+    first inherited class is a subclass of QObject. Also, be sure
+    that only the first inherited class is a QObject.
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 6
+
+    Virtual inheritance with QObject is \e not supported.
+
+    \section2 Function Pointers Cannot Be Signal or Slot Parameters
+
+    In most cases where you would consider using function pointers as
+    signal or slot parameters, we think inheritance is a better
+    alternative. Here is an example of illegal syntax:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 7
+
+    You can work around this restriction like this:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 8
+
+    It may sometimes be even better to replace the function pointer
+    with inheritance and virtual functions.
+
+    \section2 Enums and Typedefs Must Be Fully Qualified for Signal and Slot Parameters
+
+    When checking the signatures of its arguments, QObject::connect()
+    compares the data types literally. Thus,
+    \l{Qt::Alignment}{Alignment} and \l{Qt::Alignment} are treated as
+    two distinct types. To work around this limitation, make sure to
+    fully qualify the data types when declaring signals and slots,
+    and when establishing connections. For example:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 9
+
+    \section2 Type Macros Cannot Be Used for Signal and Slot Parameters
+
+    Since \c moc doesn't expand \c{#define}s, type macros that take
+    an argument will not work in signals and slots. Here is an
+    illegal example:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 10
+
+    A macro without parameters will work.
+
+    \section2 Nested Classes Cannot Have Signals or Slots
+
+    Here's an example of the offending construct:
+
+    \snippet doc/src/snippets/code/doc_src_moc.qdoc 11
+
+    \section2 Signal/Slot return types cannot be references
+
+    Signals and slots can have return types, but signals or slots returning references
+    will be treated as returning void.
+
+    \section2 Only Signals and Slots May Appear in the \c signals and \c slots Sections of a Class
+
+    \c moc will complain if you try to put other constructs in the \c
+    signals or \c slots sections of a class than signals and slots.
+
+    \sa {Meta-Object System}, {Signals and Slots}, {Qt's Property System}
+*/
diff --git a/doc/src/development/qmake-manual.qdoc b/doc/src/development/qmake-manual.qdoc
new file mode 100644
index 0000000000..181ba6a779
--- /dev/null
+++ b/doc/src/development/qmake-manual.qdoc
@@ -0,0 +1,4320 @@
+/****************************************************************************
+**
+** 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 qmake-manual.html
+    \title qmake Manual
+    \startpage {index.html}{Qt Reference Documentation}
+    \nextpage qmake Tutorial
+
+    \ingroup qttools
+    \keyword qmake
+
+    \c qmake is a tool that helps simplify the build
+    process for development project across different platforms.  \c qmake
+    automates the generation of Makefiles so that only a few lines of
+    information are needed to create each Makefile. \c qmake can be used for
+    any software project, whether it is written in Qt or not.
+
+    \c qmake generates a Makefile based on the information in a project
+    file.  Project files are created by the developer, and are usually
+    simple, but more sophisticated project files can be created for
+    complex projects.
+    \c qmake contains additional features to support development with Qt,
+    automatically including build rules for \l{moc.html}{moc}
+    and \l{uic.html}{uic}.
+    \c qmake can also generate projects for Microsoft Visual studio
+    without requiring the developer to change the project file.
+
+    \section1 Getting Started
+
+    The \l{qmake Tutorial} and guide to \l{qmake Common Projects} provide overviews
+    that aim to help new users get started with \c qmake.
+
+    \list
+    \o \l{qmake Tutorial}
+      \tableofcontents{1 qmake Tutorial}
+    \endlist
+
+    \list
+    \o \l{qmake Common Projects}
+      \tableofcontents{1 qmake Common Projects}
+    \endlist
+
+    \section1 Table of Contents
+
+    \list
+    \o \l{Using qmake}
+      \tableofcontents{1 Using qmake}
+    \o \l{qmake Project Files}
+      \tableofcontents{1 qmake Project Files}
+    \o \l{Running qmake}
+      \tableofcontents{1 Running qmake}
+    \o \l{qmake Platform Notes}
+      \tableofcontents{1 qmake Platform Notes}
+    \o \l{qmake Advanced Usage}
+      \tableofcontents{1 qmake Advanced Usage}
+    \o \l{Using Precompiled Headers}
+      \tableofcontents{1 Using Precompiled Headers}
+    \o \l{qmake Reference}
+      \tableofcontents{1 qmake Reference}
+    \o \l{qmake Variable Reference}
+      \tableofcontents{1 qmake Variable Reference}
+    \o \l{qmake Function Reference}
+      \tableofcontents{1 qmake Function Reference}
+    \o \l{Configuring qmake's Environment}
+      \tableofcontents{1 Configuring qmake's Environment}
+    \endlist
+*/
+
+/*!
+    \page qmake-using.html
+    \title Using qmake
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Manual
+    \nextpage qmake Project Files
+
+    \c qmake provides a project-oriented system for managing the build
+    process for applications, libraries, and other components. This
+    approach gives developers control over the source files used, and
+    allows each of the steps in the process to be described concisely,
+    typically within a single file. \c qmake expands the information in
+    each project file to a Makefile that executes the necessary commands
+    for compiling and linking.
+
+    In this document, we provide a basic introduction to project files,
+    describe some of the main features of \c qmake, and show how to use
+    \c qmake on the command line.
+
+    \section1 Describing a Project
+
+    Projects are described by the contents of project (\c .pro) files.
+    The information within these is used by \c qmake to generate a Makefile
+    containing all the commands that are needed to build each project.
+    Project files typically contain a list of source and header files,
+    general configuration information, and any application-specific details,
+    such as a list of extra libraries to link against, or a list of extra
+    include paths to use.
+
+    Project files can contain a number of different elements, including
+    comments, variable declarations, built-in functions, and some simple
+    control structures. In most simple projects, it is only necessary
+    to declare the source and header files that are used to build the
+    project with some basic configuration options.
+
+    Complete examples of project files can be found in the
+    \l{qmake Tutorial}.
+    An introduction to project files can be found in the
+    \l{qmake Project Files} chapter, and a more detailed description is
+    available in the \l{qmake Reference}.
+
+    \section1 Building a Project
+
+    For simple projects, you only need to run \c qmake in the top
+    level directory of your project. By default, \c qmake generates a
+    Makefile that you then use to build the project, and you can then
+    run your platform's \c make tool to build the project.
+
+    \c qmake can also be used to generate project files. A full
+    description of \c{qmake}'s command line options can be found in the
+    \l{Running qmake} chapter of this manual.
+
+    \section1 Using Precompiled Headers
+
+    In large projects, it is possible to take advantage of precompiled
+    header files to speed up the build process. This feature is described
+    in detail in the \l{Using Precompiled Headers} chapter.
+*/
+
+/*!
+    \page qmake-project-files.html
+    \title qmake Project Files
+    \contentspage {qmake Manual}{Contents}
+    \previouspage Using qmake
+    \nextpage Running qmake
+
+    Project files contain all the information required by \c qmake to build
+    your application, library, or plugin. The resources used by your project
+    are generally specified using a series of declarations, but support for
+    simple programming constructs allow you to describe different build
+    processes for different platforms and environments.
+
+    \tableofcontents
+
+    \section1 Project File Elements
+
+    The project file format used by \c qmake can be used to support both
+    simple and fairly complex build systems. Simple project files will
+    use a straightforward declarative style, defining standard variables
+    to indicate the source and header files that are used in the project.
+    Complex projects may use the control flow structures to fine-tune the
+    build process.
+
+    The following sections describe the different types of elements used
+    in project files.
+
+    \section2 Variables
+
+    In a project file, variables are used to hold lists of strings.
+    In the simplest projects, these variables inform \c qmake about the
+    configuration options to use, or supply filenames and paths to use
+    in the build process.
+
+    \c qmake looks for certain variables in each project file, and it
+    uses the contents of these to determine what it should write to a
+    Makefile. For example, the list of values in the \c HEADERS and
+    \c SOURCES variables are used to tell \c qmake about header and
+    source files in the same directory as the project file.
+
+    Variables can also be used internally to store temporary lists of values,
+    and existing lists of values can be overwritten or extended with new
+    values.
+
+    The following lines show how lists of values are assigned to variables:
+
+    \snippet doc/src/snippets/qmake/variables.pro 0
+
+    Note that the first assignment only includes values that are specified on
+    the same line as the \c SOURCES variable. The second assignment splits
+    the items across lines by using the \c \\ character.
+
+    The list of values in a variable is extended in the following way:
+
+    \snippet doc/src/snippets/qmake/variables.pro 1
+
+    The \c CONFIG variable is another special variable that \c qmake
+    uses when generating a Makefile. It is discussed in the section on
+    \l{#GeneralConfiguration}{general configuration} later in this chapter.
+    In the above line, \c qt is added to the list of existing values
+    contained in \c CONFIG.
+
+    The following table lists the variables that \c qmake recognizes, and
+    describes what they should contain.
+
+    \table
+    \header \o Variable \o Contents
+    \row \o CONFIG    \o General project configuration options.
+    \row \o DESTDIR   \o The directory in which the executable or binary file will
+                      be placed.
+    \row \o FORMS     \o A list of UI files to be processed by \c uic.
+    \row \o HEADERS   \o A list of filenames of header (.h) files used when
+                      building the project.
+    \row \o QT        \o Qt-specific configuration options.
+    \row \o RESOURCES \o A list of resource (.rc) files to be included in the
+                      final project. See the \l{The Qt Resource System} for
+                      more information about these files.
+    \row \o SOURCES   \o A list of source code files to be used when building
+                      the project.
+    \row \o TEMPLATE  \o The template to use for the project. This determines
+                      whether the output of the build process will be an
+                      application, a library, or a plugin.
+    \endtable
+
+    The contents of a variable can be read by prepending the variable name with
+    \c $$. This can be used to assign the contents of one variable to another:
+
+    \snippet doc/src/snippets/qmake/dereferencing.pro 0
+
+    The \c $$ operator is used extensively with built-in functions that operate
+    on strings and lists of values. These are described in the chapter on
+    \l{qmake Advanced Usage}.
+
+    \section3 Whitespace
+
+    Normally, variables are used to contain whitespace-separated lists
+    of values. However, it is sometimes necessary to specify values containing
+    spaces. These must be quoted by using the
+    \l{qmake Function Reference#quote-string}{quote()} function in the following way:
+
+    \snippet doc/src/snippets/qmake/quoting.pro 0
+
+    The quoted text is treated as a single item in the list of values held by
+    the variable. A similar approach is used to deal with paths that contain
+    spaces, particularly when defining the
+    \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH} and
+    \l{qmake Variable Reference#LIBS}{LIBS} variables for the Windows platform.
+    In cases like these, the \l{qmake Function Reference#quote(string)}{quote()}
+    function can be used in the following way:
+
+    \snippet doc/src/snippets/qmake/spaces.pro quoting include paths with spaces
+
+    \section2 Comments
+
+    You can add comments to project files. Comments begin with the \c
+    # character and continue to the end of the same line. For example:
+
+    \snippet doc/src/snippets/qmake/comments.pro 0
+
+    To include the \c # character in variable assignments, it is necessary
+    to use the contents of the built-in \c LITERAL_HASH variable. See the
+    \l{qmake Variable Reference#LITERAL_HASH}{variable reference} for more
+    information.
+
+    \section2 Built-in Functions and Control Flow
+
+    \c qmake provides a number of built-in functions to allow the contents
+    of variables to be processed. The most commonly used function in simple
+    project files is the \c include function which takes a filename as an
+    argument. The contents of the given file are included in the project
+    file at the place where the \c include function is used.
+    The \c include function is most commonly used to include other project
+    files:
+
+    \snippet doc/src/snippets/qmake/include.pro 0
+
+    Support for conditional structures is made available via
+    \l{qmake Advanced Usage#scopes}{scopes} that behave like \c if
+    statements in programming languages:
+
+    \snippet doc/src/snippets/qmake/scopes.pro 0
+
+    The assignments inside the braces are only made if the condition is
+    true. In this case, the special \c win32 variable must be set; this
+    happens automatically on Windows, but this can also be specified on
+    other platforms by running \c qmake with the \c{-win32} command line
+    option (see \l{Running qmake} for more information). The opening
+    brace must stand on the same line as the condition.
+
+    Simple loops are constructed by iterating over lists of values using
+    the built-in \c for function. The following code adds directories
+    to the \l{qmake Variable Reference#SUBDIRS}{SUBDIRS} variable, but
+    only if they exist:
+
+    \snippet doc/src/snippets/qmake/functions.pro 0
+
+    More complex operations on variables that would usually require loops
+    are provided by built-in functions such as \c find, \c unique, and
+    \c count. These functions, and many others are provided to manipulate
+    strings and paths, support user input, and call external tools. A list
+    of the functions available can be found in the
+    \l{qmake Advanced Usage} chapter of this manual.
+
+    \section1 Project Templates
+
+    The \c TEMPLATE variable is used to define the type of project that will
+    be built. If this is not declared in the project file, \c qmake assumes
+    that an application should be built, and will generate an appropriate
+    Makefile (or equivalent file) for the purpose.
+
+    The types of project available are listed in the following table with
+    information about the files that \c qmake will generate for each of them:
+
+    \table
+    \header \o Template      \o Description of \c qmake output
+    \row    \o app (default) \o Creates a Makefile to build an application.
+    \row    \o lib           \o Creates a Makefile to build a library.
+    \row    \o subdirs       \o Creates a Makefile containing rules for the
+    subdirectories specified using the \l{qmake Variable Reference#SUBDIRS}{SUBDIRS}
+    variable. Each subdirectory must contain its own project file.
+    \row    \o vcapp         \o Creates a Visual Studio Project file to build
+                             an application.
+    \row    \o vclib         \o Creates a Visual Studio Project file to build a library.
+    \endtable
+
+    See the \l{qmake Tutorial} for advice on writing project files for
+    projects that use the \c app and \c lib templates.
+
+    When the \c subdirs template is used, \c qmake generates a Makefile
+    to examine each specified subdirectory, process any project file it finds
+    there, and run the platform's \c make tool on the newly-created Makefile.
+    The \l{qmake Variable Reference#SUBDIRS}{SUBDIRS} variable is used to
+    contain a list of all the subdirectories to be processed.
+
+    \target GeneralConfiguration
+    \section1 General Configuration
+
+    The \l{qmake Variable Reference#CONFIG}{CONFIG variable} specifies the
+    options and features that the compiler should use and the libraries that
+    should be linked against. Anything can be added to the \c CONFIG variable,
+    but the options covered below are recognized by \c qmake internally.
+
+    The following options control the compiler flags that are used to build the
+    project:
+
+    \table
+    \header \o Option   \o Description
+    \row    \o release  \o The project is to be built in release mode.
+            This is ignored if \c debug is also specified.
+    \row    \o debug    \o The project is to be built in debug mode.
+    \row    \o debug_and_release \o The project is built in \e both debug and
+            release modes.
+    \row    \o debug_and_release_target \o The project is built in \e both debug 
+    and release modes. TARGET is built into \e both the debug and release directories.
+    \row    \o build_all \o If \c debug_and_release is specified, the project is
+            built in both debug and release modes by default.
+    \row    \o autogen_precompile_source \o Automatically generates a \c .cpp file that includes 
+    the precompiled header file specified in the .pro file.
+    \row    \o ordered  \o When using the \c subdirs template, this option
+            specifies that the directories listed should be processed in the
+            order in which they are given.
+    \row    \o warn_on  \o The compiler should output as many warnings as possible.
+            This is ignored if \c warn_off is specified.
+    \row    \o warn_off \o The compiler should output as few warnings as possible.
+    \row    \o copy_dir_files \o Enables the install rule to also copy directories, not just files.  
+    \endtable
+
+    The \c debug_and_release option is special in that it enables \e both debug and
+    release versions of a project to be built. In such a case, the Makefile that
+    \c qmake generates includes a rule that builds both versions, and this can be
+    invoked in the following way:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 0
+
+    Adding the \c build_all option to the \c CONFIG variable makes this rule
+    the default when building the project, and installation targets will be
+    created for both debug and release builds.
+
+    Note that each of the options specified in the \c CONFIG variable can also be
+    used as a scope condition.
+    You can test for the presence of certain configuration options by using the
+    built-in \l{qmake Function Reference#CONFIG(config)}{CONFIG()} function.
+    For example, the following lines show the function as the condition in a scope
+    to test whether only the \c opengl option is in use:
+
+    \snippet doc/src/snippets/qmake/configscopes.pro 4
+    \snippet doc/src/snippets/qmake/configscopes.pro 5
+
+    This enables different configurations to be defined for \c release and
+    \c debug builds, and is described in more detail in the
+    \l{qmake Advanced Usage#Scopes}{Scopes} section of the
+    \l{qmake Advanced Usage}{Advanced Usage} chapter of this manual.
+
+    The following options define the type of project to be built. Note that some
+    of these options only take effect when used on the relevant platform. On other
+    platforms, they have no effect.
+
+    \table
+    \header \o Option \o Description
+    \row    \o qt     \o The project is a Qt application and should link against the Qt
+                      library. You can use the \c QT variable to control any additional
+                      Qt modules that are required by your application.
+    \row    \o thread \o The project is a multi-threaded application.
+    \row    \o x11    \o The project is an X11 application or library.
+    \endtable
+
+    When using \l{qmake Variable Reference#TEMPLATE}{application or library project
+    templates}, more specialized configuration options can be used to fine tune the
+    build process. These are explained in details in the
+    \l{qmake-common-projects.html}{Common Projects} chapter of this manual.
+
+    For example, if your application uses the Qt library and you want to
+    build it as a multi-threaded application in \c debug mode, your project
+    file will contain the following line:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 1
+
+    Note, that you must use "+=", not "=", or \c qmake will not be able to
+    use Qt's configuration to determine the settings needed for your project.
+
+    \section1 Declaring Qt Libraries
+
+    If the \c CONFIG variable contains the \c qt value, qmake's support for Qt
+    applications is enabled. This makes it possible to fine-tune which of the
+    Qt modules are used by your application. This is achieved with the \c QT
+    variable which can be used to declare the required extension modules.
+    For example, we can enable the XML and network modules in the following way:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 2
+
+    Note that \c QT includes the \c core and \c gui modules by default, so the
+    above declaration \e adds the network and XML modules to this default list.
+    The following assignment \e omits the default modules, and will lead to
+    errors when the application's source code is being compiled:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 3
+
+    If you want to build a project \e without the \c gui module, you need to
+    exclude it with the "-=" operator. By default, \c QT contains both
+    \c core and \c gui, so the following line will result in a minimal
+    Qt project being built:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 4
+
+    The table below shows the options that can be used with the \c QT variable
+    and the features that are associated with each of them:
+
+    \table
+    \header \o Option                     \o Features
+    \row    \o core (included by default) \o QtCore module
+    \row    \o gui  (included by default) \o QtGui module
+    \row    \o network                    \o QtNetwork module
+    \row    \o opengl                     \o QtOpenGL module
+    \row    \o sql                        \o QtSql module
+    \row    \o svg                        \o QtSvg module
+    \row    \o xml                        \o QtXml module
+    \row    \o xmlpatterns                \o QtXmlPatterns module
+    \row    \o qt3support                 \o Qt3Support module
+    \endtable
+
+    Note that adding the \c opengl option to the \c QT variable automatically
+    causes the equivalent option to be added to the \c CONFIG variable.
+    Therefore, for Qt applications, it is not necessary to add the \c opengl
+    option to both \c CONFIG and \c{QT}.
+
+    \section1 Configuration Features
+
+    \c qmake can be set up with extra configuration features that are specified
+    in feature (.prf) files. These extra features often provide support for
+    custom tools that are used during the build process. To add a feature to
+    the build process, append the feature name (the stem of the feature filename)
+    to the \c CONFIG variable.
+
+    For example, \c qmake can configure the build process to take advantage
+    of external libraries that are supported by
+    \l{http://www.freedesktop.org/wiki/Software_2fpkgconfig}{pkg-config},
+    such as the D-Bus and ogg libraries, with the following lines:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 5
+
+    More information about features can be found in the
+    \l{qmake Advanced Usage#Adding New Configuration Features}
+    {Adding New Configuration Features} section of the \l{qmake Advanced Usage}
+    chapter.
+
+    \section1 Declaring Other Libraries
+
+    If you are using other libraries in your project in addition to those
+    supplied with Qt, you need to specify them in your project file.
+
+    The paths that \c qmake searches for libraries and the specific libraries
+    to link against can be added to the list of values in the
+    \l{qmake Variable Reference#LIBS}{LIBS} variable. The paths to the libraries
+    themselves can be given, or the familiar Unix-style notation for specifying
+    libraries and paths can be used if preferred.
+
+    For example, the following lines show how a library can be specified:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 6
+
+    The paths containing header files can also be specified in a similar way
+    using the \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH} variable.
+
+    For example, it is possible to add several paths to be searched for header
+    files:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 7
+*/
+
+/*!
+    \page qmake-running.html
+    \title Running qmake
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Project Files
+    \nextpage qmake Platform Notes
+
+    The behavior of \c qmake can be customized when it is run by
+    specifying various options on the command line. These allow the
+    build process to be fine-tuned, provide useful diagnostic
+    information, and can be used to specify the target platform for
+    your project.
+
+    \tableofcontents
+
+    \target Commands
+    \section1 Command-Line Options
+
+    \section2 Syntax
+
+    The syntax used to run \c qmake takes the following simple form:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 8
+
+    \c qmake supports two different modes of operation: In the default mode,
+    \c qmake will use the description in a project file to generate a Makefile,
+    but it is also possible to use \c qmake to generate project files.
+    If you want to explicitly set the mode, you must specify it before all
+    other options. The \c mode can be either of the following two values:
+
+    \list
+    \o \c -makefile \BR
+        \c qmake output will be a Makefile.
+    \o \c -project \BR
+        \c qmake output will be a project file. \BR
+\bold{Note:} It is likely that the created file will need to be edited for example adding the \c QT variable to suit what modules are required for the project.
+    \endlist
+
+    The following \c options are used to specify both general and mode-specific
+    settings. Options that only apply to the Makefile mode are described in the
+    \l{#MakefileMode}{Makefile Mode Options} section; options that influence the
+    creation of project files are described in the
+    \l{#ProjectMode}{Project File Options} section.
+
+    The \c files argument represents a list of one or more project files, separated
+    by spaces.
+
+    \section2 Options
+
+    A wide range of options can be specified on the command line to \c qmake in
+    order to customize the build process, and to override default settings for
+    your platform. The following basic options provide usage information, specify
+    where \c qmake writes the output file, and control the level of debugging
+    information that will be written to the console:
+
+    \list
+    \o \c -help \BR
+        \c qmake will go over these features and give some useful help.
+    \o \c -o file \BR
+        \c qmake output will be directed to \e file. If this option
+        is not specified, \c qmake will try to use a suitable file name for its
+        output, depending on the mode it is running in.\BR
+        If '-' is specified, output is directed to stdout.
+    \o \c -d \BR
+        \c qmake will output debugging information.
+    \endlist
+
+    For projects that need to be built differently on each target platform, with
+    many subdirectories, you can run \c qmake with each of the following
+    options to set the corresponding platform-specific variable in each
+    project file:
+
+    \list
+    \o \c -unix \BR
+        \c qmake will run in unix mode.  In this mode, Unix file
+        naming and path conventions will be used, additionally testing for \c unix
+        (as a scope) will succeed. This is the default mode on all Unices.
+    \o \c -macx \BR
+        \c qmake will run in Mac OS X mode.  In this mode, Unix file
+        naming and path conventions will be used, additionally testing for \c macx
+        (as a scope) will succeed. This is the default mode on Mac OS X.
+    \o \c -win32 \BR
+        \c qmake will run in win32 mode.  In this mode, Windows file naming and path
+        conventions will be used, additionally testing for \c win32 (as a scope)
+        will succeed. This is the default mode on Windows.
+    \endlist
+
+    The template used for the project is usually specified by the \c TEMPLATE
+    variable in the project file. We can override or modify this by using the
+    following options:
+
+    \list
+    \o \c -t tmpl \BR
+        \c qmake will override any set \c TEMPLATE variables with tmpl, but only
+        \e after the .pro file has been processed.
+    \o \c -tp prefix \BR
+        \c qmake will add the prefix to the \c TEMPLATE variable.
+    \endlist
+
+    The level of warning information can be fine-tuned to help you find problems in
+    your project file:
+
+    \list
+    \o \c -Wall \BR
+          \c qmake will report all known warnings.
+    \o \c -Wnone \BR
+          No warning information will be generated by \c qmake.
+    \o \c -Wparser \BR
+          \c qmake will only generate parser warnings. This will alert
+          you to common pitfalls and potential problems in the parsing of your
+          project files.
+    \o \c -Wlogic \BR
+          \c qmake will warn of common pitfalls and potential problems in your
+          project file. For example, \c qmake will report whether a file is placed
+          into a list of files multiple times, or if a file cannot be found.
+    \endlist
+
+    \target MakefileMode
+    \section2 Makefile Mode Options
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 9
+
+    In Makefile mode, \c qmake will generate a Makefile that is used to build the
+    project. Additionally, the following options may be used in this mode to
+    influence the way the project file is generated:
+
+    \list
+    \o \c -after \BR
+       \c qmake will process assignments given on the command line after
+       the specified files.
+    \o \c -nocache \BR
+       \c qmake will ignore the .qmake.cache file.
+    \o \c -nodepend \BR
+       \c qmake will not generate any dependency information.
+    \o \c -cache file \BR
+       \c qmake will use \e file as the cache file, ignoring any other
+       .qmake.cache files found.
+    \o \c -spec spec \BR
+       \c qmake will use \e spec as a path to platform and compiler information,
+       and the value of \c QMAKESPEC will be ignored.
+    \endlist
+
+    You may also pass \c qmake assignments on the command line;
+    they will be processed before all of the files specified. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 10
+
+    This will generate a Makefile, from test.pro with Unix pathnames.  However
+    many of the specified options aren't necessary as they are the default.
+    Therefore, the line can be simplified on Unix to:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 11
+
+    If you are certain you want your variables processed after the
+    files specified, then you may pass the \c -after option. When this
+    is specified, all assignments on the command line after the \c -after
+    option will be postponed until after the specified files are parsed.
+
+    \target ProjectMode
+    \section2 Project Mode Options
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 12
+
+    In project mode, \c qmake will generate a project file. Additionally, you
+    may supply the following options in this mode:
+
+    \list
+    \o \c -r \BR
+       \c qmake will look through supplied directories recursively
+    \o \c -nopwd \BR
+       \c qmake will not look in your current working directory for
+       source code and only use the specified \c files
+    \endlist
+
+    In this mode, the \c files argument can be a list of files or directories.
+    If a directory is specified, it will be included in the \c DEPENDPATH
+    variable, and relevant code from there will be included in the generated
+    project file. If a file is given, it will be appended to the correct
+    variable, depending on its extension; for example, UI files are added
+    to \c FORMS, and C++ files are added to \c SOURCES.
+
+    You may also pass assignments on the command line in this mode. When doing
+    so, these assignments will be placed last in the generated project file.
+*/
+
+/*!
+    \page qmake-platform-notes.html
+    \title qmake Platform Notes
+    \contentspage {qmake Manual}{Contents}
+    \previouspage Running qmake
+    \nextpage qmake Advanced Usage
+
+    Many cross-platform projects can be handled by the \c{qmake}'s basic
+    configuration features. On some platforms, it is sometimes useful, or even
+    necessary, to take advantage of platform-specific features. \c qmake knows
+    about many of these features, and these can be accessed via specific
+    variables that only have an effect on the platforms where they are relevant.
+
+    \tableofcontents
+
+    \section1 Mac OS X
+
+    Features specific to this platform include support for creating universal
+    binaries, frameworks and bundles.
+
+    \section2 Source and Binary Packages
+
+    The version of \c qmake supplied in source packages is configured slightly
+    differently to that supplied in binary packages in that it uses a different
+    feature specification. Where the source package typically uses the
+    \c macx-g++ specification, the binary package is typically configured to
+    use the \c macx-xcode specification.
+
+    Users of each package can override this configuration by invoking \c qmake
+    with the \c -spec option (see \l{Running qmake} for more information). This
+    makes it possible, for example, to use \c qmake from a binary package to
+    create a Makefile in a project directory with the following command line
+    invocation:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 13
+
+    \section2 Using Frameworks
+
+    \c qmake is able to automatically generate build rules for linking against
+    frameworks in the standard framework directory on Mac OS X, located at
+    \c{/Library/Frameworks/}.
+
+    Directories other than the standard framework directory need to be specified
+    to the build system, and this is achieved by appending linker options to the
+    \l{qmake Variable Reference#QMAKE_LFLAGS}{QMAKE_LFLAGS} variable, as shown
+    in the following example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 14
+
+    The framework itself is linked in by appending the \c{-framework} options and
+    the name of the framework to the \l{qmake Variable Reference#LIBS}{LIBS}
+    variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 15
+
+    \section2 Creating Frameworks
+
+    Any given library project can be configured so that the resulting library
+    file is placed in a
+    \l{http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html}
+    {framework}, ready for deployment. To do this, set up the project to use the
+    \l{qmake Variable Reference#TEMPLATE}{\c lib template} and add the
+    \c lib_bundle option to the
+    \l{qmake Variable Reference#CONFIG}{CONFIG} variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 16
+
+    The data associated with the library is specified using the
+    \l{qmake Variable Reference#QMAKE_BUNDLE_DATA}{QMAKE_BUNDLE_DATA}
+    variable. This holds items that will be installed with a library
+    bundle, and is often used to specify a collection of header files,
+    as in the following example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 17
+
+    Here, the \c FRAMEWORK_HEADERS variable is a user-defined variable that
+    is used to define the headers required to use a particular framework.
+    Appending it to the \c QMAKE_BUNDLE_DATA variable ensures that the
+    information about these headers are added to the collection of
+    resources that will be installed with the library bundle. Also, the
+    framework's name and version are specified by
+    \l{qmake Variable Reference#QMAKE_FRAMEWORK_BUNDLE_NAME}
+    {QMAKE_FRAMEWORK_BUNDLE_NAME}
+    and \l{qmake Variable Reference#QMAKE_FRAMEWORK_VERSION}
+    {QMAKE_FRAMEWORK_VERSION} variables. By default, the values used for
+    these are obtained from the \l{qmake Variable Reference#TARGET}{TARGET}
+    and \l{qmake Variable Reference#VERSION}{VERSION} variables.
+
+    See \l{Deploying an Application on Mac OS X} for more information about
+    deploying applications and libraries.
+
+    \section2 Creating Universal Binaries
+
+    To create a universal binary for your application, you need to be using
+    a version of Qt that has been configured with the \c{-universal} option.
+
+    The architectures to be supported in the binary are specified with the
+    \l{qmake Variable Reference#CONFIG}{CONFIG} variable. For example, the
+    following assignment causes \c qmake to generate build rules to create
+    a universal binary for both PowerPC and x86 architectures:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 18
+
+    Additionally, developers using a PowerPC-based platform need to set the
+    \l{qmake Variable Reference#QMAKE_MAC_SDK}{QMAKE_MAC_SDK} variable.
+    This process is discussed in more detail in the
+    \l{Deploying an Application on Mac OS X#Architecture Dependencies}{deployment guide for Mac OS X}.
+
+    \section2 Creating and Moving Xcode Projects
+
+    Developers on Mac OS X can take advantage of \c{qmake}'s support for Xcode
+    project files, as described in
+    \l{Qt is Mac OS X Native#Development Tools}{Qt is Mac OS X Native},
+    by running \c qmake to generate an Xcode project from an existing \c qmake
+    project files. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 19
+
+    Note that, if a project is later moved on the disk, \c qmake must be run
+    again to process the project file and create a new Xcode project file.
+
+    \section2 On supporting two build targets simultaneously
+
+    Implementing this is currently not feasible, because the XCode
+    concept of Active Build Configurations is conceptually different
+    from the qmake idea of build targets.
+
+    The XCode Active Build Configurations settings are for modifying
+    xcode configurations, compiler flags and similar build
+    options. Unlike Visual Studio, XCode does not allow for the
+    selection of specific library files based on whether debug or
+    release build configurations are selected. The qmake debug and
+    release settings control which library files are linked to the
+    executable.
+
+    It is currently not possible to set files in XCode configuration
+    settings from the qmake generated xcode project file. The way the
+    libraries are linked in the "Frameworks & Libraries" phase in the
+    XCode build system.
+
+    Furthermore, The selected "Active Build Configuration" is stored
+    in a .pbxuser file, which is generated by xcode on first load, not
+    created by qmake.
+
+    \section1 Windows
+
+    Features specific to this platform include support for creating Visual
+    Studio project files and handling manifest files when deploying Qt
+    applications developed using Visual Studio 2005.
+
+    \section2 Creating Visual Studio Project Files
+
+    Developers using Visual Studio to write Qt applications can use the
+    Visual Studio integration facilities provided with the
+    \l{Qt Commercial Editions} and do not need to worry about how
+    project dependencies are managed.
+
+    However, some developers may need to import an existing \c qmake project
+    into Visual Studio. \c qmake is able to take a project file and create a
+    Visual Studio project that contains all the necessary information required
+    by the development environment. This is achieved by setting the \c qmake
+    \l{qmake Variable Reference#TEMPLATE}{project template} to either \c vcapp
+    (for application projects) or \c vclib (for library projects).
+
+    This can also be set using a command line option, for example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 20
+
+    It is possible to recursively generate \c{.vcproj} files in subdirectories
+    and a \c{.sln} file in the main directory, by typing:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 21
+
+    Each time you update the project file, you need to run \c qmake to generate
+    an updated Visual Studio project.
+
+    \note If you are using the Visual Studio Add-in, you can import \c .pro
+    files via the \gui{Qt->Import from .pro file} menu item.
+
+    \section2 Visual Studio 2005 Manifest Files
+
+    When deploying Qt applications built using Visual Studio 2005, it is
+    necessary to ensure that the manifest file, created when the application
+    was linked, is handled correctly. This is handled automatically for
+    projects that generate DLLs.
+
+    Removing manifest embedding for application executables can be done with
+    the following assignment to the \l{qmake Variable Reference#CONFIG}
+    {CONFIG} variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 22
+
+    Also, the manifest embedding for DLLs can be removed with the following
+    assignment to the \l{qmake Variable Reference#CONFIG}{CONFIG} variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 23
+
+    This is discussed in more detail in the
+    \l{Deploying an Application on Windows#Visual Studio 2005 Onwards}
+    {deployment guide for Windows}.
+*/
+
+/*!
+    \page qmake-reference.html
+    \title qmake Reference
+    \contentspage {qmake Manual}{Contents}
+    \previouspage Using Precompiled Headers
+    \nextpage qmake Variable Reference
+
+    This reference is a detailed index of all the variables and function
+    that are available for use in \c qmake project files.
+
+    \section1 Variable Reference
+
+    The \l{qmake Variable Reference} describes the variables that are
+    recognized by \c qmake when configuring the build process for
+    projects.
+
+    \section1 Function Reference
+
+    The \l{qmake Function Reference} describes the function that can be
+    used to process the contents of variables defined in project files.
+
+    \target FrequentlyUsedVariables
+    \section1 Frequently Used Variables
+
+    The following variables are frequently used in project files to describe
+    common aspects of the build process. These are fully described in the
+    \l{qmake-variable-reference.html}{Variable Reference}.
+
+    \list
+    \o \l{qmake Variable Reference#CONFIG}{CONFIG}
+    \o \l{qmake Variable Reference#DEF_FILE}{DEF_FILE}
+    \o \l{qmake Variable Reference#DEFINES}{DEFINES}
+    \o \l{qmake Variable Reference#DESTDIR}{DESTDIR}
+    \o \l{qmake Variable Reference#DISTFILES}{DISTFILES}
+    \o \l{qmake Variable Reference#DLLDESTDIR}{DLLDESTDIR}
+    \o \l{qmake Variable Reference#FORMS}{FORMS}
+    \o \l{qmake Variable Reference#FORMS3}{FORMS3}
+    \o \l{qmake Variable Reference#GUID}{GUID}
+    \o \l{qmake Variable Reference#HEADERS}{HEADERS}
+    \o \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH}
+    \o \l{qmake Variable Reference#LEXSOURCES}{LEXSOURCES}
+    \o \l{qmake Variable Reference#LIBS}{LIBS}
+    \o \l{qmake Variable Reference#MOC_DIR}{MOC_DIR}
+    \o \l{qmake Variable Reference#OBJECTS_DIR}{OBJECTS_DIR}
+    \o \l{qmake Variable Reference#QT}{QT}
+    \o \l{qmake Variable Reference#RCC_DIR}{RCC_DIR}
+    \o \l{qmake Variable Reference#REQUIRES}{REQUIRES}
+    \o \l{qmake Variable Reference#RESOURCES}{RESOURCES}
+    \o \l{qmake Variable Reference#SOURCES}{SOURCES}
+    \o \l{qmake Variable Reference#SUBDIRS}{SUBDIRS}
+    \o \l{qmake Variable Reference#TARGET}{TARGET}
+    \o \l{qmake Variable Reference#TEMPLATE}{TEMPLATE}
+    \o \l{qmake Variable Reference#TRANSLATIONS}{TRANSLATIONS}
+    \o \l{qmake Variable Reference#UI_DIR}{UI_DIR}
+    \o \l{qmake Variable Reference#UI_HEADERS_DIR}{UI_HEADERS_DIR}
+    \o \l{qmake Variable Reference#UI_SOURCES_DIR}{UI_SOURCES_DIR}
+    \o \l{qmake Variable Reference#VERSION}{VERSION}
+    \o \l{qmake Variable Reference#YACCSOURCES}{YACCSOURCES}
+    \endlist
+
+    \section1 Environment Variables and Configuration
+
+    The \l{Configuring qmake's Environment} chapter of this manual
+    describes the environment variables that \c qmake uses when
+    configuring the build process.
+*/
+
+/*!
+    \page qmake-variable-reference.html
+    \title qmake Variable Reference
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Reference
+    \nextpage qmake Function Reference
+
+    \c{qmake}'s fundamental behavior is influenced by variable declarations that
+    define the build process of each project. Some of these declare resources,
+    such as headers and source files, that are common to each platform; others
+    are used to customize the behavior of compilers and linkers on specific
+    platforms.
+
+    Platform-specific variables follow the naming pattern of the
+    variables which they extend or modify, but include the name of the relevant
+    platform in their name. For example, \c QMAKE_LIBS can be used to specify a list
+    of libraries that a project needs to link against, and \c QMAKE_LIBS_X11 can be
+    used to extend or override this list.
+
+    \tableofcontents{3}
+
+    \target CONFIG
+    \section1 CONFIG
+
+    The \c CONFIG variable specifies project configuration and
+    compiler options.  The values will be recognized internally by
+    \c qmake and have special meaning.  They are as follows.
+
+    These \c CONFIG values control compilation flags:
+
+    \table 95%
+    \header \o Option   \o Description
+    \row    \o release  \o The project is to be built in release mode.
+            This is ignored if \c debug is also specified.
+    \row    \o debug    \o The project is to be built in debug mode.
+    \row    \o debug_and_release \o The project is built in \e both debug and
+            release modes. This can have some unexpected side effects (see
+            below for more information).
+    \row    \o build_all \o If \c debug_and_release is specified, the project is
+            built in both debug and release modes by default.
+    \row    \o ordered  \o When using the \c subdirs template, this option
+            specifies that the directories listed should be processed in the
+            order in which they are given.
+    \row    \o precompile_header \o Enables support for the use of
+            \l{Using Precompiled Headers}{precompiled headers} in projects.
+    \row    \o warn_on  \o The compiler should output as many warnings as possible.
+            This is ignored if \c warn_off is specified.
+    \row    \o warn_off \o The compiler should output as few warnings as possible.
+    \omit
+    \row    \o qt_debug \o Specifies that the project should be built against
+            debug versions of the Qt libraries specified using the
+            \l{#QT}{QT} variable.
+    \row    \o qt_release \o Specifies that the project should be built against
+            release versions of the Qt libraries specified using the
+            \l{#QT}{QT} variable.
+    \endomit
+    \endtable
+
+    Since the \c debug option overrides the \c release option when both are
+    defined in the \c CONFIG variable, it is necessary to use the
+    \c debug_and_release option if you want to allow both debug and release
+    versions of a project to be built. In such a case, the Makefile that
+    \c qmake generates includes a rule that builds both versions, and this can
+    be invoked in the following way:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 24
+
+    When linking a library, \c qmake relies on the underlying platform to know
+    what other libraries this library links against. However, if linking
+    statically, \c qmake will not get this information unless we use the following
+    \c CONFIG options:
+
+     \table 95%
+     \header \o Option   \o Description
+     \row    \o create_prl  \o This option enables \c qmake to track these
+        dependencies. When this option is enabled, \c qmake will create a file
+        ending in \c .prl which will save meta-information about the library
+        (see \l{LibDepend}{Library Dependencies} for more info).
+     \row    \o link_prl    \o When this is enabled, \c qmake will process all
+        libraries linked to by the application and find their meta-information
+        (see \l{LibDepend}{Library Dependencies} for more info).
+     \endtable
+
+    Please note that \c create_prl is required when \e {building} a
+    static library, while \c link_prl is required when \e {using} a
+    static library.
+
+    On Windows (or if Qt is configured with \c{-debug_and_release}, adding the
+    \c build_all option to the \c CONFIG variable makes this rule the default
+    when building the project, and installation targets will be created for
+    both debug and release builds.
+
+    Additionally, adding \c debug_and_release to the \c CONFIG variable will
+    cause both \c debug and \c release to be defined in the contents of
+    \c CONFIG. When the project file is processed, the
+    \l{qmake Advanced Usage#Scopes}{scopes} that test for each value will be
+    processed for \e both debug and release modes. The \c{build_pass} variable
+    will be set for each of these mode, and you can test for this to perform
+    build-specific tasks. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 25
+
+    As a result, it may be useful to define mode-specific variables, such as
+    \l{#QMAKE_LFLAGS_RELEASE}{QMAKE_LFLAGS_RELEASE}, instead of general
+    variables, such as \l{#QMAKE_LFLAGS}{QMAKE_LFLAGS}, where possible.
+
+    The following options define the application/library type:
+
+    \table 95%
+    \header \o Option \o Description
+    \row \o qt \o The target is a Qt application/library and requires the Qt
+         library and header files. The proper include and library paths for the
+         Qt library will automatically be added to the project. This is defined
+         by default, and can be fine-tuned with the \c{\l{#qt}{QT}} variable.
+    \row \o thread \o The target is a multi-threaded application or library.  The
+        proper defines and compiler flags will automatically be added to
+        the project.
+    \row \o x11 \o The target is a X11 application or library. The proper
+        include paths and libraries will automatically be added to the
+        project.
+    \row \o windows \o The target is a Win32 window application (app only). The
+        proper include paths, compiler flags and libraries will
+        automatically be added to the project.
+    \row \o console \o The target is a Win32 console application (app only). The
+        proper include paths, compiler flags and libraries will
+        automatically be added to the
+        project.
+    \row \o shared \o{1,3} The target is a shared object/DLL. The proper
+        include paths, compiler flags and libraries will automatically be
+        added to the project.
+    \row \o dll \o
+    \row \o dylib \o
+    \row \o static \o{1,2} The target is a static library (lib only).  The proper
+        compiler flags will automatically be added to the project.
+    \row \o staticlib \o
+    \row \o plugin \o The target is a plugin (lib only). This enables dll as well.
+    \row \o designer \o The target is a plugin for \QD.
+    \row \o uic3 \o Configures qmake to run uic3 on the content of \c FORMS3 if
+         defined; otherwise the contents of \c FORMS will be processed instead.
+    \row \o no_lflags_merge \o Ensures that the list of libraries stored in the
+         \c LIBS variable is not reduced to a list of unique values before it is used.
+    \row \o resources \o Configures qmake to run rcc on the content of \c RESOURCES
+         if defined.
+    \endtable
+
+    These options are used to set the compiler flags:
+
+    \table 95%
+    \header \o Option \o Description
+    \row \o 3dnow \o AMD 3DNow! instruction support is enabled.
+    \row \o exceptions \o Exception support is enabled.
+    \row \o mmx \o Intel MMX instruction support is enabled.
+    \row \o rtti \o RTTI support is enabled.
+    \row \o stl \o STL support is enabled.
+    \row \o sse \o SSE support is enabled.
+    \row \o sse2 \o SSE2 support is enabled.
+    \endtable
+
+    These options define specific features on Windows only:
+
+    \table 95%
+    \header \o Option \o Description
+    \row \o flat \o When using the vcapp template this will put all the source
+         files into the source group and the header files into the header group
+         regardless of what directory they reside in.  Turning this
+         option off will group the files within the source/header group depending
+         on the directory they reside. This is turned on by default.
+    \row \o embed_manifest_dll \o Embeds a manifest file in the DLL created
+         as part of a library project.
+    \row \o embed_manifest_exe \o Embeds a manifest file in the DLL created
+         as part of an application project.
+    \row \o incremental \o Used to enable or disable incremental linking in Visual
+         C++, depending on whether this feature is enabled or disabled by default.
+    \endtable
+
+    See \l{qmake Platform Notes#Visual Studio 2005 Manifest Files}{qmake Platform Notes}
+    for more information on the options for embedding manifest files.
+
+    These options only have an effect on Mac OS X:
+
+    \table 95%
+    \header \o Option \o Description
+    \row \o ppc \o Builds a PowerPC binary.
+    \row \o x86 \o Builds an i386 compatible binary.
+    \row \o app_bundle \o Puts the executable into a bundle (this is the default).
+    \row \o lib_bundle \o Puts the library into a library bundle.
+    \endtable
+
+    The build process for bundles is also influenced by
+    the contents of the \l{#QMAKE_BUNDLE_DATA}{QMAKE_BUNDLE_DATA} variable.
+
+    These options have an effect on Linux/Unix platforms:
+
+    \table 95%
+    \header \o Option \o Description
+    \row \o largefile \o Includes support for large files.
+    \row \o separate_debug_info \o Puts debugging information for libraries in
+    separate files.
+    \endtable
+
+    The \c CONFIG variable will also be checked when resolving scopes. You may
+    assign anything to this variable.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 26
+
+    \target DEFINES
+    \section1 DEFINES
+
+    \c qmake adds the values of this variable as compiler C
+    preprocessor macros (-D option).
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 27
+
+    \target DEF_FILE
+    \section1 DEF_FILE
+
+    \e {This is only used on Windows when using the \c app template}.
+
+    Specifies a \c .def file to be included in the project.
+
+    \target DEPENDPATH
+    \section1 DEPENDPATH
+
+    This variable contains the list of all directories to look in to
+    resolve dependencies. This will be used when crawling through
+    \c included files.
+
+    \target DEPLOYMENT
+    \section1 DEPLOYMENT
+
+    \e {This is only used on Windows CE.}
+
+    Specifies which additional files will be deployed. Deployment means the
+    transfer of files from the development system to the target device or
+    emulator.
+
+    Files can be deployed by either creating a Visual Studio project or using
+    the \l {Using QTestLib remotely on Windows CE}{cetest} executable.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 28
+
+    This will upload all PNG images in \c path to the same directory your
+    build target will be deployed to.
+
+    The default deployment target path for Windows CE is
+    \c{%CSIDL_PROGRAM_FILES%\target}, which usually gets expanded to
+    \c{\Program Files\target}.
+
+    It is also possible to specify multiple \c sources to be deployed on
+    target \c paths. In addition, different variables can be used for
+    deployment to different directories.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 29
+
+    \note All linked Qt libraries will be deployed to the path specified
+    by \c{myFiles.path}.
+
+    \target DEPLOYMENT_PLUGIN
+    \section1 DEPLOYMENT_PLUGIN
+
+    \e {This is only used on Windows CE.}
+
+    This variable specifies the Qt plugins that will be deployed. All plugins
+    available in Qt can be explicitly deployed to the device. See
+    \l{Static Plugins}{Static Plugins} for a complete list.
+
+    \note No plugins will be deployed automatically. If the application
+    depends on plugins, these plugins have to be specified manually.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 128
+
+    This will upload the jpeg imageformat plugin to the plugins directory
+    on the Windows CE device.
+
+    \target DESTDIR
+    \section1 DESTDIR
+
+    Specifies where to put the \l{#TARGET}{target} file.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 30
+
+    \target DESTDIR_TARGET
+    \section1 DESTDIR_TARGET
+
+    This variable is set internally by \c qmake, which is basically the
+    \c DESTDIR variable with the \c TARGET variable appened at the end.
+    The value of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target DLLDESTDIR
+    \section1 DLLDESTDIR
+
+    Specifies where to copy the \l{#TARGET}{target} dll.
+
+    \target DISTFILES
+    \section1 DISTFILES
+
+    This variable contains a list of files to be included in the dist
+    target. This feature is supported by UnixMake specs only.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 31
+
+    \target DSP_TEMPLATE
+    \section1 DSP_TEMPLATE
+
+    This variable is set internally by \c qmake, which specifies where the
+    dsp template file for basing generated dsp files is stored. The value
+    of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target FORMS
+    \section1 FORMS
+
+    This variable specifies the UI files (see \link
+    designer-manual.html Qt Designer \endlink) to be processed through \c uic
+    before compiling.  All dependencies, headers and source files required
+    to build these UI files will automatically be added to the project.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 32
+
+    If FORMS3 is defined in your project, then this variable must contain
+    forms for uic, and not uic3. If CONFIG contains uic3, and FORMS3 is not
+    defined, the this variable must contain only uic3 type forms.
+
+    \target FORMS3
+    \section1 FORMS3
+
+    This variable specifies the old style UI files to be processed
+    through \c uic3 before compiling, when \c CONFIG contains uic3.
+    All dependencies, headers and source files required to build these
+    UI files will automatically be added to the project.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 33
+
+    \target GUID
+    \section1 GUID
+
+    Specifies the GUID that is set inside a \c{.vcproj} file. The GUID is
+    usually randomly determined. However, should you require a fixed GUID,
+    it can be set using this variable.
+
+    This variable is specific to \c{.vcproj} files only; it is ignored
+    otherwise.
+
+    \target HEADERS
+    \section1 HEADERS
+
+    Defines the header files for the project.
+
+    \c qmake will generate dependency information (unless \c -nodepend
+    is specified on the \l{Running qmake#Commands}{command line})
+    for the specified headers. \c qmake will also automatically detect if
+    \c moc is required by the classes in these headers, and add the
+    appropriate dependencies and files to the project for generating and
+    linking the moc files.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 34
+
+    See also \l{#SOURCES}{SOURCES}.
+
+    \target INCLUDEPATH
+    \section1 INCLUDEPATH
+
+    This variable specifies the #include directories which should be
+    searched when compiling the project. Use ';' or a space as the
+    directory separator.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 35
+
+    To specify a path containing spaces, quote the path using the technique
+    mentioned in the \l{qmake Project Files#Whitespace}{qmake Project Files}
+    document. For example, paths with spaces can be specified on Windows
+    and Unix platforms by using the \l{qmake Function Reference#quote-string}{quote()}
+    function in the following way:
+
+    \snippet doc/src/snippets/qmake/spaces.pro quoting include paths with spaces
+
+    \target INSTALLS
+    \section1 INSTALLS
+
+    This variable contains a list of resources that will be installed when
+    \c{make install} or a similar installation procedure is executed. Each
+    item in the list is typically defined with attributes that provide
+    information about where it will be installed.
+
+    For example, the following \c{target.path} definition describes where the
+    build target will be installed, and the \c INSTALLS assignment adds the
+    build target to the list of existing resources to be installed:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 36
+
+    \target LEXIMPLS
+    \section1 LEXIMPLS
+
+    This variable contains a list of lex implementation files.  The value
+    of this variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely
+    needs to be modified.
+
+    \target LEXOBJECTS
+    \section1 LEXOBJECTS
+
+    This variable contains the names of intermediate lex object
+    files.The value of this variable is typically handled by
+    \c qmake and rarely needs to be modified.
+
+    \target LEXSOURCES
+    \section1 LEXSOURCES
+
+    This variable contains a list of lex source files.  All
+    dependencies, headers and source files will automatically be added to
+    the project for building these lex files.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 37
+
+    \target LIBS
+    \section1 LIBS
+
+    This variable contains a list of libraries to be linked into the project.
+    You can use the Unix \c -l (library) and -L (library path) flags and qmake
+    will do the correct thing with these libraries on Windows (namely this
+    means passing the full path of the library to the linker). The only
+    limitation to this is the library must exist, for qmake to find which
+    directory a \c -l lib lives in.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 38
+
+    To specify a path containing spaces, quote the path using the technique
+    mentioned in the \l{qmake Project Files#Whitespace}{qmake Project Files}
+    document. For example, paths with spaces can be specified on Windows
+    and Unix platforms by using the \l{qmake Function Reference#quote-string}{quote()}
+    function in the following way:
+
+    \snippet doc/src/snippets/qmake/spaces.pro quoting library paths with spaces
+
+    \bold{Note:} On Windows, specifying libraries with the \c{-l} option,
+    as in the above example, will cause the library with the highest version
+    number to be used; for example, \c{libmath2.lib} could potentially be used
+    instead of \c{libmathlib}. To avoid this ambiguity, we recommend that you
+    explicitly specify the library to be used by including the \c{.lib}
+    file name suffix.
+
+    By default, the list of libraries stored in \c LIBS is reduced to a list of
+    unique names before it is used. To change this behavior, add the
+    \c no_lflags_merge option to the \c CONFIG variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 39
+
+    \target LITERAL_HASH
+    \section1 LITERAL_HASH
+
+    This variable is used whenever a literal hash character (\c{#}) is needed in
+    a variable declaration, perhaps as part of a file name or in a string passed
+    to some external application.
+
+    For example:
+
+    \snippet doc/src/snippets/qmake/comments.pro 1
+
+    By using \c LITERAL_HASH in this way, the \c # character can be used
+    to construct a URL for the \c message() function to print to the console.
+
+    \target MAKEFILE
+    \section1 MAKEFILE
+
+    This variable specifies the name of the Makefile which
+    \c qmake should use when outputting the dependency information
+    for building a project.  The value of this variable is typically
+    handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target MAKEFILE_GENERATOR
+    \section1 MAKEFILE_GENERATOR
+
+    This variable contains the name of the Makefile generator to use
+    when generating a Makefile.  The value of this variable is typically
+    handled internally by \c qmake and rarely needs to be modified.
+
+    \target MOC_DIR
+    \section1 MOC_DIR
+
+    This variable specifies the directory where all intermediate moc
+    files should be placed.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 40
+
+    \target OBJECTS
+    \section1 OBJECTS
+
+    This variable is generated from the \link #SOURCES SOURCES
+    \endlink variable.  The extension of each source file will have been
+    replaced by .o (Unix) or .obj (Win32).  The value of this variable is
+    typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+    rarely needs to be modified.
+
+    \target OBJECTS_DIR
+    \section1 OBJECTS_DIR
+
+    This variable specifies the directory where all intermediate
+    objects should be placed.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 41
+
+    \target OBJMOC
+    \section1 OBJMOC
+
+    This variable is set by \c qmake if files can be found that
+    contain the Q_OBJECT macro.  \c OBJMOC contains the
+    name of all intermediate moc object files. The value of this variable
+    is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \target POST_TARGETDEPS
+    \section1 POST_TARGETDEPS
+
+    All libraries that the \l{#TARGET}{target} depends on can be
+    listed in this variable. Some backends do not support this, these include
+    MSVC Dsp, and ProjectBuilder .pbproj files. Generally this is supported
+    internally by these build tools, this is useful for explicitly listing
+    dependant static libraries.
+
+    This list will go after all builtin (and \link #PRE_TARGETDEPS
+    $$PRE_TARGETDEPS \endlink) dependencies.
+
+    \target PRE_TARGETDEPS
+    \section1 PRE_TARGETDEPS
+
+    All libraries that the \l{#TARGET}{target} depends on can be
+    listed in this variable. Some backends do not support this, these include
+    MSVC Dsp, and ProjectBuilder .pbproj files. Generally this is supported
+    internally by these build tools, this is useful for explicitly listing
+    dependant static libraries.
+
+    This list will go before all builtin dependencies.
+
+    \target PRECOMPILED_HEADER
+    \section1 PRECOMPILED_HEADER
+
+    This variable indicates the header file for creating a precompiled
+    header file, to increase the compilation speed of a project.
+    Precompiled headers are currently only supported on some platforms
+    (Windows - all MSVC project types, Mac OS X - Xcode, Makefile,
+    Unix - gcc 3.3 and up).
+
+    On other platforms, this variable has different meaning, as noted
+    below.
+
+    This variable contains a list of header files that require some
+    sort of pre-compilation step (such as with moc). The value of this
+    variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \target PWD
+    \section1 PWD
+
+    This variable contains the full path leading to the directory where
+    the \c qmake project file (project.pro) is located.
+
+    \target OUT_PWD
+    \section1 OUT_PWD
+
+    This variable contains the full path leading to the directory where
+    \c qmake places the generated Makefile.
+
+    \target QMAKE_systemvariable
+    \section1 QMAKE
+
+    This variable contains the name of the \c qmake program
+    itself and is placed in generated Makefiles.  The value of this
+    variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \target QMAKESPEC_systemvariable
+    \section1 QMAKESPEC
+
+    This variable contains the name of the \c qmake
+    configuration to use when generating Makefiles.  The value of this
+    variable is typically handled by \c qmake and rarely needs to be modified.
+
+    Use the \c{QMAKESPEC} environment variable to override the \c qmake configuration.
+    Note that, due to the way \c qmake reads project files, setting the \c{QMAKESPEC}
+    environment variable from within a project file will have no effect.
+
+    \target QMAKE_APP_FLAG
+    \section1 QMAKE_APP_FLAG
+
+    This variable is empty unless the \c app
+    \l{#TEMPLATE}{TEMPLATE} is specified.  The value of this
+    variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.  Use the following instead:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 42
+
+    \target QMAKE_APP_OR_DLL
+    \section1 QMAKE_APP_OR_DLL
+
+    This variable is empty unless the \c app or \c dll
+    \l{#TEMPLATE}{TEMPLATE} is specified.  The value of this
+    variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \target QMAKE_AR_CMD
+    \section1 QMAKE_AR_CMD
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains the command for invoking the program which
+    creates, modifies and extracts archives. The value of this variable is
+    typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+    and rarely needs to be modified.
+
+    \target QMAKE_BUNDLE_DATA
+    \section1 QMAKE_BUNDLE_DATA
+
+    This variable is used to hold the data that will be installed with a library
+    bundle, and is often used to specify a collection of header files.
+
+    For example, the following lines add \c path/to/header_one.h
+    and \c path/to/header_two.h to a group containing information about the
+    headers supplied with the framework:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 43
+
+    The last line adds the information about the headers to the collection of
+    resources that will be installed with the library bundle.
+
+    Library bundles are created when the \c lib_bundle option is added to the
+    \l{#CONFIG}{CONFIG} variable.
+
+    See \l{qmake Platform Notes#Creating Frameworks}{qmake Platform Notes} for
+    more information about creating library bundles.
+
+    \e{This is used on Mac OS X only.}
+
+    \section1 QMAKE_BUNDLE_EXTENSION
+
+    This variable defines the extension to be used for library bundles.
+    This allows frameworks to be created with custom extensions instead of the
+    standard \c{.framework} directory name extension.
+
+    For example, the following definition will result in a framework with the
+    \c{.myframework} extension:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 44
+
+    \e{This is used on Mac OS X only.}
+
+    \section1 QMAKE_CC
+
+    This variable specifies the C compiler that will be used when building
+    projects containing C source code. Only the file name of the compiler
+    executable needs to be specified as long as it is on a path contained
+    in the \c PATH variable when the Makefile is processed.
+
+    \target QMAKE_CFLAGS_DEBUG
+    \section1 QMAKE_CFLAGS_DEBUG
+
+    This variable contains the flags for the C compiler in debug mode.The value of this variable is
+    typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+    and rarely needs to be modified.
+
+    \target QMAKE_CFLAGS_MT
+    \section1 QMAKE_CFLAGS_MT
+
+    This variable contains the compiler flags for creating a
+    multi-threaded application or when the version of Qt that you link
+    against is a multi-threaded statically linked library.  The value of
+    this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_CFLAGS_MT_DBG
+    \section1 QMAKE_CFLAGS_MT_DBG
+
+    This variable contains the compiler flags for creating a debuggable
+    multi-threaded application or when the version of Qt that you link
+    against is a debuggable multi-threaded statically linked library.  The
+    value of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_CFLAGS_MT_DLL
+    \section1 QMAKE_CFLAGS_MT_DLL
+
+    \e {This is used on Windows only.}
+
+    This variable contains the compiler flags for creating a
+    multi-threaded dll or when the version of Qt that you link
+    against is a multi-threaded dll.  The value of this variable is typically
+    handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+    rarely needs to be modified.
+
+    \target QMAKE_CFLAGS_MT_DLLDBG
+    \section1 QMAKE_CFLAGS_MT_DLLDBG
+
+    \e {This is used on Windows only.}
+
+    This variable contains the compiler flags for creating a debuggable
+    multi-threaded dll or when the version of Qt that you link
+    against is a debuggable multi-threaded statically linked library.
+    The value of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_CFLAGS_RELEASE
+    \section1 QMAKE_CFLAGS_RELEASE
+
+    This variable contains the compiler flags for creating a non-debuggable
+    application.  The value of this variable is typically
+    handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+    rarely needs to be modified.
+
+    \target QMAKE_CFLAGS_SHLIB
+    \section1 QMAKE_CFLAGS_SHLIB
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains the compiler flags for creating a shared
+    library. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CFLAGS_THREAD
+    \section1 QMAKE_CFLAGS_THREAD
+
+    This variable contains the compiler flags for creating a multi-threaded
+    application. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CFLAGS_WARN_OFF
+    \section1 QMAKE_CFLAGS_WARN_OFF
+
+    This variable is not empty if the warn_off
+    \l{#TEMPLATE}{TEMPLATE} option is specified.  The value of this
+    variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+    and rarely needs to be modified.
+
+    \target QMAKE_CFLAGS_WARN_ON
+    \section1 QMAKE_CFLAGS_WARN_ON
+
+    This variable is not empty if the warn_on
+    \l{#TEMPLATE}{TEMPLATE} option is specified.
+    The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CLEAN
+    \section1 QMAKE_CLEAN
+
+    This variable contains any files which are not generated files (such as moc and uic
+    generated files) and object files that should be removed when using "make clean".
+
+    \section1 QMAKE_CXX
+
+    This variable specifies the C++ compiler that will be used when building
+    projects containing C++ source code. Only the file name of the compiler
+    executable needs to be specified as long as it is on a path contained
+    in the \c PATH variable when the Makefile is processed.
+
+    \section1 QMAKE_CXXFLAGS
+
+    This variable contains the C++ compiler flags that are used when building
+    a project. The value of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified. The flags
+    specific to debug and release modes can be adjusted by modifying
+    the \c QMAKE_CXXFLAGS_DEBUG and \c QMAKE_CXXFLAGS_RELEASE variables,
+    respectively.
+
+    \target QMAKE_CXXFLAGS_DEBUG
+    \section1 QMAKE_CXXFLAGS_DEBUG
+
+    This variable contains the C++ compiler flags for creating a debuggable
+    application. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_MT
+    \section1 QMAKE_CXXFLAGS_MT
+
+    This variable contains the C++ compiler flags for creating a multi-threaded
+    application. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_MT_DBG
+    \section1 QMAKE_CXXFLAGS_MT_DBG
+
+    This variable contains the C++ compiler flags for creating a debuggable multi-threaded
+    application. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_MT_DLL
+    \section1 QMAKE_CXXFLAGS_MT_DLL
+
+    \c {This is used on Windows only.}
+
+    This variable contains the C++ compiler flags for creating a multi-threaded
+    dll. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_MT_DLLDBG
+    \section1 QMAKE_CXXFLAGS_MT_DLLDBG
+
+    \c {This is used on Windows only.}
+
+    This variable contains the C++ compiler flags for creating a multi-threaded debuggable
+    dll. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_RELEASE
+    \section1 QMAKE_CXXFLAGS_RELEASE
+
+    This variable contains the C++ compiler flags for creating an
+    application. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_SHLIB
+    \section1 QMAKE_CXXFLAGS_SHLIB
+
+    This variable contains the C++ compiler flags for creating a
+    shared library.  The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_THREAD
+    \section1 QMAKE_CXXFLAGS_THREAD
+
+    This variable contains the C++ compiler flags for creating a
+    multi-threaded application.  The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+    to be modified.
+
+    \target QMAKE_CXXFLAGS_WARN_OFF
+    \section1 QMAKE_CXXFLAGS_WARN_OFF
+
+    This variable contains the C++ compiler flags for suppressing compiler warnings.
+    The value of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_CXXFLAGS_WARN_ON
+    \section1 QMAKE_CXXFLAGS_WARN_ON
+
+    This variable contains C++ compiler flags for generating compiler warnings.
+    The value of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_DISTCLEAN
+    \section1 QMAKE_DISTCLEAN
+
+    This variable removes extra files upon the invocation of \c{make distclean}.
+
+    \target QMAKE_EXTENSION_SHLIB
+    \section1 QMAKE_EXTENSION_SHLIB
+
+    This variable contains the extention for shared libraries.  The value of this
+    variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+    and rarely needs to be modified.
+
+    Note that platform-specific variables that change the extension will override
+    the contents of this variable.
+
+    \section1 QMAKE_EXT_MOC
+
+    This variable changes the extention used on included moc files.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+    \section1 QMAKE_EXT_UI
+
+    This variable changes the extention used on /e Designer UI files.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+    \section1 QMAKE_EXT_PRL
+
+    This variable changes the extention used on created PRL files.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions},
+             \l{Configuring qmake's Environment#libdepend}{Library Dependencies}.
+
+    \section1 QMAKE_EXT_LEX
+
+    This variable changes the extention used on files given to lex.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions},
+             \l{#LEXSOURCES}{LEXSOURCES}.
+
+    \section1 QMAKE_EXT_YACC
+    This variable changes the extention used on files given to yacc.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions},
+             \l{#YACCSOURCES}{YACCSOURCES}.
+
+    \section1 QMAKE_EXT_OBJ
+
+    This variable changes the extention used on generated object files.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+    \section1 QMAKE_EXT_CPP
+
+    This variable changes the interpretation of all suffixes in this
+    list of values as files of type C++ source code.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+    \section1 QMAKE_EXT_H
+
+    This variable changes the interpretation of all suffixes in this
+    list of values as files of type C header files.
+
+    See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+        \section1 QMAKE_EXTRA_COMPILERS
+
+        This variable contains the extra compilers/preprocessors that have been added
+
+        See also \l{Configuring qmake's Environment#Customizing}{Customizing Makefile Output}
+
+        \section1 QMAKE_EXTRA_TARGETS
+
+        This variable contains the extra targets that have been added
+
+        See also \l{Configuring qmake's Environment#Customizing}{Customizing Makefile Output}
+
+    \target QMAKE_FAILED_REQUIREMENTS
+    \section1 QMAKE_FAILED_REQUIREMENTS
+
+    This variable contains the list of requirements that were failed to be met when
+    \c qmake was used.  For example, the sql module is needed and wasn't compiled into Qt.  The
+    value of this variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+    and rarely needs to be modified.
+
+    \target QMAKE_FILETAGS
+    \section1 QMAKE_FILETAGS
+
+    This variable contains the file tags needed to be entered into the Makefile, such as SOURCES
+    and HEADERS.  The value of this variable is typically handled by \c qmake or
+    \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_FRAMEWORK_BUNDLE_NAME
+
+    In a framework project, this variable contains the name to be used for the
+    framework that is built.
+
+    By default, this variable contains the same value as the \l{#TARGET}{TARGET}
+    variable.
+
+    See \l{qmake Platform Notes#Creating Frameworks}{qmake Platform Notes} for
+    more information about creating frameworks and library bundles.
+
+    \e{This is used on Mac OS X only.}
+
+    \target QMAKE_FRAMEWORK_VERSION
+    \section1 QMAKE_FRAMEWORK_VERSION
+
+    For projects where the build target is a Mac OS X framework, this variable
+    is used to specify the version number that will be applied to the framework
+    that is built.
+
+    By default, this variable contains the same value as the \l{#VERSION}{VERSION}
+    variable.
+
+    See \l{qmake Platform Notes#Creating Frameworks}{qmake Platform Notes} for
+    more information about creating frameworks.
+
+    \e{This is used on Mac OS X only.}
+
+    \target QMAKE_INCDIR
+    \section1 QMAKE_INCDIR
+
+    This variable contains the location of all known header files to be added to
+    INCLUDEPATH when building an application.  The value of this variable is
+    typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely
+    needs to be modified.
+
+    \target QMAKE_INCDIR_EGL
+    \section1 QMAKE_INCDIR_EGL
+
+    This variable contains the location of EGL header files to be added
+    to INCLUDEPATH when building an application with OpenGL/ES or
+    OpenVG support. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_INCDIR_OPENGL
+    \section1 QMAKE_INCDIR_OPENGL
+
+    This variable contains the location of OpenGL header files to be added
+    to INCLUDEPATH when building an application with OpenGL support. The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    If the OpenGL implementation uses EGL (most OpenGL/ES systems),
+    then QMAKE_INCDIR_EGL may also need to be set.
+
+    \target QMAKE_INCDIR_OPENVG
+    \section1 QMAKE_INCDIR_OPENVG
+
+    This variable contains the location of OpenVG header files to be added
+    to INCLUDEPATH when building an application with OpenVG support. The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    If the OpenVG implementation uses EGL then QMAKE_INCDIR_EGL may also
+    need to be set.
+
+    \target QMAKE_INCDIR_QT
+    \section1 QMAKE_INCDIR_QT
+
+    This variable contains the location of all known header file
+    paths to be added to INCLUDEPATH when building a Qt application. The value
+    of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_INCDIR_THREAD
+    \section1 QMAKE_INCDIR_THREAD
+
+    This variable contains the location of all known header file
+    paths to be added to INCLUDEPATH when building a multi-threaded application.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_INCDIR_X11
+    \section1 QMAKE_INCDIR_X11
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains the location of X11 header file paths to be
+    added to INCLUDEPATH when building a X11 application.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target QMAKE_INFO_PLIST
+    \section1 QMAKE_INFO_PLIST
+
+    \e {This is used on Mac OS X platforms only.}
+
+    This variable contains the name of the property list file, \c{.plist}, you
+    would like to include in your Mac OS X application bundle.
+
+    In the \c{.plist} file, you can define some variables, e.g., @EXECUTABLE@,
+    which qmake will replace with the actual executable name. Other variables
+    include @ICON@, @TYPEINFO@, @LIBRARY@, and @SHORT_VERSION@.
+
+    \note Most of the time, the default \c{Info.plist} is good enough.
+
+    \section1 QMAKE_LFLAGS
+
+    This variable contains a general set of flags that are passed to
+    the linker. If you need to change the flags used for a particular
+    platform or type of project, use one of the specialized variables
+    for that purpose instead of this variable.
+
+    \target QMAKE_LFLAGS_CONSOLE
+    \section1 QMAKE_LFLAGS_CONSOLE
+
+    \e {This is used on Windows only.}
+
+    This variable contains link flags when building console
+    programs.  The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_CONSOLE_DLL
+
+    \e {This is used on Windows only.}
+
+    This variable contains link flags when building console
+    dlls.  The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_DEBUG
+
+    This variable contains link flags when building debuggable applications.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_PLUGIN
+
+    This variable contains link flags when building plugins. The value
+    of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_QT_DLL
+
+    This variable contains link flags when building programs that
+    use the Qt library built as a dll. The value of this variable is
+    typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_RELEASE
+
+    This variable contains link flags when building applications for
+    release. The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_SHAPP
+
+    This variable contains link flags when building applications which are using
+    the \c app template.  The value of this variable is typically handled by
+    \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_SHLIB
+
+    This variable contains link flags when building shared libraries
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_SONAME
+
+    This variable specifies the link flags to set the name of shared objects,
+    such as .so or .dll.  The value of this variable is typically handled by \c
+    qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_THREAD
+
+    This variable contains link flags when building multi-threaded projects.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_WINDOWS
+
+    \e {This is used on Windows only.}
+
+    This variable contains link flags when building Windows GUI projects
+    (i.e. non-console applications).
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LFLAGS_WINDOWS_DLL
+
+    \e {This is used on Windows only.}
+
+    This variable contains link flags when building Windows DLL projects.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBDIR
+
+    This variable contains the location of all known library
+    directories.The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBDIR_FLAGS
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains the location of all library
+    directory with -L prefixed.  The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBDIR_EGL
+
+    This variable contains the location of the EGL library
+    directory, when EGL is used with OpenGL/ES or OpenVG. The value
+    of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBDIR_OPENGL
+
+    This variable contains the location of the OpenGL library
+    directory.The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    If the OpenGL implementation uses EGL (most OpenGL/ES systems),
+    then QMAKE_LIBDIR_EGL may also need to be set.
+
+    \section1 QMAKE_LIBDIR_OPENVG
+
+    This variable contains the location of the OpenVG library
+    directory. The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    If the OpenVG implementation uses EGL, then QMAKE_LIBDIR_EGL
+    may also need to be set.
+
+    \section1 QMAKE_LIBDIR_QT
+
+    This variable contains the location of the Qt library
+    directory.The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBDIR_X11
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains the location of the X11 library
+    directory.The value of this variable is typically handled by
+    \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS
+
+    This variable contains all project libraries.  The value of this
+    variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_CONSOLE
+
+    \e {This Windows-specific variable is no longer used.}
+
+    Prior to Qt 4.2, this variable was used to list the libraries
+    that should be linked against when building a console application
+    project on Windows. \l{#QMAKE_LIBS_WINDOW}{QMAKE_LIBS_WINDOW}
+    should now be used instead.
+
+    \section1 QMAKE_LIBS_EGL
+
+    This variable contains all EGL libraries when building Qt with
+    OpenGL/ES or OpenVG.  The value of this variable is typically
+    handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely
+    needs to be modified.  The usual value is \c{-lEGL}.
+
+    \section1 QMAKE_LIBS_OPENGL
+
+    This variable contains all OpenGL libraries.  The value of this
+    variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    If the OpenGL implementation uses EGL (most OpenGL/ES systems),
+    then QMAKE_LIBS_EGL may also need to be set.
+
+    \section1 QMAKE_LIBS_OPENGL_QT
+
+    This variable contains all OpenGL Qt libraries.The value of this
+    variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_OPENVG
+
+    This variable contains all OpenVG libraries.  The value of this
+    variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+    and rarely needs to be modified.  The usual value is \c{-lOpenVG}.
+
+    Some OpenVG engines are implemented on top of OpenGL.  This will
+    be detected at configure time and QMAKE_LIBS_OPENGL will be implicitly
+    added to QMAKE_LIBS_OPENVG wherever the OpenVG libraries are linked.
+
+    If the OpenVG implementation uses EGL, then QMAKE_LIBS_EGL may also
+    need to be set.
+
+    \section1 QMAKE_LIBS_QT
+
+    This variable contains all Qt libraries.The value of this
+    variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_QT_DLL
+
+    \e {This is used on Windows only.}
+
+    This variable contains all Qt libraries when Qt is built as a dll.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_QT_OPENGL
+
+    This variable contains all the libraries needed to link against if
+    OpenGL support is turned on. The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_QT_THREAD
+
+    This variable contains all the libraries needed to link against if
+    thread support is turned on.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_RT
+
+    \e {This is used with Borland compilers only.}
+
+    This variable contains the runtime library needed to link against when
+    building an application.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_RTMT
+
+    \e {This is used with Borland compilers only.}
+
+    This variable contains the runtime library needed to link against when
+    building a multi-threaded application.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_THREAD
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains all libraries that need to be linked against
+    when building a multi-threaded application.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_WINDOWS
+
+    \e {This is used on Windows only.}
+
+    This variable contains all windows libraries.The value of this
+    variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_X11
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains all X11 libraries.The value of this
+    variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIBS_X11SM
+
+    \e {This is used on Unix platforms only.}
+
+    This variable contains all X11 session management libraries.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LIB_FLAG
+
+    This variable is not empty if the \c lib template is specified.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_LINK_SHLIB_CMD
+
+    This variable contains the command to execute when creating a
+    shared library. The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_POST_LINK
+
+    This variable contains the command to execute after linking the TARGET
+    together. This variable is normally empty and therefore nothing is
+    executed, additionally some backends will not support this - mostly only
+    Makefile backends.
+
+    \section1 QMAKE_PRE_LINK
+
+    This variable contains the command to execute before linking the TARGET
+    together. This variable is normally empty and therefore nothing is
+    executed, additionally some backends will not support this - mostly only
+    Makefile backends.
+
+    \section1 QMAKE_LN_SHLIB
+
+    This variable contains the command to execute when creating a link
+    to a shared library. The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_MAC_SDK
+
+    This variable is used on Mac OS X when building universal binaries.
+    This process is described in more detail in the
+    \l{Deploying an Application on Mac OS X#Architecture Dependencies}{Deploying
+    an Application on Mac OS X} document.
+
+    \section1 QMAKE_MACOSX_DEPLOYMENT_TARGET
+    This variable only has an effect when building on Mac OS X. On that
+    platform, the variable will be forwarded to the MACOSX_DEPLOYMENT_TARGET
+    environment variable, which is interpreted by the compiler or linker.
+    For more information, see the
+    \l{Deploying an Application on Mac OS X#Mac OS X Version Dependencies}{Deploying
+    an Application on Mac OS X} document.
+
+    \section1 QMAKE_MAKEFILE
+
+    This variable contains the name of the Makefile to create. The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_MOC_SRC
+
+    This variable contains the names of all moc source files to
+    generate and include in the project. The value of this variable is
+    typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_QMAKE
+
+    This variable contains the location of qmake if it is not in the path.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_QT_DLL
+
+    This variable is not empty if Qt was built as a dll.  The
+    value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_RESOURCE_FLAGS
+
+    This variable is used to customize the list of options passed to the
+    \l{rcc}{Resource Compiler} in each of the build rules where it is used.
+    For example, the following line ensures that the \c{-threshold} and
+    \c{-compress} options are used with particular values each time that
+    \c rcc is invoked:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 45
+
+    \section1 QMAKE_RUN_CC
+
+    This variable specifies the individual rule needed to build an object.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_RUN_CC_IMP
+
+    This variable specifies the individual rule needed to build an object.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_RUN_CXX
+
+    This variable specifies the individual rule needed to build an object.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_RUN_CXX_IMP
+
+    This variable specifies the individual rule needed to build an object.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_TARGET
+
+    This variable contains the name of the project target.  The value of
+    this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 QMAKE_UIC
+
+    This variable contains the location of uic if it is not in the path.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    It can be used to specify arguments to uic as well, such as additional plugin
+    paths.  For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 46
+
+    \section1 QT
+
+    The values stored in the \c QT variable control which of the Qt modules are
+    used by your project.
+
+    The table below shows the options that can be used with the \c QT variable
+    and the features that are associated with each of them:
+
+    \table
+    \header \o Option                     \o Features
+    \row    \o core (included by default) \o QtCore module
+    \row    \o gui  (included by default) \o QtGui module
+    \row    \o network                    \o QtNetwork module
+    \row    \o opengl                     \o QtOpenGL module
+    \row    \o phonon                     \o Phonon Multimedia Framework
+    \row    \o sql                        \o QtSql module
+    \row    \o svg                        \o QtSvg module
+    \row    \o xml                        \o QtXml module
+    \row    \o webkit                     \o WebKit integration
+    \row    \o qt3support                 \o Qt3Support module
+    \endtable
+
+    By default, \c QT contains both \c core and \c gui, ensuring that standard
+    GUI applications can be built without further configuration.
+
+    If you want to build a project \e without the QtGui module, you need to
+    exclude the \c gui value with the "-=" operator; the following line will
+    result in a minimal Qt project being built:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 47
+
+    Note that adding the \c opengl option to the \c QT variable automatically
+    causes the equivalent option to be added to the \c CONFIG variable.
+    Therefore, for Qt applications, it is not necessary to add the \c opengl
+    option to both \c CONFIG and \c{QT}.
+
+    \section1 QTPLUGIN
+
+    This variable contains a list of names of static plugins that are to be
+    compiled with an application so that they are available as built-in
+    resources.
+
+    \target QT_VERSION
+    \section1 QT_VERSION
+
+    This variable contains the current version of Qt.
+
+    \target QT_MAJOR_VERSION
+    \section1 QT_MAJOR_VERSION
+
+    This variable contains the current major version of Qt.
+
+    \target QT_MINOR_VERSION
+    \section1 QT_MINOR_VERSION
+
+    This variable contains the current minor version of Qt.
+
+    \target QT_PATCH_VERSION
+    \section1 QT_PATCH_VERSION
+
+    This variable contains the current patch version of Qt.
+
+    \section1 RC_FILE
+
+    This variable contains the name of the resource file for the application.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target RCC_DIR
+    \section1 RCC_DIR
+
+    This variable specifies the directory where all intermediate
+    resource files should be placed.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 48
+
+    \target REQUIRES
+    \section1 REQUIRES
+
+    This is a special variable processed by \c qmake.  If the
+    contents of this variable do not appear in CONFIG by the time this
+    variable is assigned, then a minimal Makefile will be generated that
+    states what dependencies (the values assigned to REQUIRES) are
+    missing.
+
+    This is mainly used in Qt's build system for building the examples.
+
+    \section1 RESOURCES
+
+    This variable contains the name of the resource collection file (qrc) 
+    for the application. Further information about the resource collection
+    file can be found at \l{The Qt Resource System}.
+
+    \section1 RES_FILE
+
+    This variable contains the name of the resource file for the application.
+    The value of this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target SIGNATURE_FILE
+    \section1 SIGNATURE_FILE
+
+    \e {This is only used on Windows CE.}
+
+    Specifies which signature file should be used to sign the project target.
+
+    \note This variable will overwrite the setting you have specified in configure,
+    with the \c -signature option.
+
+    \target SOURCES
+    \section1 SOURCES
+
+    This variable contains the name of all source files in the project.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 49
+
+    See also \l{#HEADERS}{HEADERS}
+
+    \section1 SRCMOC
+
+    This variable is set by \c qmake if files can be found that
+    contain the Q_OBJECT macro.  \c SRCMOC contains the
+    name of all the generated moc files. The value of this variable
+    is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \target SUBDIRS
+    \section1 SUBDIRS
+
+    This variable, when used with the \l{#TEMPLATE}{\c subdirs template}
+    contains the names of all subdirectories that contain parts of the project
+    that need be built. Each subdirectory must contain its own project file.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 50
+
+    It is essential that the project file in each subdirectory has the same
+    name as the subdirectory itself, so that \c qmake can find it.
+    For example, if the subdirectory is called \c myapp then the project file
+    in that directory should be called \c myapp.pro.
+
+    If you need to ensure that the subdirectories are built in the order in
+    which they are specified, update the \l{#CONFIG}{CONFIG} variable to
+    include the \c ordered option:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 51
+
+    \target TARGET
+    \section1 TARGET
+
+    This specifies the name of the target file.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 52
+
+    The project file above would produce an executable named \c myapp on
+    unix and 'myapp.exe' on windows.
+
+    \section1 TARGET_EXT
+
+    This variable specifies the target's extension.  The value of this variable
+    is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \section1 TARGET_x
+
+    This variable specifies the target's extension with a major version number.  The value of this variable
+    is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \section1 TARGET_x.y.z
+
+    This variable specifies the target's extension with version number.  The value of this variable
+    is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \target TEMPLATE
+    \section1 TEMPLATE
+
+    This variable contains the name of the template to use when
+    generating the project.  The allowed values are:
+
+    \table
+    \header \o Option \o Description
+    \row    \o app    \o Creates a Makefile for building applications (the default). (See
+            \l{qmake Common Projects#Application}{qmake Common Projects} for more information.)
+    \row    \o lib    \o Creates a Makefile for building libraries. (See
+            \l{qmake Common Projects#Library}{qmake Common Projects} for more information.)
+    \row    \o subdirs \o Creates a Makefile for building targets in subdirectories.
+            The subdirectories are specified using the \l{#SUBDIRS}{SUBDIRS}
+            variable.
+    \row    \o vcapp  \o \e {Windows only} Creates an application project for Visual Studio.
+            (See \l{qmake Platform Notes#Creating Visual Studio Project Files}{qmake Platform Notes}
+            for more information.)
+    \row    \o vclib  \o \e {Windows only} Creates a library project for Visual Studio.
+            (See \l{qmake Platform Notes#Creating Visual Studio Project Files}{qmake Platform Notes}
+            for more information.)
+    \endtable
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 53
+
+    The template can be overridden by specifying a new template type with the
+    \c -t command line option. This overrides the template type \e after the .pro
+    file has been processed. With .pro files that use the template type to
+    determine how the project is built, it is necessary to declare TEMPLATE on
+    the command line rather than use the \c -t option.
+
+    \section1 TRANSLATIONS
+
+    This variable contains a list of translation (.ts) files that contain
+    translations of the user interface text into non-native languages.
+
+    See the \l{Qt Linguist Manual} for more information about
+    internationalization (i18n) and localization (l10n) with Qt.
+
+    \section1 UICIMPLS
+
+    This variable contains a list of the generated implementation files by UIC.
+    The value of this variable
+    is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+    modified.
+
+    \section1 UICOBJECTS
+
+    This variable is generated from the UICIMPLS variable.  The extension of each
+    file will have been replaced by .o (Unix) or .obj (Win32).  The value of this variable is
+    typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+    rarely needs to be modified.
+
+    \target UI_DIR
+    \section1 UI_DIR
+
+    This variable specifies the directory where all intermediate files from uic
+    should be placed. This variable overrides both UI_SOURCES_DIR and
+    UI_HEADERS_DIR.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 54
+
+    \target UI_HEADERS_DIR
+    \section1 UI_HEADERS_DIR
+
+    This variable specifies the directory where all declaration files (as
+    generated by uic) should be placed.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 55
+
+    \target UI_SOURCES_DIR
+    \section1 UI_SOURCES_DIR
+
+    This variable specifies the directory where all implementation files (as generated
+    by uic) should be placed.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 56
+
+    \target VERSION
+    \section1 VERSION
+
+    This variable contains the version number of the application or library if
+    either the \c app \l{#TEMPLATE}{TEMPLATE} or the \c lib \l{#TEMPLATE}{TEMPLATE}
+    is specified.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 57
+
+    \section1 VER_MAJ
+
+    This variable contains the major version number of the library, if the
+    \c lib \l{#TEMPLATE}{template} is specified.
+
+    \section1 VER_MIN
+
+    This variable contains the minor version number of the library, if the
+    \c lib \l{#TEMPLATE}{template} is specified.
+
+    \section1 VER_PAT
+
+    This variable contains the patch version number of the library, if the
+    \c lib \l{#TEMPLATE}{template} is specified.
+
+    \section1 VPATH
+
+    This variable tells \c qmake where to search for files it cannot
+    open. With this you may tell \c qmake where it may look for things
+    like SOURCES, and if it finds an entry in SOURCES that cannot be
+    opened it will look through the entire VPATH list to see if it can
+    find the file on its own.
+
+    See also \l{#DEPENDPATH}{DEPENDPATH}.
+
+    \section1 YACCIMPLS
+
+    This variable contains a list of yacc source files. The value of
+    this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \section1 YACCOBJECTS
+
+    This variable contains a list of yacc object files. The value of
+    this variable is typically handled by \c qmake or
+     \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+    \target YACCSOURCES
+    \section1 YACCSOURCES
+
+    This variable contains a list of yacc source files to be included
+    in the project.  All dependencies, headers and source files will
+    automatically be included in the project.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 58
+
+    \section1 _PRO_FILE_
+
+    This variable contains the path to the project file in use.
+
+    For example, the following line causes the location of the project
+    file to be written to the console:
+
+    \snippet doc/src/snippets/qmake/project_location.pro project file
+
+    \section1 _PRO_FILE_PWD_
+
+    This variable contains the path to the directory containing the project
+    file in use.
+
+    For example, the following line causes the location of the directory
+    containing the project file to be written to the console:
+
+    \snippet doc/src/snippets/qmake/project_location.pro project file directory
+*/
+
+/*!
+    \page qmake-function-reference.html
+    \title qmake Function Reference
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Variable Reference
+    \nextpage Configuring qmake's Environment
+
+    \c qmake provides built-in functions to allow the contents of
+    variables to be processed, and to enable tests to be performed
+    during the configuration process. Functions that process the
+    contents of variables typically return values that can be assigned
+    to other variables, and these values are obtained by prefixing
+    function with the \c $$ operator. Functions that perform tests
+    are usually used as the conditional parts of scopes; these are
+    indicated in the function descriptions below.
+
+    \tableofcontents{2}
+
+    \section1 basename(variablename)
+
+    Returns the basename of the file specified. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 59
+
+    \section1 CONFIG(config)
+    [Conditional]
+
+    This function can be used to test for variables placed into the
+    \c CONFIG variable. This is the same as regular old style (tmake) scopes,
+    but has the added advantage a second parameter can be passed to test for
+    the active config. As the order of values is important in \c CONFIG
+    variables (i.e. the last one set will be considered the active config for
+    mutually exclusive values) a second parameter can be used to specify a set
+    of values to consider. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 60
+
+    Because release is considered the active setting (for feature parsing)
+    it will be the CONFIG used to generate the build file. In the common
+    case a second parameter is not needed, but for specific mutual
+    exclusive tests it is invaluable.
+
+    \section1 contains(variablename, value)
+    [Conditional]
+
+    Succeeds if the variable \e variablename contains the value \e value;
+    otherwise fails. You can check the return value of this function using
+    a scope.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 61
+
+    The contents of the scope are only processed if the \c drivers
+    variable contains the value, \c network. If this is the case, the
+    appropriate files are added to the \c SOURCES and \c HEADERS
+    variables.
+
+    \section1 count(variablename, number)
+    [Conditional]
+
+    Succeeds if the variable \e variablename contains a list with the
+    specified \e number of value; otherwise fails.
+
+    This function is used to ensure that declarations inside a scope are
+    only processed if the variable contains the correct number of values;
+    for example:
+
+    \snippet doc/src/snippets/qmake/functions.pro 2
+
+    \section1 dirname(file)
+
+    Returns the directory name part of the specified file. For example:
+
+    \snippet doc/src/snippets/qmake/dirname.pro 0
+
+    \section1 error(string)
+
+    This function never returns a value. \c qmake displays the given
+    \e string to the user, and exits. This function should only be used
+    for unrecoverable errors.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 62
+
+    \section1 eval(string)
+    [Conditional]
+
+    Evaluates the contents of the string using \c qmake's syntax rules
+    and returns true.
+    Definitions and assignments can be used in the string to modify the
+    values of existing variables or create new definitions.
+
+    For example:
+    \snippet doc/src/snippets/qmake/functions.pro 4
+
+    Note that quotation marks can be used to delimit the string, and that
+    the return value can be discarded if it is not needed.
+
+    \section1 exists(filename)
+    [Conditional]
+
+    Tests whether a file with the given \e filename exists.
+    If the file exists, the function succeeds; otherwise it fails.
+    If a regular expression is specified for the filename, this function
+    succeeds if any file matches the regular expression specified.
+
+    For example:
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 63
+
+    Note that "/" can be used as a directory separator, regardless of the
+    platform in use.
+
+    \section1 find(variablename, substr)
+
+    Places all the values in \e variablename that match \e substr. \e
+    substr may be a regular expression, and will be matched accordingly.
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 64
+
+    MY_VAR2 will contain '-Lone -Ltwo -Lthree -Lfour -Lfive', and MY_VAR3 will
+    contains 'three two three'.
+
+    \section1 for(iterate, list)
+
+    This special test function will cause a loop to be started that
+    iterates over all values in \e list, setting \e iterate to each
+    value in turn. As a convenience, if \e list is 1..10 then iterate will
+    iterate over the values 1 through 10.
+
+    The use of an else scope afer a condition line with a for() loop is
+    disallowed.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 65
+
+    \section1 include(filename)
+    [Conditional]
+
+    Includes the contents of the file specified by \e filename into the
+    current project at the point where it is included. This function
+    succeeds if \e filename is included; otherwise it fails. The included
+    file is processed immediately.
+
+    You can check whether the file was included by using this function as
+    the condition for a scope; for example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 66
+
+    \section1 infile(filename, var, val)
+    [Conditional]
+
+    Succeeds if the file \e filename (when parsed by \c qmake itself)
+    contains the variable \e var with a value of \e val; otherwise fails.
+    If you do not specify a third argument (\e val), the function will
+    only test whether \e var has been declared in the file.
+
+    \section1 isEmpty(variablename)
+    [Conditional]
+
+    Succeeds if the variable \e variablename is empty; otherwise fails.
+    This is the equivalent of \c{count( variablename, 0 )}.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 67
+
+    \section1 join(variablename, glue, before, after)
+
+    Joins the value of \e variablename with \c glue. If this value is
+    non-empty it prefixes the value with \e before and suffix it with \e
+    after. \e variablename is the only required field, the others default
+    to empty strings. If you need to encode spaces in \e glue, \e before, or \e
+    after you must quote them.
+
+    \section1 member(variablename, position)
+
+    Returns the value at the given \e position in the list of items in
+    \e variablename.
+    If an item cannot be found at the position specified, an empty string is
+    returned. \e variablename is the only required field. If not specified,
+    \c position defaults to 0, causing the first value in the list to be
+    returned.
+
+    \section1 message(string)
+
+    This function simply writes a message to the console. Unlike the
+    \c error() function, this function allows processing to continue.
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 68
+
+    The above line causes "This is a message" to be written to the console.
+    The use of quotation marks is optional.
+
+    \note By default, messages are written out for each Makefile generated by
+    qmake for a given project. If you want to ensure that messages only appear
+    once for each project, test the \c build_pass variable
+    \l{qmake Advanced Usage}{in conjunction with a scope} to filter out
+    messages during builds; for example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 69
+
+    \section1 prompt(question)
+
+    Displays the specified \e question, and returns a value read from stdin.
+
+    \section1 quote(string)
+
+    Converts a whole \e string into a single entity and returns the result.
+    Newlines, carriage returns, and tabs can be specified in the string
+    with \\n \\r and \\t. The return value does not contain either single
+    or double quotation marks unless you explicitly include them yourself,
+    but will be placed into a single entry (for literal expansion).
+
+    \section1 replace(string, old_string, new_string)
+
+    Replaces each instance of \c old_string with \c new_string in the
+    contents of the variable supplied as \c string. For example, the
+    code
+
+    \snippet doc/src/snippets/qmake/replace.pro 0
+
+    prints the message:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 70
+
+    \section1 sprintf(string, arguments...)
+
+    Replaces %1-%9 with the arguments passed in the comma-separated list
+    of function \e arguments and returns the processed string.
+
+    \section1 system(command)
+    [Conditional]
+
+    Executes the given \c command in a secondary shell, and succeeds
+    if the command returns with a zero exit status; otherwise fails.
+    You can check the return value of this function using a scope:
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 71
+
+    Alternatively, you can use this function to obtain stdout and stderr
+    from the command, and assign it to a variable. For example, you can
+    use this to interrogate information about the platform:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 72
+
+    \target unique
+    \section1 unique(variablename)
+
+    This will return a list of values in variable that are unique (that is
+    with repetitive entries removed). For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 73
+
+    \section1 warning(string)
+
+    This function will always succeed, and will display the given
+    \e string to the user. message() is a synonym for warning().
+*/
+
+/*!
+    \page qmake-environment-reference.html
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Function Reference
+
+    \title Configuring qmake's Environment
+
+    \tableofcontents
+
+    \target Properties
+    \section1 Properties
+
+    \c qmake has a system of persistant information, this allows you to
+    \c set a variable in qmake once, and each time qmake is invoked this
+    value can be queried. Use the following to set a property in qmake:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 74
+
+    The appropriate variable and value should be substituted for
+    \c VARIABLE and \c VALUE.
+
+    To retrieve this information back from qmake you can do:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 75
+
+    \note \c{qmake -query} will only list variables that you have
+    previously set with \c{qmake -set VARIABLE VALUE}.
+
+    This information will be saved into a QSettings object (meaning it
+    will be stored in different places for different platforms). As
+    \c VARIABLE is versioned as well, you can set one value in an older
+    version of \c qmake, and newer versions will retrieve this value. However,
+    if you set \c VARIABLE for a newer version of \c qmake, the older version
+    will not use this value. You can however query a specific version of a
+    variable if you prefix that version of \c qmake to \c VARIABLE, as in
+    the following example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 76
+
+    \c qmake also has the notion of \c builtin properties, for example you can
+    query the installation of Qt for this version of \c qmake with the
+    \c QT_INSTALL_PREFIX property:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 77
+
+    These built-in properties cannot have a version prefixed to them as
+    they are not versioned, and each version of \c qmake will have its own
+    built-in set of these values. The list below outlines the built-in
+    properties:
+
+    \list
+    \o \c QT_INSTALL_PREFIX - Where the version of Qt this qmake is built for resides
+    \o \c QT_INSTALL_DATA - Where data for this version of Qt resides
+    \o \c QMAKE_VERSION - The current version of qmake
+    \endlist
+
+    Finally, these values can be queried in a project file with a special
+    notation such as:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 78
+
+    \target QMAKESPEC
+    \section1 QMAKESPEC
+
+    \c qmake requires a platform and compiler description file which
+    contains many default values used to generate appropriate Makefiles.
+    The standard Qt distribution comes with many of these files, located
+    in the \c mkspecs subdirectory of the Qt installation.
+
+    The \c QMAKESPEC environment variable can contain any of the following:
+
+    \list
+    \o A complete path to a directory containing a \c{qmake.conf} file.
+       In this case \c qmake will open the \c{qmake.conf} file from within that
+       directory.  If the file does not exist, \c qmake will exit with an
+       error.
+    \o The name of a platform-compiler combination. In this case, \c qmake
+       will search in the directory specified by the \c mkspecs subdirectory
+       of the data path specified when Qt was compiled (see
+       QLibraryInfo::DataPath).
+    \endlist
+
+    \bold{Note:} The \c QMAKESPEC path will automatically be added to the
+    \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH} system variable.
+
+    \target INSTALLS
+    \section1 INSTALLS
+
+    It is common on Unix to also use the build tool to install applications
+    and libraries; for example, by invoking \c{make install}. For this reason,
+    \c qmake has the concept of an install set, an object which contains
+    instructions about the way part of a project is to be installed.
+    For example, a collection of documentation files can be described in the
+    following way:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 79
+
+    The \c path member informs \c qmake that the files should be installed in
+    \c /usr/local/program/doc (the path member), and the \c files member
+    specifies the files that should be copied to the installation directory.
+    In this case, everything in the \c docs directory will be coped to
+    \c /usr/local/program/doc.
+
+    Once an install set has been fully described, you can append it to the
+    install list with a line like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 80
+
+    \c qmake will ensure that the specified files are copied to the installation
+    directory. If you require greater control over this process, you can also
+    provide a definition for the \c extra member of the object. For example,
+    the following line tells \c qmake to execute a series of commands for this
+    install set:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 81
+
+    The \c unix scope
+    (see \l{qmake Advanced Usage#Scopes and Conditions}{Scopes and Conditions})
+    ensures that these particular commands are only executed on Unix platforms.
+    Appropriate commands for other platforms can be defined using other scope
+    rules.
+
+    Commands specified in the \c extra member are executed before the instructions
+    in the other members of the object are performed.
+
+    If you append a built-in install set to the \c INSTALLS variable and do
+    not specify \c files or \c extra members, \c qmake will decide what needs to
+    be copied for you. Currently, the only supported built-in install set is
+    \c target:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 82
+
+    In the above lines, \c qmake knows what needs to be copied, and will handle
+    the installation process automatically.
+
+    \target cache
+    \section1 Cache File
+
+    The cache file is a special file \c qmake reads to find settings not specified
+    in the \c qmake.conf file, project files, or at the command line. If
+    \c -nocache is not specified when \c qmake is run, it will try to find a file
+    called \c{.qmake.cache} in parent directories of the current directory. If
+    it fails to find this file, it will silently ignore this step of processing.
+
+    If it finds a \c{.qmake.cache} file then it will process this file first before
+    it processes the project file.
+
+    \target LibDepend
+    \section1 Library Dependencies
+
+    Often when linking against a library, \c qmake relies on the underlying
+    platform to know what other libraries this library links against, and
+    lets the platform pull them in. In many cases, however, this is not
+    sufficent. For example, when statically linking a library, no other
+    libraries are linked to, and therefore no dependencies to those
+    libraries are created. However, an application that later links
+    against this library will need to know where to find the symbols that
+    the static library will require. To help with this situation, \c qmake
+    attempts to follow a library's dependencies where appropriate, but
+    this behavior must be explicitly enabled by following two steps.
+
+    The first step is to enable dependency tracking in the library itself.
+    To do this you must tell \c qmake to save information about the library:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 83
+
+    This is only relevant to the \c lib template, and will be ignored for
+    all others. When this option is enabled, \c qmake will create a file
+    ending in .prl which will save some meta-information about the
+    library. This metafile is just like an ordinary project file, but only
+    contains internal variable declarations. You are free to view this file
+    and, if it is deleted, \c qmake will know to recreate it when necessary,
+    either when the project file is later read, or if a dependent library
+    (described below) has changed. When installing this library, by
+    specifying it as a target in an \c INSTALLS declaration, \c qmake will
+    automatically copy the .prl file to the installation path.
+
+    The second step in this process is to enable reading of this meta
+    information in the applications that use the static library:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 84
+
+    When this is enabled, \c qmake will process all libraries linked to
+    by the application and find their meta-information. \c qmake will use
+    this to determine the relevant linking information, specifically adding
+    values to the application project file's list of \c DEFINES as well as
+    \c LIBS. Once \c qmake has processed this file, it will then look through
+    the newly introduced libraries in the \c LIBS variable, and find their
+    dependent .prl files, continuing until all libraries have been resolved.
+    At this point, the Makefile is created as usual, and the libraries are
+    linked explicitlyy against the application.
+
+    The internals of the .prl file are left closed so they can easily
+    change later. They are not designed to be changed by hand, should only
+    be created by \c qmake, and should not be transferred between operating
+    systems as they may contain platform-dependent information.
+
+    \target Extensions
+    \section1 File Extensions
+
+    Under normal circumstances \c qmake will try to use appropriate file extensions
+    for your platform. However, it is sometimes necessary to override the default
+    choices for each platform and explicitly define file extensions for \c qmake to use.
+    This is achieved by redefining certain built-in variables; for example the extension
+    used for \l moc files can be redefined with the following assignment in a project
+    file:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 85
+
+    The following variables can be used to redefine common file extensions recognized
+    by \c qmake:
+
+    \list
+    \o QMAKE_EXT_MOC - This modifies the extension placed on included moc files.
+    \o QMAKE_EXT_UI - This modifies the extension used for designer UI files (usually
+                      in \c FORMS).
+    \o QMAKE_EXT_PRL - This modifies the extension placed on
+                       \l{#LibDepend}{library dependency files}.
+    \o QMAKE_EXT_LEX - This changes the suffix used in files (usually in \c LEXSOURCES).
+    \o QMAKE_EXT_YACC - This changes the suffix used in files (usually in \c YACCSOURCES).
+    \o QMAKE_EXT_OBJ - This changes the suffix used on generated object files.
+    \endlist
+
+    All of the above accept just the first value, so you must assign to it just one
+    value that will be used throughout your project file. There are two variables that
+    accept a list of values:
+
+    \list
+    \o QMAKE_EXT_CPP - Causes \c qmake to interpret all files with these suffixes as
+                       C++ source files.
+    \o QMAKE_EXT_H - Causes \c qmake to interpret all files with these suffixes as
+                     C and C++ header files.
+    \endlist
+
+    \target Customizing
+    \section1 Customizing Makefile Output
+
+    \c qmake tries to do everything expected of a cross-platform build tool.
+    This is often less than ideal when you really need to run special
+    platform-dependent commands. This can be achieved with specific instructions
+    to the different \c qmake backends.
+
+    Customization of the Makefile output is performed through an object-style
+    API as found in other places in \c qmake. Objects are defined automatically
+    by specifying their members; for example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 86
+
+    The definitions above define a \c qmake target called \c mytarget, containing
+    a Makefile target called \c{.buildfile} which in turn is generated with
+    the \c touch command. Finally, the \c{.depends} member specifies that
+    \c mytarget depends on \c mytarget2, another target that is defined afterwards.
+    \c mytarget2 is a dummy target; it is only defined to echo some text to
+    the console.
+
+    The final step is to instruct \c qmake that this object is a target to be built:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 87
+
+    This is all you need to do to actually build custom targets. Of course, you may
+    want to tie one of these targets to the
+    \l{qmake Variable Reference#TARGET}{qmake build target}. To do this, you simply need to
+    include your Makefile target in the list of
+    \l{qmake Variable Reference#PRE_TARGETDEPS}{PRE_TARGETDEPS}.
+
+    The following tables are an overview of the options available to you with the QMAKE_EXTRA_TARGETS
+    variable.
+
+    \table
+    \header
+        \o Member
+        \o Description
+    \row
+        \o commands
+        \o The commands for generating the custom build target.
+    \row
+        \o CONFIG
+        \o Specific configuration options for the custom build target.  See the CONFIG table for details.
+    \row
+        \o depends
+        \o The existing build targets that the custom build target depends on.
+    \row
+        \o recurse
+        \o Specifies which sub-targets should used when creating the rules in the Makefile to call in
+           the sub-target specific Makefile.  This is only used when \c recursive is set in the CONFIG.
+    \row
+        \o recurse_target
+        \o Specifies the target that should be built via the sub-target Makefile for the rule in the Makefile.
+           This adds something like $(MAKE) -f Makefile.[subtarget] [recurse_target].  This is only used when
+           \c recursive is set in the CONFIG.
+    \row
+        \o target
+        \o The file being created by the custom build target.
+    \endtable
+
+    List of members specific to the CONFIG option:
+
+    \table
+    \header
+        \o Member
+        \o Description
+    \row
+        \o recursive
+        \o Indicates that rules should be created in the Makefile and thus call
+           the relevant target inside the sub-target specific Makefile.  This defaults to creating
+           an entry for each of the sub-targets.
+    \endtable
+
+    For convenience, there is also a method of customizing projects
+    for new compilers or preprocessors:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 88
+
+    With the above definitions, you can use a drop-in replacement for moc if one
+    is available. The commands is executed on all arguments given to the
+    \c NEW_HEADERS variable (from the \c input member), and the result is written
+    to the file defined by the \c output member; this file is added to the
+    other source files in the project.
+    Additionally, \c qmake will execute \c depend_command to generate dependency
+    information, and place this information in the project as well.
+
+    These commands can easily be placed into a cache file, allowing subsequent
+    project files to add arguments to \c NEW_HEADERS.
+
+    The following tables are an overview of the options available to you with the QMAKE_EXTRA_COMPILERS
+    variable.
+
+    \table
+    \header
+        \o Member
+        \o Description
+    \row
+        \o commands
+        \o The commands used for for generating the output from the input.
+    \row
+        \o CONFIG
+        \o Specific configuration options for the custom compiler.  See the CONFIG table for details.
+    \row
+        \o depend_command
+        \o Specifies a command used to generate the list of dependencies for the output.
+    \row
+        \o dependency_type
+        \o Specifies the type of file the output is, if it is a known type (such as TYPE_C,
+           TYPE_UI, TYPE_QRC) then it is handled as one of those type of files.
+    \row
+        \o depends
+        \o Specifies the dependencies of the output file.
+    \row
+        \o input
+        \o The variable that contains the files that should be processed with the custom compiler.
+    \row
+        \o name
+        \o A description of what the custom compiler is doing.  This is only used in some backends.
+    \row
+        \o output
+        \o The filename that is created from the custom compiler.
+    \row
+        \o output_function
+        \o Specifies a custom qmake function that is used to specify the filename to be created.
+    \row
+        \o variable_out
+        \o The variable that the files created from the output should be added to.
+    \endtable
+
+    List of members specific to the CONFIG option:
+
+    \table
+    \header
+        \o Member
+        \o Description
+    \row
+        \o combine
+        \o Indicates that all of the input files are combined into a single output file.
+    \row
+        \o target_predeps
+        \o Indicates that the output should be added to the list of PRE_TARGETDEPS.
+    \row
+        \o explicit_dependencies
+        \o The dependencies for the output only get generated from the depends member and from
+           nowhere else.
+    \row
+        \o no_link
+        \o Indicates that the output should not be added to the list of objects to be linked in
+    \endtable
+*/
+
+/*!
+    \page qmake-advanced-usage.html
+    \title qmake Advanced Usage
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Platform Notes
+    \nextpage Using Precompiled Headers
+
+    Many \c qmake project files simply describe the sources and header files used
+    by the project, using a list of \c{name = value} and \c{name += value}
+    definitions. \c qmake also provides other operators, functions, and scopes
+    that can be used to process the information supplied in variable declarations.
+    These advanced features allow Makefiles to be generated for multiple platforms
+    from a single project file.
+
+    \tableofcontents
+
+    \section1 Operators
+
+    In many project files, the assignment (\c{=}) and append (\c{+=}) operators can
+    be used to include all the information about a project. The typical pattern of
+    use is to assign a list of values to a variable, and append more values
+    depending on the result of various tests. Since \c qmake defines certain
+    variables using default values, it is sometimes necessary to use the removal
+    (\c{-=}) operator to filter out values that are not required. The following
+    operators can be used to manipulate the contents of variables.
+
+    The \c = operator assigns a value to a variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 89
+
+    The above line sets the \c TARGET variable to \c myapp. This will overwrite any
+    values previously set for \c TARGET with \c myapp.
+
+    The \c += operator appends a new value to the list of values in a variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 90
+
+    The above line appends \c QT_DLL to the list of pre-processor defines to be put
+    in the generated Makefile.
+
+    The \c -= operator removes a value from the list of values in a variable:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 91
+
+    The above line removes \c QT_DLL from the list of pre-processor defines to be
+    put in the generated Makefile.
+
+    The \c *= operator adds a value to the list of values in a variable, but only
+    if it is not already present. This prevents values from being included many
+    times in a variable. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 92
+
+    In the above line, \c QT_DLL will only be added to the list of pre-processor
+    defines if it is not already defined. Note that the
+    \l{qmake Function Reference#unique}{unique()}
+    function can also be used to ensure that a variables only contains one
+    instance of each value.
+
+    The \c ~= operator replaces any values that match a regular expression with
+    the specified value:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 93
+
+    In the above line, any values in the list that start with \c QT_D or \c QT_T are
+    replaced with \c QT.
+
+    The \c $$ operator is used to extract the contents of a variable, and can be
+    used to pass values between variables or supply them to functions:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 94
+
+    \target Scopes
+    \section1 Scopes
+
+    Scopes are similar to \c if statements in procedural programming languages.
+    If a certain condition is true, the declarations inside the scope are processed.
+
+    \section2 Syntax
+
+    Scopes consist of a condition followed by an opening brace on the same line,
+    a sequence of commands and definitions, and a closing brace on a new line:
+
+    \snippet doc/src/snippets/qmake/scopes.pro syntax
+
+    The opening brace \e{must be written on the same line as the condition}.
+    Scopes may be concatenated to include more than one condition; see below
+    for examples.
+
+    \section2 Scopes and Conditions
+
+    A scope is written as a condition followed by a series of declarations
+    contained within a pair of braces; for example:
+
+    \snippet doc/src/snippets/qmake/scopes.pro 0
+
+    The above code will add the \c paintwidget_win.cpp file to the sources listed
+    in the generated Makefile if \c qmake is used on a Windows platform.
+    If \c qmake is used on a platform other than Windows, the define will be
+    ignored.
+
+    The conditions used in a given scope can also be negated to provide an
+    alternative set of declarations that will be processed only if the
+    original condition is false. For example, suppose we want to process
+    something on all platforms \e except for Windows. We can achieve this by
+    negating the scope like this:
+
+    \snippet doc/src/snippets/qmake/scopes.pro 1
+
+    Scopes can be nested to combine more than one condition. For instance, if
+    you want to include a particular file for a certain platform only if
+    debugging is enabled then you write the following:
+
+    \snippet doc/src/snippets/qmake/scopes.pro 2
+
+    To save writing many nested scopes, you can nest scopes using the \c :
+    operator. The nested scopes in the above example can be rewritten in
+    the following way:
+
+    \snippet doc/src/snippets/qmake/scopes.pro 3
+
+    You may also use the \c : operator to perform single line conditional
+    assignments; for example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 95
+
+    The above line adds \c QT_DLL to the \c DEFINES variable only on the
+    Windows platform.
+    Generally, the \c : operator behaves like a logical AND operator, joining
+    together a number of conditions, and requiring all of them to be true.
+
+	There is also the \c | operator to act like a logical OR operator, joining 
+	together a number of conditions, and requiring only one of them to be true.
+
+	\snippet doc/src/snippets/qmake/scopes.pro 4
+
+    You can also provide alternative declarations to those within a scope by
+    using an \c else scope. Each \c else scope is processed if the conditions
+    for the preceding scopes are false.
+    This allows you to write complex tests when combined with other scopes
+    (separated by the \c : operator as above). For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 96
+
+    \section2 Configuration and Scopes
+
+    The values stored in the
+    \l{qmake-project-files.html#GeneralConfiguration}{\c CONFIG variable}
+    are treated specially by \c qmake. Each of the possible values can be
+    used as the condition for a scope. For example, the list of values
+    held by \c CONFIG can be extended with the \c opengl value:
+
+    \snippet doc/src/snippets/qmake/configscopes.pro 0
+
+    As a result of this operation, any scopes that test for \c opengl will
+    be processed. We can use this feature to give the final executable an
+    appropriate name:
+
+    \snippet doc/src/snippets/qmake/configscopes.pro 1
+    \snippet doc/src/snippets/qmake/configscopes.pro 2
+    \snippet doc/src/snippets/qmake/configscopes.pro 3
+
+    This feature makes it easy to change the configuration for a project
+    without losing all the custom settings that might be needed for a specific
+    configuration. In the above code, the declarations in the first scope are
+    processed, and the final executable will be called \c application-gl.
+    However, if \c opengl is not specified, the declarations in the second
+    scope are processed instead, and the final executable will be called
+    \c application.
+
+    Since it is possible to put your own values on the \c CONFIG
+    line, this provides you with a convenient way to customize project files
+    and fine-tune the generated Makefiles.
+
+    \section2 Platform Scope Values
+
+    In addition to the \c win32, \c macx, and \c unix values used in many
+    scope conditions, various other built-in platform and compiler-specific
+    values can be tested with scopes. These are based on platform
+    specifications provided in Qt's \c mkspecs directory. For example, the
+    following lines from a project file show the current specification in
+    use and test for the \c linux-g++ specification:
+
+    \snippet doc/src/snippets/qmake/specifications.pro 0
+
+    You can test for any other platform-compiler combination as long as a
+    specification exists for it in the \c mkspecs directory.
+
+    \section1 Variables
+
+    Many of the variables used in project files are special variables that
+    \c qmake uses when generating Makefiles, such as \c DEFINES, \c SOURCES,
+    and \c HEADERS. It is possible for you to create variables for your own
+    use; \c qmake creates new variables with a given name when it encounters
+    an assignment to that name. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 97
+
+    There are no restricitions on what you do to your own variables, as \c
+    qmake will ignore them unless it needs to evaluate them when processing
+    a scope.
+
+    You can also assign the value of a current variable to another
+    variable by prefixing $$ to the variable name. For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 98
+
+    Now the MY_DEFINES variable contains what is in the DEFINES variable at
+    this point in the project file.  This is also equivalent to:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 99
+
+    The second notation allows you to append the contents of the variable to
+    another value without separating the two with a space. For example, the
+    following will ensure that the final executable will be given a name
+    that includes the project template being used:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 100
+
+    Variables can be used to store the contents of environment variables.
+    These can be evaluated at the time that \c qmake is run, or included
+    in the generated Makefile for evaluation when the project is built.
+
+    To obtain the contents of an environment value when \c qmake is run,
+    use the \c $$(...) operator:
+
+    \snippet doc/src/snippets/qmake/environment.pro 0
+
+    In the above assignment, the value of the \c PWD environment variable
+    is read when the project file is processed.
+
+    To obtain the contents of an environment value at the time when the
+    generated Makefile is processed, use the \c $(...) operator:
+
+    \snippet doc/src/snippets/qmake/environment.pro 1
+
+    In the above assignment, the value of \c PWD is read immediately
+    when the project file is processed, but \c $(PWD) is assigned to
+    \c DESTDIR in the generated Makefile. This makes the build process
+    more flexible as long as the environment variable is set correctly
+    when the Makefile is processed.
+
+    The special \c $$[...] operator can be used to access various
+    configuration options that were set when Qt was built:
+
+    \snippet doc/src/snippets/qmake/qtconfiguration.pro 0
+
+    The variables accessible with this operator are typically used to
+    enable third party plugins and components to be integrated with Qt.
+    For example, a \QD plugin can be installed alongside \QD's built-in
+    plugins if the following declaration is made in its project file:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 101
+
+    \target VariableProcessingFunctions
+    \section1 Variable Processing Functions
+
+    \c qmake provides a selection of built-in functions to allow the
+    contents of variables to be processed. These functions process the
+    arguments supplied to them and return a value, or list of values, as
+    a result. In order to assign a result to a variable, it is necessary
+    to use the \c $$ operator with this type of function in the same way
+    used to assign contents of one variable to another:
+
+    \snippet doc/src/snippets/qmake/functions.pro 1
+
+    This type of function should be used on the right-hand side of
+    assignments (i.e, as an operand).
+
+    It is possible to define your own functions for processing the
+    contents of variables. These functions can be defined in the following
+    way:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 102
+
+    The following example function takes a variable name as its only
+    argument, extracts a list of values from the variable with the
+    \l{qmake-function-reference.html}{eval()} built-in function,
+    and compiles a list of files:
+
+    \snippet doc/src/snippets/qmake/replacefunction.pro 0
+
+    \target ConditionalFunctions
+    \section1 Conditional Functions
+
+    \c qmake provides built-in functions that can be used as conditions
+    when writing scopes. These functions do not return a value, but
+    instead indicate "success" or "failure":
+
+    \snippet doc/src/snippets/qmake/functions.pro 3
+
+    This type of function should be used in conditional expressions
+    only.
+
+    It is possible to define your own functions to provide conditions
+    for scopes. The following example tests whether each file in a list
+    exists and returns true if they all exist, or false if not:
+
+    \snippet doc/src/snippets/qmake/testfunction.pro 0
+
+    \section1 Adding New Configuration Features
+
+    \c qmake lets you create your own \e features that can be included in
+    project files by adding their names to the list of values specified by
+    the \c CONFIG variable. Features are collections of custom functions and
+    definitions in \c{.prf} files that can reside in one of many standard
+    directories. The locations of these directories are defined in a number
+    of places, and \c qmake checks each of them in the following order when
+    it looks for \c{.prf} files:
+
+    \list 1
+    \o In a directory listed in the \c QMAKEFEATURES environment variable;
+       this contains a colon-separated list of directories.
+    \o In a directory listed in the \c QMAKEFEATURES property variable; this
+       contains a colon-spearated list of directories.
+    \omit
+    \o In a features directory beneath the project's root directory (where
+       the \c{.qmake.cache} file is generated).
+    \endomit
+    \o In a features directory residing within a \c mkspecs directory.
+       \c mkspecs directories can be located beneath any of the directories
+       listed in the \c QMAKEPATH environment variable (a colon-separated list
+       of directories). (\c{$QMAKEPATH/mkspecs/<features>})
+    \o In a features directory residing beneath the directory provided by the
+       \c QMAKESPEC environment variable. (\c{$QMAKESPEC/<features>})
+    \o In a features directory residing in the \c data_install/mkspecs directory.
+       (\c{data_install/mkspecs/<features>})
+    \o In a features directory that exists as a sibling of the directory
+       specified by the \c QMAKESPEC environment variable.
+       (\c{$QMAKESPEC/../<features>})
+    \endlist
+
+    The following features directories are searched for features files:
+
+    \list 1
+    \o \c{features/unix}, \c{features/win32}, or \c{features/macx}, depending on
+       the platform in use
+    \o \c features/
+    \endlist
+
+    For example, consider the following assignment in a project file:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 103
+
+    With this addition to the \c CONFIG variable, \c qmake will search the
+    locations listed above for the \c myfeatures.prf file after it has
+    finished parsing your project file. On Unix systems, it will look for
+    the following file:
+
+    \list 1
+    \o \c $QMAKEFEATURES/myfeatures.prf (for each directory listed in the
+       \c QMAKEFEATURES environment variable)
+    \o \c $$QMAKEFEATURES/myfeatures.prf (for each directory listed in the
+       \c QMAKEFEATURES property variable)
+    \o \c myfeatures.prf (in the project's root directory)
+    \o \c $QMAKEPATH/mkspecs/features/unix/myfeatures.prf and
+       \c $QMAKEPATH/mkspecs/features/myfeatures.prf (for each directory
+       listed in the \c QMAKEPATH environment variable)
+    \o \c $QMAKESPEC/features/unix/myfeatures.prf and
+       \c $QMAKESPEC/features/myfeatures.prf
+    \o \c data_install/mkspecs/features/unix/myfeatures.prf and
+       \c data_install/mkspecs/features/myfeatures.prf
+    \o \c $QMAKESPEC/../features/unix/myfeatures.prf and
+       \c $QMAKESPEC/../features/myfeatures.prf
+    \endlist
+
+    \note The \c{.prf} files must have names in lower case.
+
+
+*/
+
+/*!
+    \page qmake-precompiledheaders.html
+    \title Using Precompiled Headers
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Advanced Usage
+    \nextpage qmake Reference
+
+    \target Introduction
+
+    Precompiled headers are a performance feature supported by some
+    compilers to compile a stable body of code, and store the compiled
+    state of the code in a binary file. During subsequent compilations,
+    the compiler will load the stored state, and continue compiling the
+    specified file. Each subsequent compilation is faster because the
+    stable code does not need to be recompiled.
+
+    \c qmake supports the use of precompiled headers (PCH) on some
+    platforms and build environments, including:
+    \list
+    \o Windows
+        \list
+        \o nmake
+        \o Dsp projects (VC 6.0)
+        \o Vcproj projects (VC 7.0 \& 7.1)
+        \endlist
+    \o Mac OS X
+        \list
+        \o Makefile
+        \o Xcode
+        \endlist
+    \o Unix
+        \list
+        \o GCC 3.4 and above
+        \endlist
+    \endlist
+
+    \target ADD_PCH
+    \section1 Adding Precompiled Headers to Your Project
+
+    \target PCH_CONTENTS
+    \section2 Contents of the Precompiled Header File
+
+    The precompiled header must contain code which is \e stable
+    and \e static throughout your project. A typical PCH might look
+    like this:
+
+    \section3 Example: \c stable.h
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 104
+
+    Note that a precompiled header file needs to separate C includes from
+    C++ includes, since the precompiled header file for C files may not
+    contain C++ code.
+
+    \target PROJECT_OPTIONS
+    \section2 Project Options
+
+    To make your project use PCH, you only need to define the
+    \c PRECOMPILED_HEADER variable in your project file:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 105
+
+    \c qmake will handle the rest, to ensure the creation and use of the
+    precompiled header file. You do not need to include the precompiled
+    header file in \c HEADERS, as \c qmake will do this if the configuration
+    supports PCH.
+
+    All platforms that support precompiled headers have the configuration
+    option \c precompile_header set. Using this option, you may trigger
+    conditional blocks in your project file to add settings when using PCH.
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 106
+
+    \section1 Notes on Possible Issues
+
+    On some platforms, the file name suffix for precompiled header files is
+    the same as that for other object files. For example, the following
+    declarations may cause two different object files with the same name to
+    be generated:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 107
+
+    To avoid potential conflicts like these, it is good practice to ensure
+    that header files that will be precompiled are given distinctive names.
+
+    \target EXAMPLE_PROJECT
+    \section1 Example Project
+
+    You can find the following source code in the
+    \c{examples/qmake/precompile} directory in the Qt distribution:
+
+    \section2 \c mydialog.ui
+
+    \quotefromfile examples/qmake/precompile/mydialog.ui
+    \printuntil
+
+    \section2 \c stable.h
+
+    \snippet examples/qmake/precompile/stable.h 0
+
+    \section2 \c myobject.h
+
+    \snippet examples/qmake/precompile/myobject.h 0
+
+    \section2 \c myobject.cpp
+
+    \snippet examples/qmake/precompile/myobject.cpp 0
+
+    \section2 \c util.cpp
+
+    \snippet examples/qmake/precompile/util.cpp 0
+
+    \section2 \c main.cpp
+
+    \snippet examples/qmake/precompile/main.cpp 0
+
+    \section2 \c precompile.pro
+
+    \snippet examples/qmake/precompile/precompile.pro 0
+*/
+
+/*!
+    \page qmake-tutorial.html
+    \title qmake Tutorial
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Manual
+    \nextpage qmake Common Projects
+
+    This tutorial teaches you how to use \c qmake.  We recommend that
+    you read the \c qmake user guide after completing this tutorial.
+
+    \section1 Starting off Simple
+
+    Let's assume that you have just finished a basic implementation of
+    your application, and you have created the following files:
+
+    \list
+    \o hello.cpp
+    \o hello.h
+    \o main.cpp
+    \endlist
+
+    You will find these files in the \c{examples/qmake/tutorial} directory
+    of the Qt distribution. The only other thing you know about the setup of
+    the application is that it's written in Qt.  First, using your favorite
+    plain text editor, create a file called \c hello.pro in
+    \c{examples/qmake/tutorial}. The first thing you need to do is add the
+    lines that tell \c qmake about the source and header files that are part
+    of your development project.
+
+    We'll add the source files to the project file first.  To do this you
+    need to use the \l{qmake Variable Reference#SOURCES}{SOURCES} variable.
+    Just start a new line with \c {SOURCES +=} and put hello.cpp after it.
+    You should have something like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 108
+
+    We repeat this for each source file in the project, until we end up
+    with the following:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 109
+
+    If you prefer to use a Make-like syntax, with all the files listed in
+    one go you can use the newline escaping like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 110
+
+    Now that the source files are listed in the project file, the header
+    files must be added. These are added in exactly the same way as source
+    files, except that the variable name we use is
+    \l{qmake Variable Reference#HEADERS}{HEADERS}.
+
+    Once you have done this, your project file should look something like
+    this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 111
+
+    The target name is set automatically; it is the same as the project
+    file, but with the suffix appropriate to the platform. For example, if
+    the project file is called \c hello.pro, the target will be \c hello.exe
+    on Windows and \c hello on Unix. If you want to use a different name
+    you can set it in the project file:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 112
+
+    The final step is to set the \l{qmake Variable Reference#CONFIG}{CONFIG}
+    variable. Since this is a Qt application, we need to put \c qt on the
+    \c CONFIG line so that \c qmake will add the relevant libraries to be
+    linked against and ensure that build lines for \c moc and \c uic are
+    included in the generated Makefile.
+
+    The finished project file should look like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 113
+
+    You can now use \c qmake to generate a Makefile for your application.
+    On the command line, in your project's directory, type the following:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 114
+
+    Then type \c make or \c nmake depending on the compiler you use.
+
+    For Visual Studio users, \c qmake can also generate \c .dsp or
+    \c .vcproj files, for example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 115
+
+    \section1 Making an Application Debuggable
+
+    The release version of an application doesn't contain any debugging
+    symbols or other debugging information. During development it is useful
+    to produce a debugging version of the application that has the
+    relevant information. This is easily achieved by adding \c debug to the
+    \c CONFIG variable in the project file.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 116
+
+    Use \c qmake as before to generate a Makefile and you will be able to
+    obtain useful information about your application when running it in
+    a debugging environment.
+
+    \section1 Adding Platform-Specific Source Files
+
+    After a few hours of coding, you might have made a start on the
+    platform-specific part of your application, and decided to keep the
+    platform-dependent code separate.  So you now have two new files to
+    include into your project file: \c hellowin.cpp and \c
+    hellounix.cpp.  We can't just add these to the \c SOURCES
+    variable since this will put both files in the Makefile. So, what we
+    need to do here is to use a scope which will be processed depending on
+    which platform \c qmake is run on.
+
+    A simple scope that will add in the platform-dependent file for
+    Windows looks like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 117
+
+    So if \c qmake is run on Windows, it will add \c hellowin.cpp to the
+    list of source files.  If \c qmake is run on any other platform, it
+    will simply ignore it. Now all that is left to be done is to create a
+    scope for the Unix-specific file.
+
+    When you have done that, your project file should now look
+    something like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 118
+
+    Use \c qmake as before to generate a Makefile.
+
+    \section1 Stopping qmake If a File Doesn't Exist
+
+    You may not want to create a Makefile if a certain file doesn't exist.
+    We can check if a file exists by using the exists() function.  We can
+    stop \c qmake from processing by using the error() function.  This
+    works in the same way as scopes do.  Simply replace the scope condition
+    with the function. A check for a \c main.cpp file looks like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 119
+
+    The \c{!} symbol is used to negate the test; i.e. \c{exists( main.cpp )}
+    is true if the file exists, and \c{!exists( main.cpp )} is true if the
+    file doesn't exist.
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 120
+
+    Use \c qmake as before to generate a makefile.  If you rename \c
+    main.cpp temporarily, you will see the message and \c qmake will stop
+    processing.
+
+    \section1 Checking for More than One Condition
+
+    Suppose you use Windows and you want to be able to see statement
+    output with qDebug() when you run your application on the command line.
+    Unless you build your application with the appropriate console setting,
+    you won't see the output. We can easily put \c console on the \c CONFIG
+    line so that on Windows the makefile will have this setting. However,
+    let's say that we only want to add the \c CONFIG line if we are running
+    on Windows \e and when \c debug is already on the \c CONFIG line.
+    This requires using two nested scopes; just create one scope, then create
+    the other inside it. Put the settings to be processed inside the last
+    scope, like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 121
+
+    Nested scopes can be joined together using colons, so the final
+    project file looks like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 122
+
+    That's it! You have now completed the tutorial for \c qmake, and are
+    ready to write project files for your development projects.
+*/
+
+/*!
+    \page qmake-common-projects.html
+    \title qmake Common Projects
+    \contentspage {qmake Manual}{Contents}
+    \previouspage qmake Tutorial
+    \nextpage Using qmake
+
+    This chapter describes how to set up \c qmake project files for three
+    common project types that are based on Qt. Although all kinds of
+    projects use many of the same variables, each of them use project-specific
+    variables to customize output files.
+
+    Platform-specific variables are not described here; we refer the reader to
+    the \l{Deploying Qt Applications} document for information on issues such as
+    \l{Deploying an Application on Mac OS X#Architecture Dependencies}{building
+    universal binaries for Mac OS X} and
+    \l{Deploying an Application on Windows#Visual Studio 2005 Onwards}
+    {handling Visual Studio manifest files}.
+
+    \tableofcontents
+
+    \target Application
+    \section1 Building an Application
+
+    \section2 The app Template
+
+    The \c app template tells \c qmake to generate a Makefile that will build
+    an application. With this template, the type of application can be specified
+    by adding one of the following options to the \c CONFIG variable definition:
+
+    \table
+    \header \o Option  \o Description
+    \row    \o windows \o The application is a Windows GUI application.
+    \row    \o console \o \c app template only: the application is a Windows console
+                       application.
+    \endtable
+
+    When using this template the following \c qmake system variables are recognized.
+    You should use these in your .pro file to specify information about your
+    application.
+
+    \list
+    \o HEADERS - A list of all the header files for the application.
+    \o SOURCES - A list of all the source files for the application.
+    \o FORMS - A list of all the UI files (created using \c{Qt Designer})
+    for the application.
+    \o LEXSOURCES - A list of all the lex source files for the application.
+    \o YACCSOURCES - A list of all the yacc source files for the application.
+    \o TARGET - Name of the executable for the application. This defaults
+    to the name of the project file. (The extension, if any, is added
+    automatically).
+    \o DESTDIR - The directory in which the target executable is placed.
+    \o DEFINES - A list of any additional pre-processor defines needed for the application.
+    \o INCLUDEPATH - A list of any additional include paths needed for the application.
+    \o DEPENDPATH - The dependency search path for the application.
+    \o VPATH - The search path to find supplied files.
+    \o DEF_FILE - Windows only: A .def file to be linked against for the application.
+    \o RC_FILE - Windows only: A resource file for the application.
+    \o RES_FILE - Windows only: A resource file to be linked against for the application.
+    \endlist
+
+    You only need to use the system variables that you have values for,
+    for instance, if you do not have any extra INCLUDEPATHs then you do not
+    need to specify any, \c qmake will add in the default ones needed.
+    For instance, an example project file might look like this:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 123
+
+    For items that are single valued, e.g. the template or the destination
+    directory, we use "="; but for multi-valued items we use "+=" to \e
+    add to the existing items of that type. Using "=" replaces the item's
+    value with the new value, for example if we wrote \c{DEFINES=QT_DLL},
+    all other definitions would be deleted.
+
+    \target Library
+    \section1 Building a Library
+
+    \section2 The lib Template
+
+    The \c lib template tells \c qmake to generate a Makefile that will
+    build a library.  When using this template, in addition to the system variables
+    mentioned above for the \c app template the \c VERSION variable is
+    supported.  You should use these in your .pro file to specify
+    information about the library.
+
+    When using the \c lib template, the following options can be added to the
+    \c CONFIG variable to determine the type of library that is built:
+
+    \table
+    \header \o Option    \o Description
+    \row    \o dll       \o The library is a shared library (dll).
+    \row    \o staticlib \o The library is a static library.
+    \row    \o plugin    \o The library is a plugin; this also enables the dll option.
+    \endtable
+
+    The following option can also be defined to provide additional information about
+    the library.
+
+    \list
+    \o VERSION - The version number of the target library, for example, 2.3.1.
+    \endlist
+
+    The target file name for the library is platform-dependent. For example, on
+    X11 and Mac OS X, the library name will be prefixed by \c lib; on Windows,
+    no prefix is added to the file name.
+
+    \target Plugin
+    \section1 Building a Plugin
+
+    Plugins are built using the \c lib template, as described in the previous
+    section. This tells \c qmake to generate a Makefile for the project that will
+    build a plugin in a suitable form for each platform, usually in the form of a
+    library. As with ordinary libraries, the \c VERSION variable is used to specify
+    information about the plugin.
+
+    \list
+    \o VERSION - The version number of the target library, for example, 2.3.1.
+    \endlist
+
+    \section2 Building a Qt Designer Plugin
+
+    \QD plugins are built using a specific set of configuration settings that
+    depend on the way Qt was configured for your system. For convenience, these
+    settings can be enabled by adding \c designer to the project's \c CONFIG
+    variable. For example:
+
+    \snippet examples/designer/worldtimeclockplugin/worldtimeclockplugin.pro 0
+
+    See the \l{Qt Designer Examples} for more examples of plugin-based projects.
+
+    \section1 Building and Installing in Debug and Release Modes
+
+    Sometimes, it is necessary to build a project in both debug and release
+    modes. Although the \c CONFIG variable can hold both \c debug and \c release
+    options, the \c debug option overrides the \c release option.
+
+    \section2 Building in Both Modes
+
+    To enable a project to be built in both modes, you must add the
+    \c debug_and_release option to your project's \c CONFIG definition:
+
+    \snippet doc/src/snippets/qmake/debug_and_release.pro 0
+    \snippet doc/src/snippets/qmake/debug_and_release.pro 1
+
+    The scope in the above snippet modifies the build target in each mode to
+    ensure that the resulting targets have different names. Providing different
+    names for targets ensures that one will not overwrite the other.
+
+    When \c qmake processes the project file, it will generate a Makefile rule
+    to allow the project to be built in both modes. This can be invoked in the
+    following way:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 124
+
+    The \c build_all option can be added to the \c CONFIG variable in the
+    project file to ensure that the project is built in both modes by default:
+
+    \snippet doc/src/snippets/qmake/debug_and_release.pro 2
+
+    This allows the Makefile to be processed using the default rule:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 125
+
+    \section2 Installing in Both Modes
+
+    The \c build_all option also ensures that both versions of the target
+    will be installed when the installation rule is invoked:
+
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 126
+
+    It is possible to customize the names of the build targets depending on
+    the target platform. For example, a library or plugin may be named using a
+    different convention on Windows to the one used on Unix platforms:
+
+    \omit
+    Note: This was originally used in the customwidgetplugin.pro file, but is
+    no longer needed there.
+    \endomit
+    \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 127
+
+    The default behavior in the above snippet is to modify the name used for
+    the build target when building in debug mode. An \c else clause could be
+    added to the scope to do the same for release mode; left as it is, the
+    target name remains unmodified.
+*/
+
diff --git a/doc/src/development/qmsdev.qdoc b/doc/src/development/qmsdev.qdoc
new file mode 100644
index 0000000000..ceed4c1090
--- /dev/null
+++ b/doc/src/development/qmsdev.qdoc
@@ -0,0 +1,166 @@
+/****************************************************************************
+**
+** 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$
+**
+****************************************************************************/
+
+/* NOT DOCUMENTED ! 
+  \page qmsdev.html
+
+  \title The QMsDev Plugin
+
+  The Visual Studio Integration Plugin is currently available only to users of
+  Visual Studio 6. It offers simple ways of doing common tasks when writing a
+  Qt application. 
+
+  \tableofcontents
+
+  \section1 How to install the Visual Studio Integration Plugin
+   
+  When you install Qt, the integration plugin should be installed for you,
+  however, sometimes this does  not happen, so to install the integration
+  plugin manually just carry out the following steps.
+
+  \list
+  \i Start up Visual Studio.
+  \i Select Tools|Customize|Add-ins and Macro Files.
+  \i Ensure that there is a tick next to QMsDev Developer Studio Add-In.
+  \i Click Close.
+  \endlist
+
+  Now the integration plugin should be installed. If this doesn't
+  work, then contact Qt technical support giving details of
+  what went wrong.
+  
+  \section1 How to uninstall the Visual Studio Integration Plugin
+
+  When you want to uninstall the integration plugin, just carry out the
+  following steps.
+
+  \list
+  \i Close down any instances of Visual Studio.
+  \i Delete the file '%MSDevDir%\\addins\\qmsdev.dll'
+  \endlist
+
+  \section1 What can the Visual Studio Integration Plugin do?
+  
+  The integration plugin adds the following options to Visual Studio:
+
+  \list
+  \i New Qt Project
+  \i New Qt Dialog
+  \i Qt Designer
+  \i Open Qt Project
+  \i Write Qt Project
+  \i Use Qt In Current Project
+  \i Add MOC
+  \endlist
+
+  \section2 Using the 'New Qt Project' button
+  
+  The 'New Qt Project' button allows you to create a simple Qt project
+  ready for development. Simply fill in the form and if you select
+  'Dialog' or 'Main Window' without MDI support then it will
+  automatically start up \e{Qt Designer}. When you have finished with
+  the form in \e{Qt Designer} just save it and it will appear in a
+  ready made Qt project.
+
+  If you select 'Main Window' with 'MDI Support' then it will simply
+  give you a code skeleton in a project ready for you to populate with
+  your own code.
+
+  \section2 Using the 'New Qt Dialog' button
+
+  The 'New Qt Dialog' button works in two ways: You can use it to create a new
+  dialog for your project; or you can  use it to insert an existing
+  dialog into your project.
+
+  If you want to create a new dialog then all you need to do is specify where
+  the dialog file should be saved and give it a name. This will start up
+  \e{Qt Designer} to allow you to design your new dialog, and will add it to
+  the existing  project.
+
+  If you want to add an existing dialog to your project, then just select the
+  relevant UI file. This will then add it to your existing project and add
+  the relevant steps to create the generated code.
+
+  \section2 Using the 'Qt Designer' button
+
+  The 'Qt Designer' button simply starts up \e{Qt Designer}, it has no ties to
+  your existing project so whatever you do with it will not affect your
+  existing projects. It can also be started up by using the Ctrl+Shift+D key
+  combination in Visual Studio.
+
+  \section2 Using the 'Open Qt Project' button
+
+  The 'Open Qt Project' button allows you to convert an existing \c
+  qmake project file into a \c .dsp file which you can insert into
+  your existing workspace. When you click the 'Open Qt Project'
+  button, just select an existing \c qmake project file (a \c .pro
+  file) and then click OK. You will get a message box at the end
+  which asks you to insert the newly created \c .dsp file into your
+  existing workspace.
+
+  \section2 Using the 'Write Qt Project' button
+
+  The 'Write Qt Project' button creates a \c qmake project (\c .pro)
+  file for your current project so that you can easily copy the files
+  onto another platform and be able to use \c qmake to create a Makefile
+  on that other platform. All you need to do is make the project you
+  want to create a \c .pro file for, and click on the button. Just
+  name your \c qmake project file and click Save.
+
+  \section2 Using the 'Use Qt In Current Project' button
+
+  The 'Use Qt In Current Project' button simply adds in the necessary
+  information for the current project so that it links against Qt and
+  sets any other settings needed to use Qt in that project.
+
+  \section2 Using the 'Add MOC' button
+
+  The 'Add MOC' button will add in the custom build step for the selected file
+  so that it creates any needed MOC files and it will add these generated
+  files to the project. All you need to do to use it is click on a file that
+  has Q_OBJECT and click the button. 
+
+  You only need to use this button if you added a file that has
+  Q_OBJECT in it by hand, you don't need to use this if you used any
+  of the previously mentioned buttons. It can also be invoked by using
+  the \key{Ctrl+Shift+M} key combination in Visual Studio.
+
+*/
diff --git a/doc/src/development/qtestlib.qdoc b/doc/src/development/qtestlib.qdoc
new file mode 100644
index 0000000000..13a5b7c04b
--- /dev/null
+++ b/doc/src/development/qtestlib.qdoc
@@ -0,0 +1,778 @@
+/****************************************************************************
+**
+** 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 qtestlib-manual.html
+    \title QTestLib Manual
+    \brief An overview of Qt's unit testing framework.
+
+    \ingroup frameworks-technologies
+    \keyword qtestlib
+
+    The QTestLib framework, provided by Nokia, is a tool for unit
+    testing Qt based applications and libraries. QTestLib provides
+    all the functionality commonly found in unit testing frameworks as
+    well as extensions for testing graphical user interfaces.
+
+    Table of contents:
+
+    \tableofcontents
+
+    \section1 QTestLib Features
+
+    QTestLib is designed to ease the writing of unit tests for Qt
+    based applications and libraries:
+
+    \table
+    \header \o Feature \o Details
+    \row
+        \o \bold Lightweight
+        \o QTestLib consists of about 6000 lines of code and 60
+           exported symbols.
+    \row
+        \o \bold Self-contained
+        \o QTestLib requires only a few symbols from the Qt Core library
+           for non-gui testing.
+    \row
+        \o \bold {Rapid testing}
+        \o QTestLib needs no special test-runners; no special
+           registration for tests.
+    \row
+        \o \bold {Data-driven testing}
+        \o A test can be executed multiple times with different test data.
+    \row
+        \o \bold {Basic GUI testing}
+        \o QTestLib offers functionality for mouse and keyboard simulation.
+    \row
+        \o \bold {Benchmarking}
+        \o QTestLib supports benchmarking and provides several measurement back-ends.
+    \row
+         \o \bold {IDE friendly}
+         \o QTestLib outputs messages that can be interpreted by Visual
+            Studio and KDevelop.
+    \row
+         \o \bold Thread-safety
+         \o The error reporting is thread safe and atomic.
+    \row
+         \o \bold Type-safety
+         \o Extensive use of templates prevent errors introduced by
+            implicit type casting.
+    \row
+         \o \bold {Easily extendable}
+         \o Custom types can easily be added to the test data and test output.
+    \endtable
+
+    Note: For higher-level GUI and application testing needs, please
+    see the \l{Third-Party Tools}{Qt testing products provided by
+    Nokia partners}.
+
+
+    \section1 QTestLib API
+
+    All public methods are in the \l QTest namespace. In addition, the
+    \l QSignalSpy class provides easy introspection for Qt's signals and slots.
+
+
+    \section1 Using QTestLib
+
+    \section2 Creating a Test
+
+    To create a test, subclass QObject and add one or more private slots to it. Each
+    private slot is a testfunction in your test. QTest::qExec() can be used to execute
+    all testfunctions in the test object.
+
+    In addition, there are four private slots that are \e not treated as testfunctions.
+    They will be executed by the testing framework and can be used to initialize and
+    clean up either the entire test or the current test function.
+
+    \list
+    \o \c{initTestCase()} will be called before the first testfunction is executed.
+    \o \c{cleanupTestCase()} will be called after the last testfunction was executed.
+    \o \c{init()} will be called before each testfunction is executed.
+    \o \c{cleanup()} will be called after every testfunction.
+    \endlist
+
+    If \c{initTestCase()} fails, no testfunction will be executed. If \c{init()} fails,
+    the following testfunction will not be executed, the test will proceed to the next
+    testfunction.
+
+    Example:
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 0
+
+    For more examples, refer to the \l{QTestLib Tutorial}.
+
+    \section2 Building a Test
+
+    If you are using \c qmake as your build tool, just add the
+    following to your project file:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 1
+
+    If you are using other buildtools, make sure that you add the location
+    of the QTestLib header files to your include path (usually \c{include/QtTest}
+    under your Qt installation directory). If you are using a release build
+    of Qt, link your test to the \c QtTest library. For debug builds, use
+    \c{QtTest_debug}.
+
+    See \l {Chapter 1: Writing a Unit Test}{Writing a Unit Test} for a step by
+    step explanation.
+
+    \section2 QTestLib Command Line Arguments
+
+    \section3 Syntax
+
+    The syntax to execute an autotest takes the following simple form:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 2
+
+    Substitute \c testname with the name of your executable. \c
+    testfunctions can contain names of test functions to be
+    executed. If no \c testfunctions are passed, all tests are run. If you
+    append the name of an entry in \c testdata, the test function will be
+    run only with that test data.
+
+    For example:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 3
+
+    Runs the test function called \c toUpper with all available test data.
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 4
+
+    Runs the \c toUpper test function with all available test data,
+    and the \c toInt test function with the testdata called \c
+    zero (if the specified test data doesn't exist, the associated test
+    will fail).
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 5
+
+    Runs the testMyWidget function test, outputs every signal
+    emission and waits 500 milliseconds after each simulated
+    mouse/keyboard event.
+
+    \section3 Options
+
+    The following command line arguments are understood:
+
+    \list
+    \o \c -help \BR
+    outputs the possible command line arguments and give some useful help.
+    \o \c -functions \BR
+    outputs all test functions available in the test.
+    \o \c -o \e filename \BR
+    write output to the specified file, rather than to standard output
+    \o \c -silent \BR
+    silent output, only shows warnings, failures and minimal status messages
+    \o \c -v1 \BR
+    verbose output; outputs information on entering and exiting test functions.
+    \o \c -v2 \BR
+    extended verbose output; also outputs each \l QCOMPARE() and \l QVERIFY()
+    \o \c -vs \BR
+    outputs every signal that gets emitted
+    \o \c -xml \BR
+    outputs XML formatted results instead of plain text
+    \o \c -lightxml \BR
+    outputs results as a stream of XML tags
+    \o \c -eventdelay \e ms \BR
+    if no delay is specified for keyboard or mouse simulation
+    (\l QTest::keyClick(),
+    \l QTest::mouseClick() etc.), the value from this parameter
+    (in milliseconds) is substituted.
+    \o \c -keydelay \e ms \BR
+    like -eventdelay, but only influences keyboard simulation and not mouse
+    simulation.
+    \o \c -mousedelay \e ms \BR
+    like -eventdelay, but only influences mouse simulation and not keyboard
+    simulation.
+    \o \c -keyevent-verbose \BR
+    output more verbose output for keyboard simulation
+    \o \c -maxwarnings \e number\BR
+    sets the maximum number of warnings to output. 0 for unlimited, defaults to 2000.
+    \endlist
+
+    \section2 Creating a Benchmark
+    
+    To create a benchmark, follow the instructions for crating a test and then add a
+    QBENCHMARK macro to the test function that you want to benchmark.
+    
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 12
+    
+    The code insde the QBENCHMARK macro will be measured, and possibly also repeated
+    several times in order to get an accurate measurement. This depends on the selected
+    measurement back-end. Several back-ends are available an can be selected on the
+    command line:
+    
+    \target testlib-benchmarking-measurement
+
+    \table
+    \header \o Name
+         \o Commmand-line Arguemnt
+         \o Availability
+    \row \o Walltime
+         \o (default)
+         \o All platforms
+    \row \o CPU tick counter
+         \o -tickcounter
+         \o Windows, Mac OS X, Linux, many UNIX-like systems.
+    \row \o Valgrind/Callgrind
+         \o -callgrind
+         \o Linux (if installed)
+    \row \o Event Counter
+         \o -eventcounter
+         \o All platforms
+    \endtable
+    
+    In short, walltime is always available but requires many repetitions to
+    get a useful result. 
+    Tick counters are usually available and can provide 
+    results with fewer repetitions, but can be susceptible to CPU frequency 
+    scaling issues. 
+    Valgrind provides exact results, but does not take
+    I/O waits into account, and is only available on a limited number of
+    platforms.
+    Event counting is available on all platforms and it provides the number of events
+    that were received by the event loop before they are sent to their corresponding
+    targets (this might include non-Qt events).
+       
+    \note Depending on the device configuration, Tick counters on the
+     Windows CE platform may not be as fine-grained, compared to other platforms.
+     Devices that do not support high-resolution timers default to
+     one-millisecond granularity.
+
+    See the chapter 5 in the \l{QTestLib Tutorial} for more benchmarking examples.
+
+    \section1 Using QTestLib remotely on Windows CE
+    \c cetest is a convenience application which helps the user to launch an 
+    application remotely on a Windows CE device or emulator.
+
+    It needs to be executed after the unit test has been successfully compiled.
+
+    Prior to launching, the following files are copied to the device:
+
+    \list
+    \o all Qt libraries the project links to
+    \o \l {QtRemote}{QtRemote.dll}
+    \o the c runtime library specified during installation
+    \o all files specified in the \c .pro file following the \l DEPLOYMENT rules.
+    \endlist
+
+    \section2 Using \c cetest
+    \section3 Syntax
+    The syntax to execute an autotest takes the following simple form:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 6
+
+    \section3 Options
+    \c cetest provides the same options as those for unit-testing on non cross-compiled
+    platforms. See \l {QTestLib Command Line Arguments} {Command Line Arguments} for
+    more information.
+
+    The following commands are also included:
+
+    \list
+    \o \c -debug \BR
+    Test version compiled in debug mode.
+    \o \c -release \BR
+    Test version compiled in release mode.
+    \o \c -libpath \e path \BR
+    Target path to copy Qt libraries to.
+    \o \c -qt-delete \BR
+    Delete Qt libraries after execution.
+    \o \c -project-delete \BR
+    Delete project files after execution.
+    \o \c -delete \BR
+    Delete project and Qt libraries after execution.
+    \o \c -conf \BR
+    Specifies a qt.conf file to be deployed to remote directory.
+    \endlist
+
+    \note \c{debug} is the default build option.
+
+    \section2 QtRemote
+    \c QtRemote is a small library which is build after QTestLib. It allows the host
+    system to create a process on a remote device and waits until its execution has
+    been finished.
+
+    \section2 Requirements
+    \c cetest uses Microsoft ActiveSync to establish a remote connection between the
+    host computer and the device. Thus header files and libraries are needed to compile
+    cetest and QtRemote successfully.
+
+    Prior to \l{Installing Qt on Windows CE}{installation} of Qt, you need to set your
+    \c INCLUDE and \c LIB environment variables properly.
+
+    A default installation of Windows Mobile 5 for Pocket PC can be obtained by:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 7
+
+    Note that Qt will remember the path, so you do not need to set it again
+    after switching the environments for cross-compilation.
+
+    \section1 3rd Party Code
+
+    The CPU tick counters used for benchmarking is licensed under the following
+    license: (from src/testlib/3rdparty/cycle.h)
+                    
+    \legalese
+    Copyright (c) 2003, 2006 Matteo Frigo\br
+    Copyright (c) 2003, 2006 Massachusetts Institute of Technology
+
+    Permission is hereby granted, free of charge, to any person obtaining
+    a copy of this software and associated documentation files (the
+    "Software"), to deal in the Software without restriction, including
+    without limitation the rights to use, copy, modify, merge, publish,
+    distribute, sublicense, and/or sell copies of the Software, and to
+    permit persons to whom the Software is furnished to do so, subject to
+    the following conditions:
+
+    The above copyright notice and this permission notice shall be
+    included in all copies or substantial portions of the Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+    NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+    LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+    OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+    WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+    \endlegalese
+*/
+
+/*!
+    \page qtestlib-tutorial.html
+    \brief A short introduction to testing with QTestLib.
+    \contentspage QTestLib Manual
+    \nextpage {Chapter 1: Writing a Unit Test}{Chapter 1}
+
+    \title QTestLib Tutorial
+
+    This tutorial gives a short introduction to how to use some of the
+    features of the QTestLib framework. It is divided into four
+    chapters:
+
+    \list 1
+    \o \l {Chapter 1: Writing a Unit Test}{Writing a Unit Test}
+    \o \l {Chapter 2: Data Driven Testing}{Data Driven Testing}
+    \o \l {Chapter 3: Simulating GUI Events}{Simulating GUI Events}
+    \o \l {Chapter 4: Replaying GUI Events}{Replaying GUI Events}
+    \o \l {Chapter 5: Writing a Benchmark}{Writing a Benchmark}
+    \endlist
+
+*/
+
+
+/*!
+    \example qtestlib/tutorial1
+
+    \contentspage {QTestLib Tutorial}{Contents}
+    \nextpage {Chapter 2: Data Driven Testing}{Chapter 2}
+
+    \title Chapter 1: Writing a Unit Test
+
+    In this first chapter we will see how to write a simple unit test
+    for a class, and how to execute it.
+
+    \section1 Writing a Test
+
+    Let's assume you want to test the behavior of our QString class.
+    First, you need a class that contains your test functions. This class
+    has to inherit from QObject:
+
+    \snippet examples/qtestlib/tutorial1/testqstring.cpp 0
+
+    Note that you need to include the QTest header, and that the
+    test functions have to be declared as private slots so the
+    test framework finds and executes it.
+
+    Then you need to implement the test function itself. The
+    implementation could look like this:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 8
+
+    The \l QVERIFY() macro evaluates the expression passed as its
+    argument. If the expression evaluates to true, the execution of
+    the test function continues. Otherwise, a message describing the
+    failure is appended to the test log, and the test function stops
+    executing.
+
+    But if you want a more verbose output to the test log, you should
+    use the \l QCOMPARE() macro instead:
+
+    \snippet examples/qtestlib/tutorial1/testqstring.cpp 1
+
+    If the strings are not equal, the contents of both strings is
+    appended to the test log, making it immediately visible why the
+    comparison failed.
+
+    Finally, to make our test case a stand-alone executable, the
+    following two lines are needed:
+
+    \snippet examples/qtestlib/tutorial1/testqstring.cpp 2
+
+    The \l QTEST_MAIN() macro expands to a simple \c main()
+    method that runs all the test functions. Note that if both the
+    declaration and the implementation of our test class are in a \c
+    .cpp file, we also need to include the generated moc file to make
+    Qt's introspection work.
+
+    \section1 Executing a Test
+
+    Now that we finished writing our test, we want to execute
+    it. Assuming that our test was saved as \c testqstring.cpp in an
+    empty directory: we build the test using qmake to create a project
+    and generate a makefile.
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 9
+
+    \bold {Note:}If you're using windows, replace \c make with \c
+    nmake or whatever build tool you use.
+
+    Running the resulting executable should give you the following
+    output:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 10
+
+    Congratulations! You just wrote and executed your first unit test
+    using the QTestLib framework.
+*/
+
+/*!
+    \example qtestlib/tutorial2
+
+    \previouspage {Chapter 1: Writing a Unit Test}{Chapter 1}
+    \contentspage {QTestLib Tutorial}{Contents}
+    \nextpage {Chapter 3: Simulating Gui Events}{Chapter 3}
+
+    \title Chapter 2: Data Driven Testing
+
+    In this chapter we will demonstrate how to execute a test
+    multiple times with different test data.
+
+    So far, we have hard coded the data we wanted to test into our
+    test function. If we add more test data, the function might look like
+    this:
+
+    \snippet doc/src/snippets/code/doc_src_qtestlib.qdoc 11
+
+    To prevent that the function ends up being cluttered by repetitive
+    code, QTestLib supports adding test data to a test function. All
+    we need is to add another private slot to our test class:
+
+    \snippet examples/qtestlib/tutorial2/testqstring.cpp 0
+
+    \section1 Writing the Data Function
+
+    A test function's associated data function carries the same name,
+    appended by \c{_data}. Our data function looks like this:
+
+    \snippet examples/qtestlib/tutorial2/testqstring.cpp 1
+
+    First, we define the two elements of our test table using the \l
+    QTest::addColumn() function: A test string, and the
+    expected result of applying the QString::toUpper() function to
+    that string.
+
+    Then we add some data to the table using the \l
+    QTest::newRow() function. Each set of data will become a
+    separate row in the test table.
+
+    \l QTest::newRow() takes one argument: A name that will be
+    associated with the data set. If the test fails, the name will be
+    used in the test log, referencing the failed data. Then we
+    stream the data set into the new table row: First an arbitrary
+    string, and then the expected result of applying the
+    QString::toUpper() function to that string.
+
+    You can think of the test data as a two-dimensional table. In
+    our case, it has two columns called \c string and \c result and
+    three rows. In addition a name as well as an index is associated
+    with each row:
+
+    \table
+    \header
+        \o index
+        \o name
+        \o string
+        \o result
+    \row
+        \o 0
+        \o all lower
+        \o "hello"
+        \o HELLO
+    \row
+        \o 1
+        \o mixed
+        \o "Hello"
+        \o HELLO
+    \row
+        \o 2
+        \o all upper
+        \o "HELLO"
+        \o HELLO
+    \endtable
+
+    \section1 Rewriting the Test Function
+
+    Our test function can now be rewritten:
+
+    \snippet examples/qtestlib/tutorial2/testqstring.cpp 2
+
+    The TestQString::toUpper() function will be executed three times,
+    once for each entry in the test table that we created in the
+    associated TestQString::toUpper_data() function.
+
+    First, we fetch the two elements of the data set using the \l
+    QFETCH() macro. \l QFETCH() takes two arguments: The data type of
+    the element and the element name. Then we perform the test using
+    the \l QCOMPARE() macro.
+
+    This approach makes it very easy to add new data to the test
+    without modifying the test itself.
+
+    And again, to make our test case a stand-alone executable,
+    the following two lines are needed:
+
+    \snippet examples/qtestlib/tutorial2/testqstring.cpp 3
+
+    As before, the QTEST_MAIN() macro expands to a simple main()
+    method that runs all the test functions, and since both the
+    declaration and the implementation of our test class are in a .cpp
+    file, we also need to include the generated moc file to make Qt's
+    introspection work.
+*/
+
+/*!
+    \example qtestlib/tutorial3
+
+    \previouspage {Chapter 2 Data Driven Testing}{Chapter 2}
+    \contentspage {QTestLib Tutorial}{Contents}
+    \nextpage {Chapter 4: Replaying GUI Events}{Chapter 4}
+
+    \title Chapter 3: Simulating GUI Events
+
+    QTestLib features some mechanisms to test graphical user
+    interfaces. Instead of simulating native window system events,
+    QTestLib sends internal Qt events. That means there are no
+    side-effects on the machine the tests are running on.
+
+    In this chapter we will se how to write a simple GUI test.
+
+    \section1 Writing a GUI test
+
+    This time, let's assume you want to test the behavior of our
+    QLineEdit class. As before, you will need a class that contains
+    your test function:
+
+    \snippet examples/qtestlib/tutorial3/testgui.cpp 0
+
+    The only difference is that you need to include the QtGui class
+    definitions in addition to the QTest namespace.
+
+    \snippet examples/qtestlib/tutorial3/testgui.cpp 1
+
+    In the implementation of the test function we first create a
+    QLineEdit. Then we simulate writing "hello world" in the line edit
+    using the \l QTest::keyClicks() function.
+
+    \note The widget must also be shown in order to correctly test keyboard
+    shortcuts.
+
+    QTest::keyClicks() simulates clicking a sequence of keys on a
+    widget. Optionally, a keyboard modifier can be specified as well
+    as a delay (in milliseconds) of the test after each key click. In
+    a similar way, you can use the QTest::keyClick(),
+    QTest::keyPress(), QTest::keyRelease(), QTest::mouseClick(),
+    QTest::mouseDClick(), QTest::mouseMove(), QTest::mousePress()
+    and QTest::mouseRelease() functions to simulate the associated
+    GUI events.
+
+    Finally, we use the \l QCOMPARE() macro to check if the line edit's
+    text is as expected.
+
+    As before, to make our test case a stand-alone executable, the
+    following two lines are needed:
+
+    \snippet examples/qtestlib/tutorial3/testgui.cpp 2
+
+    The QTEST_MAIN() macro expands to a simple main() method that
+    runs all the test functions, and since both the declaration and
+    the implementation of our test class are in a .cpp file, we also
+    need to include the generated moc file to make Qt's introspection
+    work.
+*/
+
+/*!
+    \example qtestlib/tutorial4
+
+    \previouspage {Chapter 3: Simulating GUI Event}{Chapter 3}
+    \contentspage {QTestLib Tutorial}{Contents}
+    \nextpage {Chapter 5: Writing a Benchmark}{Chapter 5}
+
+    \title Chapter 4: Replaying GUI Events
+
+    In this chapter, we will show how to simulate a GUI event,
+    and how to store a series of GUI events as well as replay them on
+    a widget.
+
+    The approach to storing a series of events and replay them, is
+    quite similar to the approach explained in \l {Chapter 2:
+    Data Driven Testing}{chapter 2}; all you need is to add a data
+    function to your test class:
+
+    \snippet examples/qtestlib/tutorial4/testgui.cpp 0
+
+    \section1 Writing the Data Function
+
+    As before, a test function's associated data function carries the
+    same name, appended by \c{_data}.
+
+    \snippet examples/qtestlib/tutorial4/testgui.cpp 1
+
+    First, we define the elements of the table using the
+    QTest::addColumn() function: A list of GUI events, and the
+    expected result of applying the list of events on a QWidget. Note
+    that the type of the first element is \l QTestEventList.
+
+    A QTestEventList can be populated with GUI events that can be
+    stored as test data for later usage, or be replayed on any
+    QWidget.
+
+    In our current data function, we create two \l
+    {QTestEventList}s. The first list consists of a single click to
+    the 'a' key. We add the event to the list using the
+    QTestEventList::addKeyClick() function. Then we use the
+    QTest::newRow() function to give the data set a name, and
+    stream the event list and the expected result into the table.
+
+    The second list consists of two key clicks: an 'a' with a
+    following 'backspace'. Again we use the
+    QTestEventList::addKeyClick() to add the events to the list, and
+    QTest::newRow() to put the event list and the expected
+    result into the table with an associated name.
+
+    \section1 Rewriting the Test Function
+
+    Our test can now be rewritten:
+
+    \snippet examples/qtestlib/tutorial4/testgui.cpp 2
+
+    The TestGui::testGui() function will be executed two times,
+    once for each entry in the test data that we created in the
+    associated TestGui::testGui_data() function.
+
+    First, we fetch the two elements of the data set using the \l
+    QFETCH() macro. \l QFETCH() takes two arguments: The data type of
+    the element and the element name. Then we create a QLineEdit, and
+    apply the list of events on that widget using the
+    QTestEventList::simulate() function.
+
+    Finally, we use the QCOMPARE() macro to check if the line edit's
+    text is as expected.
+
+    As before, to make our test case a stand-alone executable,
+    the following two lines are needed:
+
+    \snippet examples/qtestlib/tutorial4/testgui.cpp 3
+
+    The QTEST_MAIN() macro expands to a simple main() method that
+    runs all the test functions, and since both the declaration and
+    the implementation of our test class are in a .cpp file, we also
+    need to include the generated moc file to make Qt's introspection
+    work.
+*/
+
+/*!
+    \example qtestlib/tutorial5
+
+    \previouspage {Chapter 4: Replaying GUI Events}{Chapter 4}
+    \contentspage {QTestLib Tutorial}{Contents}
+
+    \title Chapter 5: Writing a Benchmark
+
+    In this final chapter we will demonstrate how to write benchmarks
+    using QTestLib.
+
+    \section1 Writing a Benchmark
+    To create a benchmark we extend a test function with a QBENCHMARK macro.
+    A benchmark test function will then typically consist of setup code and 
+    a QBENCHMARK macro that contains the code to be measured. This test
+    function benchmarks QString::localeAwareCompare().
+
+    \snippet examples/qtestlib/tutorial5/benchmarking.cpp 0
+
+    Setup can be done at the beginning of the function, the clock is not 
+    running at this point. The code inside the QBENCHMARK macro will be
+    measured, and possibly repeated several times in order to  get an 
+    accurate measurement.
+
+    Several \l {testlib-benchmarking-measurement}{back-ends} are available
+    and can be selected on the command line.
+
+    \section1 Data Functions
+
+    Data functions are useful for creating benchmarks that compare 
+    multiple data inputs, for example locale aware compare against standard
+    compare.
+
+    \snippet examples/qtestlib/tutorial5/benchmarking.cpp 1
+
+    The test function then uses the data to determine what to benchmark.
+
+    \snippet examples/qtestlib/tutorial5/benchmarking.cpp 2
+
+    The "if(useLocaleCompare)" switch is placed outside the QBENCHMARK 
+    macro to avoid measuring its overhead. Each benchmark test function
+    can have one active QBENCHMARK macro. 
+
+    \section1 External Tools
+
+    Tools for handling and visualizing test data are available as part of
+    the \l{qtestlib-tools} project on the Qt Labs Web site. These include
+    a tool for comparing performance data obtained from test runs and a
+    utility to generate Web-based graphs of performance data.
+
+    See the \l{qtestlib-tools Announcement} for more information on these
+    tools and a simple graphing example.
+
+*/
+
+
+
diff --git a/doc/src/development/rcc.qdoc b/doc/src/development/rcc.qdoc
new file mode 100644
index 0000000000..1da641c43c
--- /dev/null
+++ b/doc/src/development/rcc.qdoc
@@ -0,0 +1,95 @@
+/****************************************************************************
+**
+** 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 rcc.html
+    \title Resource Compiler (rcc)
+    \ingroup qttools
+    \keyword rcc
+
+    The \c rcc tool is used to embed resources into a Qt application during
+    the build process. It works by generating a C++ source file containing
+    data specified in a Qt resource (.qrc) file.
+
+    Usage:
+    \snippet doc/src/snippets/code/doc_src_rcc.qdoc 0
+
+    RCC accepts the following command line options:
+
+    \table
+    \header \o Option         \o Argument \o Description
+
+    \row    \o \c{-o}         \o          \o Writes output to file rather than
+                                             stdout.
+
+    \row    \o \c{-name}      \o \c name  \o Creates an external initialization
+                                             function with name.
+
+    \row    \o \c{-threshold} \o \c level \o Specifies a threshold (in bytes)
+                                             to use when compressing files. If
+                                             the file is smaller than the
+                                             threshold, it will not be
+                                             compressed, independent of what
+                                             the compression level is.
+                                             
+    \row    \o \c{-compress}  \o \c level \o Compresses input files with the
+                                             given level. Level is an integer
+                                             from 1 to 9 - 1 being the fastest,
+                                             producing the least compression;
+                                             9 being the slowest, producing
+                                             the most compression.
+
+    \row    \o \c{-root}      \o \c path  \o Prefixes the resource access path
+                                             with root path.
+
+    \row    \o \c{-no-compress} \o        \o Disables all compression.
+
+    \row    \o \c{-binary}    \o          \o Outputs a binary file for use as
+                                             a dynamic resource.
+
+    \row    \o \c{-version}   \o          \o Displays version information.
+
+    \row    \o \c{-help}      \o          \o Displays usage information.
+    \endtable
+
+    See also \l{The Qt Resource System} for more information about embedding
+    resources in Qt applications.
+*/
diff --git a/doc/src/development/tools-list.qdoc b/doc/src/development/tools-list.qdoc
new file mode 100644
index 0000000000..01f71d38a1
--- /dev/null
+++ b/doc/src/development/tools-list.qdoc
@@ -0,0 +1,84 @@
+/****************************************************************************
+**
+** 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$
+**
+****************************************************************************/
+
+/*!
+    \group qttools
+    \title Qt's Tools
+
+    Qt is supplied with several command line and graphical tools to
+    ease and speed the development process. Each tool is listed here
+    with a link to its documentation.
+
+    \table
+    \header \o Tool \o Description
+    \row \o \l{Qt Designer Manual}{Qt Designer}
+         \o Create forms visually.
+    \row \o \l{Qt Assistant Manual}{Qt Assistant}
+         \o Quickly find the help you need.
+    \row \o \l{Qt Linguist Manual}{Qt Linguist, lupdate, lrelease, lconvert}
+         \o Translate applications to reach international markets.
+    \row \o \l{qmake Manual}{qmake}
+         \o Create makefiles from simple platform-independent project files (\c .pro files).
+    \row \o \l{The Virtual Framebuffer}{qvfb}
+         \o Run and test embedded applications on the desktop.
+    \row \o \l{makeqpf}
+         \o Create pre-rendered fonts for embedded devices.
+    \row \o \l{moc}{Meta-Object Compiler (moc)}
+         \o Generate meta-object information for QObject subclasses.
+    \row \o \l{User Interface Compiler (uic)}
+         \o Generate C++ code from user interface files.
+    \row \o \l{Resource Compiler (rcc)}
+         \o Embed resources into Qt applications during the build process.
+    \row \o \l{Configuring Qt}{Configuring Qt (qtconfig)}
+         \o X11-based Qt configuration tool with online help.
+    \row \o \l{Fine-Tuning Features in Qt}{Configuring Qt Embedded (qconfig)}
+         \o Qt Embedded (Linux and Windows CE) configuration tool.
+    \row \o \l{Examples and Demos Launcher}
+         \o A launcher for Qt's Examples and Demonstration programs.
+    \row \o \l{qt3to4 - The Qt 3 to 4 Porting Tool}
+         \o A tool to assist in porting applications from Qt 3 to Qt 4.
+    \row \o \l{QtDBus XML compiler (qdbusxml2cpp)}
+         \o A tool to convert D-Bus interface descriptions to C++ source code.
+    \row \o \l{D-Bus Viewer}
+         \o A tool to introspect D-Bus objects and messages.
+    \endtable
+
+*/
diff --git a/doc/src/development/uic.qdoc b/doc/src/development/uic.qdoc
new file mode 100644
index 0000000000..b05643c13a
--- /dev/null
+++ b/doc/src/development/uic.qdoc
@@ -0,0 +1,88 @@
+/****************************************************************************
+**
+** 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 uic.html
+    \title User Interface Compiler (uic)
+    \ingroup qttools
+    \keyword uic
+
+    \omit KEEP THIS FILE SYNCHRONIZED WITH uic.1 \endomit
+
+    This page documents the \e{User Interface Compiler} for the Qt GUI
+    toolkit. The \c uic reads an XML format user interface definition
+    (\c .ui) file as generated by \l{designer-manual.html}{Qt
+    Designer} and creates a corresponding C++ header file.
+
+    Usage:
+    \snippet doc/src/snippets/code/doc_src_uic.qdoc 0
+
+    \section1 Options
+
+    The following table lists the command-line options recognized by
+    \c uic.
+
+    \table
+    \header \o Option \o Description
+    \row \o \c{-o <file>} \o Write output to \c <file> instead of to standard output.
+    \row \o \c{-tr <func>} \o Use \c <func> for translating strings instead of \c tr().
+    \row \o \c{-p} \o Don't generate guards against multiple inclusion (\c #ifndef FOO_H ...).
+    \row \o \c{-h} \o Display the usage and the list of options.
+    \row \o \c{-v} \o Display \c{uic}'s version number.
+    \endtable
+
+    \section1 Examples
+
+    If you use \c qmake, \c uic will be invoked automatically for
+    header files.
+
+    Here are useful makefile rules if you only use GNU make:
+
+    \snippet doc/src/snippets/code/doc_src_uic.qdoc 1
+
+    If you want to write portably, you can use individual rules of the
+    following form:
+
+    \snippet doc/src/snippets/code/doc_src_uic.qdoc 2
+
+    You must also remember to add \c{ui_foo.h} to your \c HEADERS
+    (substitute your favorite name).
+*/
author	Volker Hilsheimer <volker.hilsheimer@nokia.com>	2009-08-17 18:37:42 +0200
committer	Volker Hilsheimer <volker.hilsheimer@nokia.com>	2009-08-17 18:37:42 +0200
commit	911557fcf7dedc002e689a0d66efd2b77e044bd1 (patch)
tree	a66138f008c27f39e5306dc6f2df01c129e11988 /doc/src/development
parent	285d4b12cb937a5672d6eb15781f03d249f8cfc1 (diff)