diff options
| author | Volker Hilsheimer <volker.hilsheimer@nokia.com> | 2009-08-17 16:37:42 (GMT) |
|---|---|---|
| committer | Volker Hilsheimer <volker.hilsheimer@nokia.com> | 2009-08-17 16:37:42 (GMT) |
| commit | 911557fcf7dedc002e689a0d66efd2b77e044bd1 (patch) | |
| tree | a66138f008c27f39e5306dc6f2df01c129e11988 /doc/src/scripting/scripting.qdoc | |
| parent | 285d4b12cb937a5672d6eb15781f03d249f8cfc1 (diff) | |
| download | Qt-911557fcf7dedc002e689a0d66efd2b77e044bd1.zip Qt-911557fcf7dedc002e689a0d66efd2b77e044bd1.tar.gz Qt-911557fcf7dedc002e689a0d66efd2b77e044bd1.tar.bz2 | |
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.
Diffstat (limited to 'doc/src/scripting/scripting.qdoc')
| -rw-r--r-- | doc/src/scripting/scripting.qdoc | 1929 |
1 files changed, 1929 insertions, 0 deletions
diff --git a/doc/src/scripting/scripting.qdoc b/doc/src/scripting/scripting.qdoc new file mode 100644 index 0000000..5fcf8b2 --- /dev/null +++ b/doc/src/scripting/scripting.qdoc @@ -0,0 +1,1929 @@ +/**************************************************************************** +** +** 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 script + \title Scripting Classes and Overviews + + \brief Classes that add scripting capabilities to Qt applications. +*/ + +/*! + \page scripting.html + \title Making Applications Scriptable + \ingroup frameworks-technologies + + Qt 4.3 and later provides support for application scripting with ECMAScript. + The following guides and references cover aspects of programming with + ECMAScript and Qt. + + \tableofcontents + + \section1 Scripting Classes + + The following classes add scripting capabilities to Qt applications. + + \annotatedlist script + + \section1 Language Overview + + Qt Script is based on the ECMAScript scripting language, as defined + in standard \l{ECMA-262}. Microsoft's JScript, and Netscape's + JavaScript are also based on the ECMAScript standard. For an + overview of ECMAScript, see the + \l{ECMAScript Reference}{ECMAScript reference}. + If you are not familiar with the ECMAScript language, there are + several existing tutorials and books that cover this subject, such + as \l{JavaScript: The Definitive Guide}. + + Existing users of \l{Qt Script for Applications (QSA)} may find the + \l{Moving from QSA to Qt Script} document useful when porting + QSA scripts to Qt Script. + + \section1 Basic Usage + + To evaluate script code, you create a QScriptEngine and call its + evaluate() function, passing the script code (text) to evaluate + as argument. + + \snippet doc/src/snippets/qtscript/evaluation/main.cpp 0 + + The return value will be the result of the evaluation (represented + as a QScriptValue object); this can be converted to standard C++ + and Qt types. + + Custom properties can be made available to scripts by registering + them with the script engine. This is most easily done by setting + properties of the script engine's \e{Global Object}: + + \snippet doc/src/snippets/qtscript/registeringvalues/main.cpp 0 + + This places the properties in the script environment, thus making them + available to script code. + + \section1 Making a QObject Available to the Script Engine + + Any QObject-based instance can be made available for use with scripts. + + When a QObject is passed to the QScriptEngine::newQObject() function, + a Qt Script wrapper object is created that can be used to make the + QObject's signals, slots, properties, and child objects available + to scripts. + + Here's an example of making an instance of a QObject subclass + available to script code under the name \c{"myObject"}: + + \snippet doc/src/snippets/qtscript/registeringobjects/main.cpp 0 + + This will create a global variable called \c{myObject} in the + script environment. The variable serves as a proxy to the + underlying C++ object. Note that the name of the script variable + can be anything; i.e., it is not dependent upon QObject::objectName(). + + The \l{QScriptEngine::}{newQObject()} function accepts two additional + optional arguments: one is the ownership mode, and the other is a + collection of options that allow you to control certain aspects of how + the QScriptValue that wraps the QObject should behave. We will come + back to the usage of these arguments later. + + \section2 Using Signals and Slots + + Qt Script adapts Qt's central \l{Signals and Slots} feature for + scripting. There are three principal ways to use signals and slots + with Qt Script: + + \list + \i \bold{Hybrid C++/script}: C++ application code connects a + signal to a script function. The script function can, for example, be + a function that the user has typed in, or one that you have read from a + file. This approach is useful if you have a QObject but don't want + to expose the object itself to the scripting environment; you just + want a script to be able to define how a signal should be reacted + to, and leave it up to the C++ side of your application to establish + the connection. + + \i \bold{Hybrid script/C++}: A script can connect signals and slots + to establish connections between pre-defined objects that the + application exposes to the scripting environment. In this scenario, + the slots themselves are still written in C++, but the definition of + the connections is fully dynamic (script-defined). + + \i \bold{Purely script-defined}: A script can both define signal + handler functions (effectively "slots written in Qt Script"), + \e{and} set up the connections that utilize those handlers. For + example, a script can define a function that will handle the + QLineEdit::returnPressed() signal, and then connect that signal to the + script function. + \endlist + + Use the qScriptConnect() function to connect a C++ signal to a + script function. In the following example a script signal handler is + defined that will handle the QLineEdit::textChanged() signal: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 47 + + The first two arguments to qScriptConnect() are the same + as you would pass to QObject::connect() to establish a normal C++ + connection. The third argument is the script object that will act + as the \c this object when the signal handler is invoked; in the above + example we pass an invalid script value, so the \c this object will + be the Global Object. The fourth argument is the script function + ("slot") itself. The following example shows how the \c this argument + can be put to use: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 48 + + We create two QLineEdit objects and define a single signal handler + function. The connections use the same handler function, but the + function will be invoked with a different \c this object depending on + which object's signal was triggered, so the output of the print() + statement will be different for each. + + In script code, Qt Script uses a different syntax for connecting to + and disconnecting from signals than the familiar C++ syntax; i.e., + QObject::connect(). + To connect to a signal, you reference the relevant signal as a property + of the sender object, and invoke its \c{connect()} function. There + are three overloads of \c{connect()}, each with a corresponding + \c{disconnect()} overload. The following subsections describe these + three forms. + + \section3 Signal to Function Connections + + \c{connect(function)} + + In this form of connection, the argument to \c{connect()} is the + function to connect to the signal. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 2 + + The argument can be a Qt Script function, as in the above + example, or it can be a QObject slot, as in + the following example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 3 + + When the argument is a QObject slot, the argument types of the + signal and slot do not necessarily have to be compatible; + QtScript will, if necessary, perform conversion of the signal + arguments to match the argument types of the slot. + + To disconnect from a signal, you invoke the signal's + \c{disconnect()} function, passing the function to disconnect + as argument: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 4 + + When a script function is invoked in response to a signal, the + \c this object will be the Global Object. + + \section3 Signal to Member Function Connections + + \c{connect(thisObject, function)} + + In this form of the \c{connect()} function, the first argument + is the object that will be bound to the variable, \c this, when + the function specified using the second argument is invoked. + + If you have a push button in a form, you typically want to do + something involving the form in response to the button's + \c{clicked} signal; passing the form as the \c this object + makes sense in such a case. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 5 + + To disconnect from the signal, pass the same arguments to \c{disconnect()}: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 6 + + \section3 Signal to Named Member Function Connections + + \c{connect(thisObject, functionName)} + + In this form of the \c{connect()} function, the first argument is + the object that will be bound to the variable, \c this, when + a function is invoked in response to the signal. The second argument + specifies the name of a function that is connected to the signal, + and this refers to a member function of the object passed as the + first argument (\c thisObject in the above scheme). + + Note that the function is resolved when the connection is made, not + when the signal is emitted. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 7 + + To disconnect from the signal, pass the same arguments to \c{disconnect()}: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 8 + + \section3 Error Handling + + When \c{connect()} or \c{disconnect()} succeeds, the function will + return \c{undefined}; otherwise, it will throw a script exception. + You can obtain an error message from the resulting \c{Error} object. + Example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 9 + + \section3 Emitting Signals from Scripts + + To emit a signal from script code, you simply invoke the signal + function, passing the relevant arguments: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 10 + + It is currently not possible to define a new signal in a script; + i.e., all signals must be defined by C++ classes. + + \section3 Overloaded Signals and Slots + + When a signal or slot is overloaded, QtScript will attempt to + pick the right overload based on the actual types of the QScriptValue arguments + involved in the function invocation. For example, if your class has slots + \c{myOverloadedSlot(int)} and \c{myOverloadedSlot(QString)}, the following + script code will behave reasonably: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 11 + + You can specify a particular overload by using array-style property access + with the \l{QMetaObject::normalizedSignature()}{normalized signature} of + the C++ function as the property name: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 12 + + If the overloads have different number of arguments, QtScript will + pick the overload with the argument count that best matches the + actual number of arguments passed to the slot. + + For overloaded signals, Qt Script will throw an error if you try to connect + to the signal by name; you have to refer to the signal with the full + normalized signature of the particular overload you want to connect to. + + \section2 Accessing Properties + + The properties of the QObject are available as properties + of the corresponding QtScript object. When you manipulate + a property in script code, the C++ get/set method for that + property will automatically be invoked. For example, if your + C++ class has a property declared as follows: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 13 + + then script code can do things like the following: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 14 + + \section2 Accessing Child QObjects + + Every named child of the QObject (that is, for which + QObject::objectName() is not an empty string) is by default available as + a property of the QtScript wrapper object. For example, + if you have a QDialog with a child widget whose \c{objectName} property is + \c{"okButton"}, you can access this object in script code through + the expression + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 15 + + Since \c{objectName} is itself a Q_PROPERTY, you can manipulate + the name in script code to, for example, rename an object: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 16 + + You can also use the functions \c{findChild()} and \c{findChildren()} + to find children. These two functions behave identically to + QObject::findChild() and QObject::findChildren(), respectively. + + For example, we can use these functions to find objects using strings + and regular expressions: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 17 + + You typically want to use \c{findChild()} when manipulating a form + that uses nested layouts; that way the script is isolated from the + details about which particular layout a widget is located in. + + \section2 Controlling QObject Ownership + + Qt Script uses garbage collection to reclaim memory used by script + objects when they are no longer needed; an object's memory can be + automatically reclaimed when it is no longer referenced anywhere in + the scripting environment. Qt Script lets you control what happens + to the underlying C++ QObject when the wrapper object is reclaimed + (i.e., whether the QObject is deleted or not); you do this when you + create an object by passing an ownership mode as the second argument + to QScriptEngine::newQObject(). + + Knowing how Qt Script deals with ownership is important, since it can + help you avoid situations where a C++ object isn't deleted when it + should be (causing memory leaks), or where a C++ object \e{is} + deleted when it shouldn't be (typically causing a crash if C++ code + later tries to access that object). + + \section3 Qt Ownership + + By default, the script engine does not take ownership of the + QObject that is passed to QScriptEngine::newQObject(); the object + is managed according to Qt's object ownership (see + \l{Object Trees and Object Ownership}). This mode is appropriate + when, for example, you are wrapping C++ objects that are part of + your application's core; that is, they should persist regardless of + what happens in the scripting environment. Another way of stating + this is that the C++ objects should outlive the script engine. + + \section3 Script Ownership + + Specifying QScriptEngine::ScriptOwnership as the ownership mode + will cause the script engine to take full ownership of the QObject + and delete it when it determines that it is safe to do so + (i.e., when there are no more references to it in script code). + This ownership mode is appropriate if the QObject does not have a + parent object, and/or the QObject is created in the context of the + script engine and is not intended to outlive the script engine. + + For example, a constructor function that constructs QObjects + only to be used in the script environment is a good candidate: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 18 + + \section3 Auto-Ownership + + With QScriptEngine::AutoOwnership the ownership is based on whether + the QObject has a parent or not. + If the QtScript garbage collector finds that the QObject is no + longer referenced within the script environment, the QObject will + be deleted \e{only} if it does not have a parent. + + \section3 What Happens When Someone Else Deletes the QObject? + + It is possible that a wrapped QObject is deleted outside of + Qt Script's control; i.e., without regard to the ownership mode + specified. In this case, the wrapper object will still + be an object (unlike the C++ pointer it wraps, the script object + won't become null). Any attempt to access properties of the script + object will, however, result in a script exception being thrown. + + Note that QScriptValue::isQObject() will still return true for a + deleted QObject, since it tests the type of the script object, not + whether the internal pointer is non-null. In other words, if + QScriptValue::isQObject() returns true but QScriptValue::toQObject() + returns a null pointer, this indicates that the QObject has been + deleted outside of Qt Script (perhaps accidentally). + + \section2 Customizing Access to the QObject + + QScriptEngine::newQObject() can take a third argument which allows + you to control various aspects of the access to the QObject through + the QtScript wrapper object it returns. + + QScriptEngine::ExcludeChildObjects specifies that child objects of + the QObject should not appear as properties of the wrapper object. + + QScriptEngine::ExcludeSuperClassProperties and + QScriptEngine::ExcludeSuperClassMethods can be used to avoid + exposing members that are inherited from the QObject's superclass. + This is useful for defining a "pure" interface where inherited members + don't make sense from a scripting perspective; e.g., you don't want + script authors to be able to change the \c{objectName} property of + the object or invoke the \c{deleteLater()} slot. + + QScriptEngine::AutoCreateDynamicProperties specifies that properties + that don't already exist in the QObject should be created as dynamic + properties of the QObject, rather than as properties of the QtScript + wrapper object. If you want new properties to truly become persistent + properties of the QObject, rather than properties that are destroyed + along with the wrapper object (and that aren't shared if the QObject + is wrapped multiple times with QScriptEngine::newQObject()), you + should use this option. + + QScriptEngine::SkipMethodsInEnumeration specifies that signals and + slots should be skipped when enumerating the properties of the QObject + wrapper in a for-in script statement. This is useful when defining + prototype objects, since by convention function properties of + prototypes should not be enumerable. + + \section2 Making a QObject-based Class New-able from a Script + + The QScriptEngine::newQObject() function is used to wrap an + existing QObject instance, so that it can be made available to + scripts. A different scenario is that you want scripts to be + able to construct new objects, not just access existing ones. + + The Qt meta-type system currently does not provide dynamic + binding of constructors for QObject-based classes. If you want to + make such a class new-able from scripts, Qt Script can generate + a reasonable script constructor for you; see + QScriptEngine::scriptValueFromQMetaObject(). + + You can also use QScriptEngine::newFunction() to wrap your own + factory function, and add it to the script environment; see + QScriptEngine::newQMetaObject() for an example. + + \section2 Enum Values + + Values for enums declared with Q_ENUMS are not available as + properties of individual wrapper objects; rather, they are + properties of the QMetaObject wrapper object that can be created + with QScriptEngine::newQMetaObject(). + + \section1 Conversion Between QtScript and C++ Types + + QtScript will perform type conversion when a value needs to be + converted from the script side to the C++ side or vice versa; for + instance, when a C++ signal triggers a script function, when + you access a QObject property in script code, or when + you call QScriptEngine::toScriptValue() or + QScriptEngine::fromScriptValue() in C++. QtScript provides default + conversion operations for many of the built-in Qt types. You can + change the conversion operation for a type (including your custom + C++ types) by registering your own conversion functions with + qScriptRegisterMetaType(). + + \section2 Default Conversion from Qt Script to C++ + + The following table describes the default conversion from a + QScriptValue to a C++ type. + + \table 80% + \header \o C++ Type \o Default Conversion + \row \o bool \o QScriptValue::toBool() + \row \o int \o QScriptValue::toInt32() + \row \o uint \o QScriptValue::toUInt32() + \row \o float \o float(QScriptValue::toNumber()) + \row \o double \o QScriptValue::toNumber() + \row \o short \o short(QScriptValue::toInt32()) + \row \o ushort \o QScriptValue::toUInt16() + \row \o char \o char(QScriptValue::toInt32()) + \row \o uchar \o unsigned char(QScriptValue::toInt32()) + \row \o qlonglong \o qlonglong(QScriptValue::toInteger()) + \row \o qulonglong \o qulonglong(QScriptValue::toInteger()) + \row \o QString \o An empty string if the QScriptValue is null + or undefined; QScriptValue::toString() otherwise. + \row \o QDateTime \o QScriptValue::toDateTime() + \row \o QDate \o QScriptValue::toDateTime().date() + \row \o QRegExp \o QScriptValue::toRegExp() + \row \o QObject* \o QScriptValue::toQObject() + \row \o QWidget* \o QScriptValue::toQObject() + \row \o QVariant \o QScriptValue::toVariant() + \row \o QChar \o If the QScriptValue is a string, the result + is the first character of the string, or a null QChar + if the string is empty; otherwise, the result is a QChar + constructed from the unicode obtained by converting the + QScriptValue to a \c{ushort}. + \row \o QStringList \o If the QScriptValue is an array, the + result is a QStringList constructed from the result of + QScriptValue::toString() for each array element; otherwise, + the result is an empty QStringList. + \row \o QVariantList \o If the QScriptValue is an array, the result + is a QVariantList constructed from the result of + QScriptValue::toVariant() for each array element; otherwise, + the result is an empty QVariantList. + \row \o QVariantMap \o If the QScriptValue is an object, the result + is a QVariantMap with a (key, value) pair of the form + (propertyName, propertyValue.toVariant()) for each property, + using QScriptValueIterator to iterate over the object's + properties. + \row \o QObjectList \o If the QScriptValue is an array, the result + is a QObjectList constructed from the result of + QScriptValue::toQObject() for each array element; otherwise, + the result is an empty QObjectList. + \row \o QList<int> \o If the QScriptValue is an array, the result is + a QList<int> constructed from the result of + QScriptValue::toInt32() for each array element; otherwise, + the result is an empty QList<int>. + \endtable + + Additionally, QtScript will handle the following cases: + + \list + \i If the QScriptValue is a QObject and the target type name ends with + \c * (i.e., it is a pointer), the QObject pointer will be cast to the + target type with qobject_cast(). + \i If the QScriptValue is a QVariant and the target type name ends with + \c * (i.e., it is a pointer), and the \l{QVariant::userType()}{userType()} + of the QVariant is the type that the target type points to, the result + is a pointer to the QVariant's data. + \i If the QScriptValue is a QVariant and it can be converted to the + target type (according to QVariant::canConvert()), the QVariant will + be cast to the target type with qvariant_cast(). + \endlist + + \section2 Default Conversion from C++ to Qt Script + + The following table describes the default behavior when a QScriptValue is + constructed from a C++ type: + + \table 80% + \header \o C++ Type \o Default Construction + \row \o void \o QScriptEngine::undefinedValue() + \row \o bool \o QScriptValue(engine, value) + \row \o int \o QScriptValue(engine, value) + \row \o uint \o QScriptValue(engine, value) + \row \o float \o QScriptValue(engine, value) + \row \o double \o QScriptValue(engine, value) + \row \o short \o QScriptValue(engine, value) + \row \o ushort \o QScriptValue(engine, value) + \row \o char \o QScriptValue(engine, value) + \row \o uchar \o QScriptValue(engine, value) + \row \o QString \o QScriptValue(engine, value) + \row \o qlonglong \o QScriptValue(engine, qsreal(value)). Note that + the conversion may lead to loss of precision, since not all + 64-bit integers can be represented using the qsreal type. + \row \o qulonglong \o QScriptValue(engine, qsreal(value)). Note that + the conversion may lead to loss of precision, since not all + 64-bit unsigned integers can be represented using the qsreal + type. + \row \o QChar \o QScriptValue(this, value.unicode()) + \row \o QDateTime \o \l{QScriptEngine::newDate()}{QScriptEngine::newDate}(value) + \row \o QDate \o \l{QScriptEngine::newDate()}{QScriptEngine::newDate}(value) + \row \o QRegExp \o \l{QScriptEngine::newRegExp()}{QScriptEngine::newRegExp}(value) + \row \o QObject* \o \l{QScriptEngine::newQObject()}{QScriptEngine::newQObject}(value) + \row \o QWidget* \o \l{QScriptEngine::newQObject()}{QScriptEngine::newQObject}(value) + \row \o QVariant \o \l{QScriptEngine::newVariant()}{QScriptEngine::newVariant}(value) + \row \o QStringList \o A new script array (created with + QScriptEngine::newArray()), whose elements are created using + the QScriptValue(QScriptEngine *, QString) constructor for + each element of the list. + \row \o QVariantList \o A new script array (created with + QScriptEngine::newArray()), whose elements are created using + QScriptEngine::newVariant() for each element of the list. + \row \o QVariantMap \o A new script object (created with + QScriptEngine::newObject()), whose properties are initialized + according to the (key, value) pairs of the map. + \row \o QObjectList \o A new script array (created with + QScriptEngine::newArray()), whose elements are created using + QScriptEngine::newQObject() for each element of the list. + \row \o QList<int> \o A new script array (created with + QScriptEngine::newArray()), whose elements are created using + the QScriptValue(QScriptEngine *, int) constructor for each + element of the list. + \endtable + + Other types (including custom types) will be wrapped using + QScriptEngine::newVariant(). For null pointers of any type, the + result is QScriptEngine::nullValue(). + + \section1 How to Design and Implement Application Objects + + This section explains how to implement application objects and + provides the necessary technical background material. + + \section2 Making a C++ object available to Scripts Written in QtScript + + Making C++ classes and objects available to a scripting language is + not trivial because scripting languages tend to be more dynamic than + C++, and it must be possible to introspect objects (query information + such as function names, function signatures, properties, etc., at + run-time). Standard C++ does not provide features for this. + + We can achieve the functionality we want by extending C++, using + C++'s own facilities so our code is still standard C++. The Qt + meta-object system provides the necessary additional functionality. + It allows us to write using an extended C++ syntax, but converts this + into standard C++ using a small utility program called \l{moc} + (Meta-Object Compiler). Classes that wish to take advantage of the + meta-object facilities are either subclasses of QObject, or use the + \c{Q_OBJECT} macro. Qt has used this approach for many years and it has + proven to be solid and reliable. QtScript uses this meta-object + technology to provide scripters with dynamic access to C++ classes + and objects. + + To completely understand how to make C++ objects available to Qt + Script, some basic knowledge of the Qt meta-object system is very + helpful. We recommend that you read the \l{Qt Object Model}. The + information in this document and the documents it links to are very + useful for understanding how to implement application objects. + + However, this knowledge is not essential in the simplest cases. + To make an object available in QtScript, it must derive from + QObject. All classes which derive from QObject can be introspected + and can provide the information needed by the scripting engine at + run-time; e.g., class name, functions, signatures. Because we obtain + the information we need about classes dynamically at run-time, there + is no need to write wrappers for QObject derived classes. + + \section2 Making C++ Class Member Functions Available in QtScript + + The meta-object system also makes information about signals and slots + dynamically available at run-time. By default, for QObject subclasses, + only the signals and slots are automatically made available to scripts. + This is very convenient because, in practice, we normally only want to + make specially chosen functions available to scripters. When you create + a QObject subclass, make sure that the functions you want to expose to + QtScript are public slots. + + For example, the following class definition enables scripting only for + certain functions: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 19 + + In the example above, aNonScriptableFunction() is not declared as a + slot, so it will not be available in QtScript. The other three + functions will automatically be made available in QtScript because + they are declared in the \c{public slots} section of the class + definition. + + It is possible to make any function script-invokable by specifying + the \c{Q_INVOKABLE} modifier when declaring the function: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 20 + + Once declared with \c{Q_INVOKABLE}, the method can be invoked from + QtScript code just as if it were a slot. Although such a method is + not a slot, you can still specify it as the target function in a + call to \c{connect()} in script code; \c{connect()} accepts both + native and non-native functions as targets. + + \section2 Making C++ Class Properties Available in QtScript + + In the previous example, if we wanted to get or set a property using + QtScript we would have to write code like the following: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 21 + + Scripting languages often provide a property syntax to modify and + retrieve properties (in our case the enabled state) of an + object. Many script programmers would want to write the above code + like this: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 22 + + To make this possible, you must define properties in the C++ QObject + subclass. For example, the following \c MyObject class declaration + declares a boolean property called \c enabled, which uses the function + \c{setEnabled(bool)} as its setter function and \c{isEnabled()} as its + getter function: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 23 + + The only difference from the original code is the use of the macro + \c{Q_PROPERTY}, which takes the type and name of the property, and + the names of the setter and getter functions as arguments. + + If you don't want a property of your class to be accessible in + QtScript, you set the \c{SCRIPTABLE} attribute to \c false when + declaring the property; by default, the \c{SCRIPTABLE} attribute is + \c true. For example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 24 + + \section2 Reacting to C++ Objects Signals in Scripts + + In the Qt object model, signals are used as a notification mechanism + between QObjects. This means one object can connect a signal to + another object's slot and, every time the signal is emitted, the slot + is called. This connection is established using the QObject::connect() + function. + + The signals and slots mechanism is also available to QtScript + programmers. The code to declare a signal in C++ is the same, + regardless of whether the signal will be connected to a slot in C++ + or in QtScript. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 25 + + The only change we have made to the code in the previous section is + to declare a signals section with the relevant signal. Now, the + script writer can define a function and connect to the object like + this: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 26 + + \section2 Design of Application Objects + + The previous section described how to implement C++ objects which + can be used in QtScript. Application objects are the same kind of + objects, and they make your application's functionality available to + QtScript scripters. Since the C++ application is already written + in Qt, many objects are already QObjects. The easiest approach would + be to simply add all these QObjects as application objects to the + scripting engine. For small applications this might be sufficient, + but for larger applications this is probably not the right + approach. The problem is that this method reveals too much of the + internal API and gives script programmers access to application + internals which should not be exposed. + + Generally, the best way of making application functionality available + to scripters is to code some QObjects which define the applications + public API using signals, slots, and properties. This gives you + complete control of the functionality made available by the + application. The implementations of these objects simply call the + functions in the application which do the real work. So, instead of + making all your QObjects available to the scripting engine, just add + the wrapper QObjects. + + \section3 Returning QObject Pointers + + If you have a slot that returns a QObject pointer, you should note + that, by default, Qt Script only handles conversion of the types + QObject* and QWidget*. This means that if your slot is declared + with a signature like "MyObject* getMyObject()", QtScript doesn't + automatically know that MyObject* should be handled in the same way + as QObject* and QWidget*. The simplest way to solve this is to only + use QObject* and QWidget* in the method signatures of your scripting + interface. + + Alternatively, you can register conversion functions for your custom + type with the qScriptRegisterMetaType() function. In this way, you + can preserve the precise typing in your C++ declarations, while + still allowing pointers to your custom objects to flow seamlessly + between C++ and scripts. Example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 43 + + \section1 Function Objects and Native Functions + + In Qt Script, functions are first-class values; they are objects that + can have properties of their own, just like any other type of + object. They can be stored in variables and passed as arguments to + other functions. Knowing how function calls in Qt Script behave is + useful when you want to define and use your own script functions. + This section discusses this matter, and also explains how you can + implement native functions; that is, Qt Script functions written in + C++, as opposed to functions written in the scripting language + itself. Even if you will be relying mostly on the dynamic QObject + binding that Qt Script provides, knowing about these powerful + concepts and techniques is important to understand what's actually + going on when script functions are executed. + + \section2 Calling a Qt Script Function from C++ + + Calling a Qt Script function from C++ is achieved with the + QScriptValue::call() function. A typical scenario is that you evaluate a + script that defines a function, and at some point you want to call that + function from C++, perhaps passing it some arguments, and then handle the + result. The following script defines a Qt Script object that has a + toKelvin() function: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 90 + + The toKelvin() function takes a temperature in Kelvin as argument, and + returns the temperature converted to Celsius. The following snippet shows + how the toKelvin() function might be obtained and called from C++: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 91 + + If a script defines a global function, you can access the function as a + property of QScriptEngine::globalObject(). For example, the following script + defines a global function add(): + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 56 + + C++ code might call the add() function as follows: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 92 + + As already mentioned, functions are just values in Qt Script; a function by + itself is not "tied to" a particular object. This is why you have to specify + a \c{this} object (the first argument to QScriptValue::call()) that the + function should be applied to. + + If the function is supposed to act as a method (i.e. it can only be applied + to a certain class of objects), it is up to the function itself to check + that it is being called with a compatible \c{this} object. + + Passing an invalid QScriptValue as the \c{this} argument to + QScriptValue::call() indicates that the Global Object should be used as the + \c{this} object; in other words, that the function should be invoked as a + global function. + + \section2 The \c this Object + + When a Qt Script function is invoked from a script, the \e{way} in which it + is invoked determines the \c this object when the function body is executed, + as the following script example illustrates: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 49 + + An important thing to note is that in Qt Script, unlike C++ and Java, the + \c this object is not part of the execution scope. This means that + member functions (i.e., functions that operate on \c this) must always + use the \c this keyword to access the object's properties. For example, + the following script probably doesn't do what you want: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 50 + + You will get a reference error saying that 'a is not defined' or, worse, + two totally unrelated global variables \c a and \c b will be used to + perform the computation, if they exist. Instead, the script should look + like this: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 51 + + Accidentally omitting the \c this keyword is a typical source of + error for programmers who are used to the scoping rules of C++ and Java. + + \section2 Wrapping a Native Function + + Qt Script provides QScriptEngine::newFunction() as a way of wrapping a + C++ function pointer; this enables you to implement a function in + C++ and add it to the script environment, so that scripts can invoke + your function as if it were a "normal" script function. Here is how the + previous \c{getProperty()} function can be written in C++: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 52 + + Call QScriptEngine::newFunction() to wrap the function. This will + produce a special type of function object that carries a pointer to + the C++ function internally. Once the resulting wrapper has been + added to the scripting environment (e.g., by setting it as a property + of the Global Object), scripts can call the function without having + to know nor care that it is, in fact, a native function. + + Note that the name of the C++ function doesn't matter in the + scripting sense; the name by which the function is invoked by + scripts depends only on what you call the script object property + in which you store the function wrapper. + + It is currently not possible to wrap member functions; i.e., methods + of a C++ class that require a \c this object. + + \section2 The QScriptContext Object + + A QScriptContext holds all the state associated with a particular + invocation of your function. Through the QScriptContext, you can: + \list + \i Get the arguments that were passed to the function. + \i Get the \c this object. + \i Find out whether the function was called with the \c new operator + (the significance of this will be explained later). + \i Throw a script error. + \i Get the function object that's being invoked. + \i Get the activation object (the object used to hold local variables). + \endlist + + The following sections explain how to make use of this + functionality. + + \section2 Processing Function Arguments + + Two things are worth noting about function arguments: + + \list 1 + \o Any script function \mdash including native functions \mdash can + be invoked with any number of arguments. This means that it is up to + the function itself to check the argument count if necessary, and act + accordingly (e.g., throw an error if the number of arguments is + too large, or prepare a default value if the number is too small). + \o A value of any type can be supplied as an argument to any + function. This means that it is up to you to check the type of the + arguments if necessary, and act accordingly (e.g., throw an error + if an argument is not an object of a certain type). + \endlist + + In summary: Qt Script does not automatically enforce any constraints on the + number or type of arguments involved in a function call. + + \section3 Formal Parameters and the Arguments Object + + A native Qt Script function is analogous to a script function that defines no + formal parameters and only uses the built-in \c arguments variable to + process its arguments. To see this, let's first consider how a + script would normally define an \c{add()} function that takes two + arguments, adds them together and returns the result: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 56 + + When a script function is defined with formal parameters, their + names can be viewed as mere aliases of properties of the \c + arguments object; for example, in the \c{add(a, b)} definition's + function body, \c a and \c arguments[0] refer to the same + variable. This means that the \c{add()} function can equivalently be + written like this: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 57 + + This latter form closely matches what a native implementation + typically looks like: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 58 + + \section3 Checking the Number of Arguments + + Again, remember that the presence (or lack) of formal parameter + names in a function definition does not affect how the function + may be invoked; \c{add(1, 2, 3)} is allowed by the engine, as is + \c{add(42)}. In the case of the \c {add()} function, the function + really needs two arguments in order to do something useful. This + can be expressed by the script definition as follows: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 59 + + This would result in an error being thrown if a script invokes + \c{add()} with anything other than two arguments. The native + function can be modified to perform the same check: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 62 + + \section3 Checking the Types of Arguments + + In addition to expecting a certain number of arguments, a function might + expect that those arguments are of certain types (e.g., that the first + argument is a number and that the second is a string). Such a function + should explicitly check the type of arguments and/or perform a conversion, + or throw an error if the type of an argument is incompatible. + + As it is, the native implementation of \c{add()} shown above doesn't + have the exact same semantics as the script counterpart; this is + because the behavior of the Qt Script \c{+} operator depends on the + types of its operands (for example, if one of the operands is a string, + string concatenation is performed). To give the script function + stricter semantics (namely, that it should only add numeric + operands), the argument types can be tested: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 60 + + Then an invocation like \c{add("foo", new Array())} will + cause an error to be thrown. + + The C++ version can call QScriptValue::isNumber() to perform similar + tests: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 63 + + A less strict script implementation might settle for performing an + explicit to-number conversion before applying the \c{+} operator: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 61 + + In a native implementation, this is equivalent to calling + QScriptValue::toNumber() without performing any type test first, + since QScriptValue::toNumber() will automatically perform a type + conversion if necessary. + + To check if an argument is of a certain object type (class), + scripts can use the \c instanceof operator (e.g., \c{"arguments[0] + instanceof Array"} evaluates to true if the first argument is an + Array object); native functions can call QScriptValue::instanceOf(). + + To check if an argument is of a custom C++ type, you typically use + qscriptvalue_cast() and check if the result is valid. For object types, + this means casting to a pointer and checking if it is non-zero; for + value types, the class should have an \c{isNull()}, \c{isValid()} + or similar method. Alternatively, since most custom types are + transported in \l{QVariant}s, you can check if the script value is a + QVariant using QScriptValue::isVariant(), and then check if the + QVariant can be converted to your type using QVariant::canConvert(). + + \section3 Functions with Variable Numbers of Arguments + + Because of the presence of the built-in \c arguments object, + implementing functions that take a variable number of arguments + is simple. In fact, as we have seen, in the technical sense \e{all} + Qt Script functions can be seen as variable-argument functions). + As an example, consider a concat() function that takes an arbitrary + number of arguments, converts the arguments to their string + representation and concatenates the results; for example, + \c{concat("Qt", " ", "Script ", 101)} would return "Qt Script 101". + A script definition of \c{concat()} might look like this: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 64 + + Here is an equivalent native implementation: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 65 + + A second use case for a variable number of arguments is to implement + optional arguments. Here's how a script definition typically does + it: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 66 + + And here's the native equivalent: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 67 + + A third use case for a variable number of arguments is to simulate + C++ overloads. This involves checking the number of arguments and/or + their type at the beginning of the function body (as already shown), + and acting accordingly. It might be worth thinking twice before + doing this, and instead favor unique function names; e.g., having + separate \c{processNumber(number)} and \c{processString(string)} + functions rather than a generic \c{process(anything)} function. + On the caller side, this makes it harder for scripts to accidentally + call the wrong overload (since they don't know or don't comprehend + your custom sophisticated overloading resolution rules), and on the + callee side, you avoid the need for potentially complex (read: + error-prone) checks to resolve ambiguity. + + \section3 Accessing the Arguments Object + + Most native functions use the QScriptContext::argument() function to + access function arguments. However, it is also possible to access + the built-in \c arguments object itself (the one referred to by the + \c arguments variable in script code), by calling the + QScriptContext::argumentsObject() function. This has three principal + applications: + + \list + \o The \c arguments object can be used to easily forward a function + call to another function. In script code, this is what it + typically looks like: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 68 + + For example, \c{foo(10, 20, 30)} would result in the \c{foo()} function + executing the equivalent of \c{bar(10, 20, 30)}. This is useful if + you want to perform some special pre- or post-processing when + calling a function (e.g., to log the call to \c{bar()} without having + to modify the \c{bar()} function itself, like the above example), or if + you want to call a "base implementation" from a prototype + function that has the exact same "signature". In C++, the forwarding + function might look like this: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 69 + + \o The arguments object can serve as input to a QScriptValueIterator, + providing a generic way to iterate over the arguments. A debugger + might use this to display the arguments object in a general purpose + "Qt Script Object Explorer", for example. + + \o The arguments object can be serialized (e.g., with JSON) and transferred + to another entity (e.g., a script engine running in another thread), + where the object can be deserialized and passed as argument to + another script function. + \endlist + + \section2 Constructor Functions + + Some script functions are constructors; they are expected to initialize + new objects. The following snippet is a small example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 75 + + There is nothing special about constructor functions. In fact, any + script function can act as a constructor function (i.e., any function + can serve as the operand to \c{new}). Some functions behave differently + depending on whether they are called as part of a \c{new} expression + or not; for example, the expression \c{new Number(1)} will create a + Number object, whereas \c{Number("123")} will perform a type + conversion. Other functions, like \c{Array()}, will always create + and initialize a new object (e.g., \c{new Array()} and \c{Array()} have + the same effect). + + A native Qt Script function can call the + QScriptContext::isCalledAsConstructor() function to determine if it + is being called as a constructor or as a regular function. When a + function is called as a constructor (i.e., it is the operand in a + \c{new} expression), this has two important implications: + + \list + \i The \c this object, QScriptContext::thisObject(), contains + the new object to be initialized; the engine creates this + new object automatically before invoking your function. This means + that your native constructor function normally doesn't have to (and + shouldn't) create a new object when it is called as a + constructor, since the engine has already prepared a new + object. Instead your function should operate on the supplied + \c this object. + \i The constructor function should return an undefined value, + QScriptEngine::undefinedValue(), to tell the engine that the + \c this object should be the final result of the \c new + operator. Alternatively, the function can return the \c this + object itself. + \endlist + + When QScriptContext::isCalledAsConstructor() returns false, how your + constructor handles this case depends on what behavior you desire. + If, like the built-in \c{Number()} function, a plain function call should + perform a type conversion of its argument, then you perform the conversion + and return the result. If, on the other hand, you want your constructor + to behave \e{as if it was called as a constructor} (with + \c{new}), you have to explicitly create a new object (that is, + ignore the \c this object), initialize that object, and return it. + + The following example implements a constructor function that always + creates and initializes a new object: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 76 + + Given this constructor, scripts would be able to use either the + expression \c{new Person("Bob")} or \c{Person("Bob")} to create a + new \c{Person} object; both behave in the same way. + + There is no equivalent way for a function defined in script + code to determine whether or not it was invoked as a constructor. + + Note that, even though it is not considered good practice, there is + nothing that stops you from choosing to ignore the default + constructed (\c this) object when your function is called as a + constructor and creating your own object anyway; simply have the + constructor return that object. The object will "override" the + default object that the engine constructed (i.e., the default + object will simply be discarded internally). + + \section2 Associating Data with a Function + + Even if a function is global \mdash i.e., not associated with any particular + (type of) object \mdash you might still want to associate some data with it, + so that it becomes self-contained; for example, the function could have + a pointer to some C++ resource that it needs to access. If your application + only uses a single script engine, or the same C++ resource can/should be + shared among all script engines, you can simply use a static C++ variable + and access it from within the native Qt Script function. + + In the case where a static C++ variable or singleton class is + not appropriate, you can call QScriptValue::setProperty() on the + function object, but be aware that those properties will also be + accessible to script code. The alternative is to use QScriptValue::setData(); + this data is not script-accessible. The implementation can access this + internal data through the QScriptContext::callee() function, which + returns the function object being invoked. The following example + shows how this might be used: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 55 + + \section2 Native Functions as Arguments to Functions + + As previously mentioned, a function object can be passed as argument + to another function; this is also true for native functions, + naturally. As an example, here's a native comparison function + that compares its two arguments numerically: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 53 + + The above function can be passed as argument to the standard + \c{Array.prototype.sort} function to sort an array numerically, + as the following C++ code illustrates: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 54 + + Note that, in this case, we are truly treating the native function + object as a value \mdash i.e., we don't store it as a property of the + scripting environment \mdash we simply pass it on as an "anonymous" + argument to another script function and then forget about it. + + \section2 The Activation Object + + Every Qt Script function invocation has an \e{activation object} + associated with it; this object is accessible through the + QScriptContext::activationObject() function. The activation object + is a script object whose properties are the local variables + associated with the invocation (including the arguments for which + the script function has a corresponding formal parameter name). + Thus, getting, modifying, creating and deleting local variables + from C++ is done using the regular QScriptValue::property() and + QScriptValue::setProperty() functions. The activation object itself + is not directly accessible from script code (but it is implicitly + accessed whenever a local variable is read from or written to). + + For C++ code, there are two principal applications of the + activation object: + + \list + \i The activation object provides a standard way to traverse the + variables associated with a function call, by using it as the input + to QScriptValueIterator. This is useful for debugging purposes. + + \i The activation object can be used to prepare local variables + that should be available when a script is evaluated inline; this + can be viewed as a way of passing arguments to the script + itself. This technique is typically used in conjunction with + QScriptEngine::pushContext(), as in the following example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 77 + + We create a temporary execution context, create a local variable + for it, evaluate the script, and finally restore the old context. + \endlist + + \section2 Nested Functions and the Scope Chain + + This is an advanced topic; feel free to skip it. + + A nested function can be used to "capture" the execution context in which a + nested function object is created; this is typically referred to as creating + a \e closure. When, at some later time, the nested function is invoked, it + can access the variables that were created when the enclosing function was + invoked. This can perhaps best be illustrated through a small example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 70 + + The \c{counter()} function initializes a local variable to zero, + and returns a nested function. The nested function increments + the "outer" variable and returns its new value. The variable + persists over function calls, as shown in the following example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 71 + + The \c{counter()} function can be implemented as a native function, too + \mdash or rather, as a pair of native functions: One for the outer and + one for the inner. The definition of the outer function is as follows: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 72 + + The function creates a local variable and initializes it to zero. + Then it wraps the inner native function, and sets the scope of + the resulting function object to be the activation object associated + with this (the outer) function call. The inner function accesses + the "outer" activation through the scope of the callee: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 73 + + It is also possible to have a hybrid approach, where the outer function + is a native function and the inner function is defined by a script: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 74 + + \section2 Property Getters and Setters + + A script object property can be defined in terms of a getter/setter + function, similar to how a Qt C++ property has read and write + functions associated with it. This makes it possible for a script to + use expressions like \c{object.x} instead of \c{object.getX()}; the + getter/setter function for \c{x} will implicitly be invoked + whenever the property is accessed. To scripts, the property looks + and behaves just like a regular object property. + + A single Qt Script function can act as both getter and setter for + a property. When it is called as a getter, the argument count is 0. + When it is called as a setter, the argument count is 1; the argument + is the new value of the property. In the following example, we + define a native combined getter/setter that transforms the value + slightly: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 78 + + The example uses the internal data of the object to store and + retrieve the transformed value. Alternatively, the property + could be stored in another, "hidden" property of the object itself + (e.g., \c{__x__}). A native function is free to implement whatever + storage scheme it wants, as long as the external behavior of the + property itself is consistent (e.g., that scripts should not be able + to distinguish it from a regular property). + + The following C++ code shows how an object property can be defined + in terms of the native getter/setter: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 79 + + When the property is accessed, like in the following script, the + getter/setter does its job behind the scenes: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 80 + + \note It is important that the setter function, not just the getter, + returns the value of the property; i.e., the setter should \e{not} + return QScriptValue::UndefinedValue. This is because the result of + the property assignment is the value returned by the setter, and + not the right-hand side expression. Also note that you normally + should not attempt to read the same property that the getter modifies + within the getter itself, since this will cause the getter to be + called recursively. + + You can remove a property getter/setter by calling + QScriptValue::setProperty(), passing an invalid QScriptValue + as the getter/setter. Remember to specify the + QScriptValue::PropertyGetter/QScriptValue::PropertySetter flag(s), + otherwise the only thing that will happen is that the setter will be + invoked with an invalid QScriptValue as its argument! + + Property getters and setters can be defined and installed by script + code as well, as in the following example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 81 + + Getters and setters can only be used to implement "a priori + properties"; i.e., the technique can't be used to react to an access + to a property that the object doesn't already have. To gain total + control of property access in this way, you need to subclass + QScriptClass. + + \section1 Making Use of Prototype-Based Inheritance + + In ECMAScript, inheritance is based on the concept of \e{shared + prototype objects}; this is quite different from the class-based + inheritance familiar to C++ programmers. With QtScript, you can + associate a custom prototype object with a C++ type using + QScriptEngine::setDefaultPrototype(); this is the key to providing + a script interface to that type. Since the QtScript module is built + on top of Qt's meta-type system, this can be done for any C++ type. + + You might be wondering when exactly you would need to use this + functionality in your application; isn't the automatic binding + provided by QScriptEngine::newQObject() enough? No, not under all + circumstances. + Firstly, not every C++ type is derived from QObject; types that + are not QObjects cannot be introspected through Qt's meta-object + system (they do not have properties, signals and slots). Secondly, + even if a type is QObject-derived, the functionality you want to + expose to scripts might not all be available, since it is unusual to + define every function to be a slot (and it's not always + possible/desirable to change the C++ API to make it so). + + It is perfectly possible to solve this problem by using "conventional" + C++ techniques. For instance, the QRect class could effectively be + made scriptable by creating a QObject-based C++ wrapper class with + \c{x}, \c{y}, \c{width} properties and so on, which forwarded property + access and function calls to the wrapped value. However, as we shall + see, by taking advantage of the ECMAScript object model and combining + it with Qt's meta-object system, we can arrive at a solution that is + more elegant, consistent and lightweight, supported by a small API. + + This section explains the underlying concepts of prototype-based + inheritance. Once these concepts are understood, the associated + practices can be applied throughout the QtScript API in order to + create well-behaved, consistent bindings to C++ that will fit nicely + into the ECMAScript universe. + + When experimenting with QtScript objects and inheritance, it can be + helpful to use the interactive interpreter included with the + \l{Qt Script Examples}, located in \c{examples/script/qscript}. + + \section2 Prototype Objects and Shared Properties + + The purpose of a QtScript \e{prototype object} is to define + behavior that should be shared by a set of other QtScript + objects. We say that objects which share the same prototype object + belong to the same \e{class} (again, on the technical side this + should not to be confused with the class constructs of languages + like C++ and Java; ECMAScript has no such construct). + + The basic prototype-based inheritance mechanism works as follows: Each + QtScript object has an internal link to another object, its + \e{prototype}. When a property is looked up in an object, and the + object itself does not have the property, the property is looked up + in the prototype object instead; if the prototype has the property, + then that property is returned. Otherwise, the property is looked up + in the prototype of the prototype object, and so on; this chain of + objects constitutes a \e{prototype chain}. The chain of prototype + objects is followed until the property is found or the end of the + chain is reached. + + For example, when you create a new object by the expression \c{new + Object()}, the resulting object will have as its prototype the + standard \c{Object} prototype, \c{Object.prototype}; through this + prototype relation, the new object inherits a set of properties, + including the \c{hasOwnProperty()} function and \c{toString()} + function: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 27 + + The \c{toString()} function itself is not defined in \c{o} (since we + did not assign anything to \c{o.toString}), so instead the + \c{toString()} function in the standard \c{Object} prototype is + called, which returns a highly generic string representation of + \c{o} ("[object Object]"). + + Note that the properties of the prototype object are not \e{copied} to + the new object; only a \e{link} from the new object to the prototype + object is maintained. This means that changes done to the prototype + object will immediately be reflected in the behavior of all objects + that have the modified object as their prototype. + + \section2 Defining Classes in a Prototype-Based Universe + + In QtScript, a class is not defined explicitly; there is no + \c{class} keyword. Instead, you define a new class in two steps: + + \list 1 + \i Define a \e{constructor function} that will initialize new objects. + \i Set up a \e{prototype object} that defines the class interface, and + assign this object to the public \c{prototype} property of the + constructor function. + \endlist + + With this arrangement, the constructor's public \c{prototype} + property will automatically be set as the prototype of objects created + by applying the \c{new} operator to your constructor function; + e.g., the prototype of an object created by \c{new Foo()} will be the + value of \c{Foo.prototype}. + + Functions that don't operate on the \c this object ("static" methods) + are typically stored as properties of the constructor function, not + as properties of the prototype object. The same is true for + constants, such as enum values. + + The following code defines a simple constructor function for a class + called \c{Person}: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 28 + + Next, you want to set up \c{Person.prototype} as your prototype + object; i.e., define the interface that should be common to all + \c{Person} objects. QtScript automatically creates a default + prototype object (by the expression \c{new Object()}) for every + script function; you can add properties to this object, or you can + assign your own custom object. (Generally speaking, any QtScript + object can act as prototype for any other object.) + + Here's an example of how you might want to override the + \c{toString()} function that \c{Person.prototype} inherits from + \c{Object.prototype}, to give your \c{Person} objects a more + appropriate string representation: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 29 + + This resembles the process of reimplementing a virtual function + in C++. Henceforth, when the property named \c{toString} is + looked up in a \c{Person} object, it will be resolved in + \c{Person.prototype}, not in \c{Object.prototype} as before: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 30 + + There are also some other interesting things we can learn about a + \c{Person} object: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 31 + + The \c{hasOwnProperty()} function is not inherited from + \c{Person.prototype}, but rather from \c{Object.prototype}, which is + the prototype of \c{Person.prototype} itself; i.e., the prototype + chain of \c{Person} objects is \c{Person.prototype} followed by + \c{Object.prototype}. This prototype chain establishes a \e{class + hierarchy}, as demonstrated by applying the \c{instanceof} operator; + \c{instanceof} checks if the value of the public \c{prototype} + property of the constructor function on the right-hand side is + reached by following the prototype chain of the object on the + left-hand side. + + When defining subclasses, there's a general pattern you can use. The + following example shows how one can create a subclass of \c{Person} + called \c{Employee}: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 32 + + Again, you can use the \c{instanceof} to verify that the + class relationship between \c{Employee} and \c{Person} has been + correctly established: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 33 + + This shows that the prototype chain of \c{Employee} objects is the + same as that of \c{Person} objects, but with \c{Employee.prototype} + added to the front of the chain. + + \section2 Prototype-Based Programming with the QtScript C++ API + + You can use QScriptEngine::newFunction() to wrap + native functions. When implementing a constructor function, + you also pass the prototype object as an argument to + QScriptEngine::newFunction(). + You can call QScriptValue::construct() to call a constructor + function, and you can use QScriptValue::call() from within a + native constructor function if you need to call a base class + constructor. + + The QScriptable class provides a convenient way to implement a + prototype object in terms of C++ slots and properties. Take a look + at the \l{Default Prototypes Example} to see how this is done. + Alternatively, the prototype functionality can be implemented in + terms of standalone native functions that you wrap with + QScriptEngine::newFunction() and set as properties of your prototype + object by calling QScriptValue::setProperty(). + + In the implementation of your prototype functions, you use + QScriptable::thisObject() (or QScriptContext::thisObject()) to + obtain a reference to the QScriptValue being operated upon; then you + call qscriptvalue_cast() to cast it to your C++ type, and perform + the relevant operations using the usual C++ API for the type. + + You associate a prototype object with a C++ type by calling + QScriptEngine::setDefaultPrototype(). Once this mapping is + established, QtScript will automatically assign the correct + prototype when a value of such a type is wrapped in a QScriptValue; + either when you explicitly call QScriptEngine::toScriptValue(), or + when a value of such a type is returned from a C++ slot and + internally passed back to script code by the engine. This means you + \e{don't} have to implement wrapper classes if you use this + approach. + + As an example, let's consider how the \c{Person} class from the + preceding section can be implemented in terms of the Qt Script API. + We begin with the native constructor function: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 34 + + Here's the native equivalent of the \c{Person.prototype.toString} + function we saw before: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 35 + + The \c{Person} class can then be initialized as follows: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 36 + + The implementation of the \c{Employee} subclass is similar. We + use QScriptValue::call() to call the super-class (Person) constructor: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 37 + + The \c{Employee} class can then be initialized as follows: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 38 + + When implementing the prototype object of a class, you may want to use + the QScriptable class, as it enables you to define the API of your + script class in terms of Qt properties, signals and slots, and + automatically handles value conversion between the Qt Script and C++ + side. + + \section2 Implementing Prototype Objects for Value-based Types + + When implementing a prototype object for a value-based type -- + e.g. QPointF -- the same general technique applies; you populate + a prototype object with functionality that should be shared + among instances. You then associate the prototype object with + the type by calling QScriptEngine::setDefaultPrototype(). This + ensures that when e.g. a value of the relevant type is returned + from a slot back to the script, the prototype link of the script + value will be initialized correctly. + + When values of the custom type are stored in QVariants -- which Qt + Script does by default --, qscriptvalue_cast() enables you to safely + cast the script value to a pointer to the C++ type. This makes it + easy to do type-checking, and, for prototype functions that should + modify the underlying C++ value, lets you modify the actual value + contained in the script value (and not a copy of it). + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 39 + + \section2 Implementing Constructors for Value-based Types + + You can implement a constructor function for a value-based type + by wrapping a native factory function. For example, the following + function implements a simple constructor for QPoint: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 44 + + In the above code we simplified things a bit, e.g. we didn't check + the argument count to decide which QPoint C++ constructor to use. + In your own constructors you have to do this type of resolution + yourself, i.e. by checking the number of arguments passed to the + native function, and/or by checking the type of the arguments and + converting the arguments to the desired type. If you detect a problem + with the arguments you may want to signal this by throwing a script + exception; see QScriptContext::throwError(). + + \section2 Managing Non-QObject-based Objects + + For value-based types (e.g. QPoint), the C++ object will be destroyed when + the Qt Script object is garbage-collected, so managing the memory of the C++ + object is not an issue. For QObjects, Qt Script provides several + alternatives for managing the underlying C++ object's lifetime; see the + \l{Controlling QObject Ownership} section. However, for polymorphic types + that don't inherit from QObject, and when you can't (or won't) wrap the type + in a QObject, you have to manage the lifetime of the C++ object yourself. + + A behavior that's often reasonable when a Qt Script object wraps a C++ + object, is that the C++ object is deleted when the Qt Script object is + garbage-collected; this is typically the case when the objects can be + constructed by scripts, as opposed to the application providing the scripts + with pre-made "environment" objects. A way of making the lifetime of the C++ + object follow the lifetime of the Qt Script object is by using a shared + pointer class, such as QSharedPointer, to hold a pointer to your object; + when the Qt Script object containing the QSharedPointer is + garbage-collected, the underlying C++ object will be deleted if there are no + other references to the object. + + The following snippet shows a constructor function that constructs + QXmlStreamReader objects that are stored using QSharedPointer: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 93 + + Prototype functions can use qscriptvalue_cast() to cast the \c this object + to the proper type: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 94 + + The prototype and constructor objects are set up in the usual way: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 95 + + Scripts can now construct QXmlStreamReader objects by calling the \c + XmlStreamReader constructor, and when the Qt Script object is + garbage-collected (or the script engine is destroyed), the QXmlStreamReader + object is destroyed as well. + + \section1 Defining Custom Script Classes with QScriptClass + + There are cases where neither the dynamic QObject binding provided + by QScriptEngine::newQObject() or the manual binding provided by + QScriptEngine::newFunction() is sufficient. For example, you might + want to implement a dynamic script proxy to an underlying object; + or you might want to implement an array-like class (i.e. that gives + special treatment to properties that are valid array indexes, and + to the property "length"). In such cases, you can subclass + QScriptClass to achieve the desired behavior. + + QScriptClass allows you to handle all property access for a + (class of) script object through virtual get/set property functions. + Iteration of custom properties is also supported through the + QScriptClassPropertyIterator class; this means you can advertise + properties to be reported by for-in script statements and + QScriptValueIterator. + + \section1 Error Handling and Debugging Facilities + + Syntax errors in scripts will be reported as soon as a script is + evaluated; QScriptEngine::evaluate() will return a SyntaxError object + that you can convert to a string to get a description of the error. + + The QScriptEngine::uncaughtExceptionBacktrace() function gives you + a human-readable backtrace of the last uncaught exception. In order + to get useful filename information in backtraces, you should pass + proper filenames to QScriptEngine::evaluate() when evaluating your + scripts. + + Often an exception doesn't happen at the time the script is evaluated, + but at a later time when a function defined by the script is actually + executed. For C++ signal handlers, this is tricky; consider the case + where the clicked() signal of a button is connected to a script function, + and that script function causes a script exception when it is handling + the signal. Where is that script exception propagated to? + + The solution is to connect to the QScriptEngine::signalHandlerException() + signal; this will give you notification when a signal handler causes + an exception, so that you can find out what happened and/or recover + from it. + + In Qt 4.4 the QScriptEngineAgent class was introduced. QScriptEngineAgent + provides an interface for reporting low-level "events" in a script engine, + such as when a function is entered or when a new script statement is + reached. By subclassing QScriptEngineAgent you can be notified of these + events and perform some action, if you want. QScriptEngineAgent itself + doesn't provide any debugging-specific functionality (e.g. setting + breakpoints), but it is the basis of tools that do. + + The QScriptEngineDebugger class introduced in Qt 4.5 provides a + \l{Qt Script Debugger Manual}{Qt Script debugger} that can be embedded + into your application. + + \section2 Redefining print() + + Qt Script provides a built-in print() function that can be useful for + simple debugging purposes. The built-in print() function writes to + standard output. You can redefine the print() function (or add your + own function, e.g. debug() or log()) that redirects the text to + somewhere else. The following code shows a custom print() that adds + text to a QPlainTextEdit. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 45 + + The following code shows how the custom print() function may be + initialized and used. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 46 + + A pointer to the QPlainTextEdit is stored as an internal property + of the script function itself, so that it can be retrieved when + the function is called. + + \section1 Using QtScript Extensions + + The QScriptEngine::importExtension() function can be used to load plugins + into a script engine. Plugins typically add some extra functionality to + the engine; for example, a plugin might add full bindings for the Qt + Arthur painting API, so that those classes may be used from Qt Script + scripts. There are currently no script plugins shipped with Qt. + + If you are implementing some Qt Script functionality that you want other + Qt application developers to be able to use, \l{Creating QtScript Extensions} + {developing an extension} (e.g. by subclassing QScriptExtensionPlugin) is + worth looking into. + + \section1 Internationalization + + Since Qt 4.5, Qt Script supports internationalization of scripts by building + on the C++ internationalization functionality (see \l{Internationalization + with Qt}). + + \section2 Use qsTr() for All Literal Text + + Wherever your script uses "quoted text" for text that will be presented to + the user, ensure that it is processed by the QCoreApplication::translate() + function. Essentially all that is necessary to achieve this is to use + the qsTr() script function. Example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 82 + + This accounts for 99% of the user-visible strings you're likely to write. + + The qsTr() function uses the basename of the script's filename (see + QFileInfo::baseName()) as the translation context; if the filename is not + unique in your project, you should use the qsTranslate() function and pass a + suitable context as the first argument. Example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 83 + + If you need to have translatable text completely outside a function, there + are two functions to help: QT_TR_NOOP() and QT_TRANSLATE_NOOP(). They merely + mark the text for extraction by the \c lupdate utility described below. At + runtime, these functions simply return the text to translate unmodified. + + Example of QT_TR_NOOP(): + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 84 + + Example of QT_TRANSLATE_NOOP(): + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 85 + + \section2 Use String.prototype.arg() for Dynamic Text + + The String.prototype.arg() function (which is modeled after QString::arg()) + offers a simple means for substituting arguments: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 86 + + \section2 Produce Translations + + Once you are using qsTr() and/or qsTranslate() throughout your scripts, you + can start producing translations of the user-visible text in your program. + + The \l{Qt Linguist manual} provides further information about + Qt's translation tools, \e{Qt Linguist}, \c lupdate and \c + lrelease. + + Translation of Qt Script scripts is a three-step process: + + \list 1 + + \o Run \c lupdate to extract translatable text from the script source code + of the Qt application, resulting in a message file for translators (a TS + file). The utility recognizes qsTr(), qsTranslate() and the + \c{QT_TR*_NOOP()} functions described above and produces TS files + (usually one per language). + + \o Provide translations for the source texts in the TS file, using + \e{Qt Linguist}. Since TS files are in XML format, you can also + edit them by hand. + + \o Run \c lrelease to obtain a light-weight message file (a QM + file) from the TS file, suitable only for end use. Think of the TS + files as "source files", and QM files as "object files". The + translator edits the TS files, but the users of your application + only need the QM files. Both kinds of files are platform and + locale independent. + + \endlist + + Typically, you will repeat these steps for every release of your + application. The \c lupdate utility does its best to reuse the + translations from previous releases. + + When running \c lupdate, you must specify the location of the script(s), + and the name of the TS file to produce. Examples: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 87 + + will extract translatable text from \c myscript.qs and create the + translation file \c myscript_la.qs. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 88 + + will extract translatable text from all files ending with \c{.qs} in the + \c scripts folder and create the translation file \c scripts_la.qs. + + Alternatively, you can create a separate qmake project file that sets up + the \c SOURCES and \c TRANSLATIONS variables appropriately; then run + \c lupdate with the project file as input. + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 89 + + When running \c lrelease, you must specify the name of the TS input + file; or, if you are using a qmake project file to manage script + translations, you specify the name of that file. \c lrelease will create + \c myscript_la.qm, the binary representation of the translation. + + \section2 Apply Translations + + In your application, you must use QTranslator::load() to load the + translation files appropriate for the user's language, and install them + using QCoreApplication::installTranslator(). Finally, you must call + QScriptEngine::installTranslatorFunctions() to make the script translation + functions (qsTr(), qsTranslate() and \c{QT_TR*_NOOP()}) available to scripts + that are subsequently evaluated by QScriptEngine::evaluate(). For scripts + that are using the qsTr() function, the proper filename must be passed as + second argument to QScriptEngine::evaluate(). + + \c linguist, \c lupdate and \c lrelease are installed in the \c bin + subdirectory of the base directory Qt is installed into. Click Help|Manual + in \e{Qt Linguist} to access the user's manual; it contains a tutorial + to get you started. + + See also the \l{Hello Script Example}. + + \section1 ECMAScript Compatibility + + QtScript implements all the built-in classes and functions defined + in ECMA-262. + + The Date parsing and string conversion functions are implemented using + QDateTime::fromString() and QDateTime::toString(), respectively. + + The RegExp class is a wrapper around QRegExp. The QRegExp semantics + do not precisely match the semantics for regular expressions defined + in ECMA-262. + + \section1 QtScript Extensions to ECMAScript + + \list + \i \c{__proto__} \br + The prototype of an object (QScriptValue::prototype()) + can be accessed through its \c{__proto__} property in script code. + This property has the QScriptValue::Undeletable flag set. + For example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 40 + + \i \c{Object.prototype.__defineGetter__} \br + This function installs a + getter function for a property of an object. The first argument is + the property name, and the second is the function to call to get + the value of that property. When the function is invoked, the + \c this object will be the object whose property is accessed. + For example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 41 + + \i \c{Object.prototype.__defineSetter__} \br + This function installs a + setter function for a property of an object. The first argument is + the property name, and the second is the function to call to set + the value of that property. When the function is invoked, the + \c this object will be the object whose property is accessed. + For example: + + \snippet doc/src/snippets/code/doc_src_qtscript.qdoc 42 + + \i \c{Function.prototype.connect} \br + This function connects + a signal to a slot. Usage of this function is described in + the section \l{Using Signals and Slots}. + + \i \c{Function.prototype.disconnect} \br + This function disconnects + a signal from a slot. Usage of this function is described in + the section \l{Using Signals and Slots}. + + \i \c{QObject.prototype.findChild} \br + This function is semantically equivalent to QObject::findChild(). + + \i \c{QObject.prototype.findChildren} \br + This function is semantically equivalent to QObject::findChildren(). + + \i \c{QObject.prototype.toString} \br + This function returns a default string representation of a QObject. + + \i \c{gc} \br + This function invokes the garbage collector. + + \i \c{Error.prototype.backtrace} \br + This function returns a human-readable backtrace, in the form of + an array of strings. + + \i Error objects have the following additional properties: + \list + \i \c{lineNumber}: The line number where the error occurred. + \i \c{fileName}: The file name where the error occurred (if a file name + was passed to QScriptEngine::evaluate()). + \i \c{stack}: An array of objects describing the stack. Each object has + the following properties: + \list + \i \c{functionName}: The function name, if available. + \i \c{fileName}: The file name, if available. + \i \c{lineNumber}: The line number, if available. + \endlist + \endlist + + \endlist + + */ |