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/frameworks-technologies/model-view-programming.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/frameworks-technologies/model-view-programming.qdoc')
| -rw-r--r-- | doc/src/frameworks-technologies/model-view-programming.qdoc | 2498 |
1 files changed, 2498 insertions, 0 deletions
diff --git a/doc/src/frameworks-technologies/model-view-programming.qdoc b/doc/src/frameworks-technologies/model-view-programming.qdoc new file mode 100644 index 0000000..b38edd8 --- /dev/null +++ b/doc/src/frameworks-technologies/model-view-programming.qdoc @@ -0,0 +1,2498 @@ +/**************************************************************************** +** +** 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 model-view + \title Model/View Classes +*/ + +/*! + \page model-view-programming.html + \nextpage An Introduction to Model/View Programming + \startpage index.html Qt Reference Documentation + + \title Model/View Programming + \brief A guide to the extensible model/view architecture used by Qt's + item view classes. + + \ingroup frameworks-technologies + + \list + \o \l{An Introduction to Model/View Programming} + \tableofcontents{1 An Introduction to Model/View Programming} + \o \l{Using Models and Views} + \tableofcontents{1 Using Models and Views} + \o \l{Model Classes} + \tableofcontents{1 Model Classes} + \o \l{Creating New Models} + \tableofcontents{1 Creating New Models} + \o \l{View Classes} + \tableofcontents{1 View Classes} + \o \l{Handling Selections in Item Views} + \tableofcontents{1 Handling Selections in Item Views} + \o \l{Delegate Classes} + \tableofcontents{1 Delegate Classes} + \o \l{Item View Convenience Classes} + \tableofcontents{1 Item View Convenience Classes} + \o \l{Using Drag and Drop with Item Views} + \tableofcontents{1 Using Drag and Drop with Item Views} + \o \l{Proxy Models} + \tableofcontents{1 Proxy Models} + \o \l{Model Subclassing Reference} + \tableofcontents{1 Model Subclassing Reference} + \endlist + + \keyword Model/View Classes + \section1 All Model/View Classes + + These classes use the model/view design pattern in which the + underlying data (in the model) is kept separate from the way the data + is presented and manipulated by the user (in the view). + + \annotatedlist model-view + + \section1 Related Examples + + \list + \o \l{itemviews/dirview}{Dir View} + \o \l{itemviews/spinboxdelegate}{Spin Box Delegate} + \o \l{itemviews/pixelator}{Pixelator} + \o \l{itemviews/simpletreemodel}{Simple Tree Model} + \o \l{itemviews/chart}{Chart} + \endlist +*/ + +/*! + \page model-view-introduction.html + \previouspage Model/View Programming + \nextpage Using Models and Views + \startpage index.html Qt Reference Documentation + + \title An Introduction to Model/View Programming + + \tableofcontents + + Qt 4 introduces a new set of item view classes that use a model/view + architecture to manage the relationship between data and the way it + is presented to the user. The separation of functionality introduced by + this architecture gives developers greater flexibility to customize the + presentation of items, and provides a standard model interface to allow + a wide range of data sources to be used with existing item views. + In this document, we give a brief introduction to the model/view paradigm, + outline the concepts involved, and describe the architecture of the item + view system. Each of the components in the architecture is explained, + and examples are given that show how to use the classes provided. + + \section1 The Model/View Architecture + + Model-View-Controller (MVC) is a design pattern originating from + Smalltalk that is often used when building user interfaces. + In \l{Design Patterns}, Gamma et al. write: + + \quotation + MVC consists of three kinds of objects. The Model is the application + object, the View is its screen presentation, and the Controller defines + the way the user interface reacts to user input. Before MVC, user + interface designs tended to lump these objects together. MVC decouples + them to increase flexibility and reuse. + \endquotation + + If the view and the controller objects are combined, the result is + the model/view architecture. This still separates the way that data + is stored from the way that it is presented to the user, but provides + a simpler framework based on the same principles. This separation + makes it possible to display the same data in several different views, + and to implement new types of views, without changing the underlying + data structures. + To allow flexible handling of user input, we introduce the concept of + the \e delegate. The advantage of having a delegate in this framework + is that it allows the way items of data are rendered and edited to be + customized. + + \table + \row \i \inlineimage modelview-overview.png + \i \bold{The model/view architecture} + + The model communicates with a source of data, providing an \e interface + for the other components in the architecture. The nature of the + communication depends on the type of data source, and the way the model + is implemented. + + The view obtains \e{model indexes} from the model; these are references + to items of data. By supplying model indexes to the model, the view can + retrieve items of data from the data source. + + In standard views, a \e delegate renders the items of data. When an item + is edited, the delegate communicates with the model directly using + model indexes. + \endtable + + Generally, the model/view classes can be separated into the three groups + described above: models, views, and delegates. Each of these components + is defined by \e abstract classes that provide common interfaces and, + in some cases, default implementations of features. + Abstract classes are meant to be subclassed in order to provide the full + set of functionality expected by other components; this also allows + specialized components to be written. + + Models, views, and delegates communicate with each other using \e{signals + and slots}: + + \list + \o Signals from the model inform the view about changes to the data + held by the data source. + \o Signals from the view provide information about the user's interaction + with the items being displayed. + \o Signals from the delegate are used during editing to tell the + model and view about the state of the editor. + \endlist + + \section2 Models + + All item models are based on the QAbstractItemModel class. This class + defines an interface that is used by views and delegates to access data. + The data itself does not have to be stored in the model; it can be held + in a data structure or repository provided by a separate class, a file, + a database, or some other application component. + + The basic concepts surrounding models are presented in the section + on \l{Model Classes}. + + QAbstractItemModel + provides an interface to data that is flexible enough to handle views + that represent data in the form of tables, lists, and trees. However, + when implementing new models for list and table-like data structures, + the QAbstractListModel and QAbstractTableModel classes are better + starting points because they provide appropriate default implementations + of common functions. Each of these classes can be subclassed to provide + models that support specialized kinds of lists and tables. + + The process of subclassing models is discussed in the section on + \l{Creating New Models}. + + Qt provides some ready-made models that can be used to handle items of + data: + + \list + \o QStringListModel is used to store a simple list of QString items. + \o QStandardItemModel manages more complex tree structures of items, each + of which can contain arbitrary data. + \o QDirModel provides information about files and directories in the local + filing system. + \o QSqlQueryModel, QSqlTableModel, and QSqlRelationalTableModel are used + to access databases using model/view conventions. + \endlist + + If these standard models do not meet your requirements, you can subclass + QAbstractItemModel, QAbstractListModel, or QAbstractTableModel to create + your own custom models. + + \section2 Views + + Complete implementations are provided for different kinds of + views: QListView displays a list of items, QTableView displays data + from a model in a table, and QTreeView shows model items of data in a + hierarchical list. Each of these classes is based on the + QAbstractItemView abstract base class. Although these classes are + ready-to-use implementations, they can also be subclassed to provide + customized views. + + The available views are examined in the section on \l{View Classes}. + + \section2 Delegates + + QAbstractItemDelegate is the abstract base class for delegates in the + model/view framework. Since Qt 4.4, the default delegate implementation is + provided by QStyledItemDelegate, and this is used as the default delegate + by Qt's standard views. However, QStyledItemDelegate and QItemDelegate are + independent alternatives to painting and providing editors for items in + views. The difference between them is that QStyledItemDelegate uses the + current style to paint its items. We therefore recommend using + QStyledItemDelegate as the base class when implementing custom delegates or + when working with Qt style sheets. + + Delegates are described in the section on \l{Delegate Classes}. + + \section2 Sorting + + There are two ways of approaching sorting in the model/view + architecture; which approach to choose depends on your underlying + model. + + If your model is sortable, i.e, if it reimplements the + QAbstractItemModel::sort() function, both QTableView and QTreeView + provide an API that allows you to sort your model data + programmatically. In addition, you can enable interactive sorting + (i.e. allowing the users to sort the data by clicking the view's + headers), by connecting the QHeaderView::sortIndicatorChanged() signal + to the QTableView::sortByColumn() slot or the + QTreeView::sortByColumn() slot, respectively. + + The alternative approach, if your model do not have the required + interface or if you want to use a list view to present your data, + is to use a proxy model to transform the structure of your model + before presenting the data in the view. This is covered in detail + in the section on \l {Proxy Models}. + + \section2 Convenience Classes + + A number of \e convenience classes are derived from the standard view + classes for the benefit of applications that rely on Qt's item-based + item view and table classes. They are not intended to be subclassed, + but simply exist to provide a familiar interface to the equivalent classes + in Qt 3. + Examples of such classes include \l QListWidget, \l QTreeWidget, and + \l QTableWidget; these provide similar behavior to the \c QListBox, + \c QListView, and \c QTable classes in Qt 3. + + These classes are less flexible than the view classes, and cannot be + used with arbitrary models. We recommend that you use a model/view + approach to handling data in item views unless you strongly need an + item-based set of classes. + + If you wish to take advantage of the features provided by the model/view + approach while still using an item-based interface, consider using view + classes, such as QListView, QTableView, and QTreeView with + QStandardItemModel. + + \section1 The Model/View Components + + The following sections describe the way in which the model/view pattern + is used in Qt. Each section provides an example of use, and is followed + by a section showing how you can create new components. +*/ + +/*! + \page model-view-using.html + \contentspage model-view-programming.html Contents + \previouspage An Introduction to Model/View Programming + \nextpage Model Classes + + \title Using Models and Views + + \tableofcontents + + \section1 Introduction + + Two of the standard models provided by Qt are QStandardItemModel and + QDirModel. QStandardItemModel is a multi-purpose model that can be used + to represent various different data structures needed by list, table, + and tree views. This model also holds the items of data. + QDirModel is a model that maintains information about the contents of a + directory. As a result, it does not hold any items of data itself, but + simply represents files and directories on the local filing system. + + QDirModel provides a ready-to-use model to experiment with, and can be + easily configured to use existing data. Using this model, we can show how + to set up a model for use with ready-made views, and explore how to + manipulate data using model indexes. + + \section1 Using Views with an Existing Model + + The QListView and QTreeView classes are the most suitable views + to use with QDirModel. The example presented below displays the + contents of a directory in a tree view next to the same information in + a list view. The views share the user's selection so that the selected + items are highlighted in both views. + + \img shareddirmodel.png + + We set up a QDirModel so that it is ready for use, and create some + views to display the contents of a directory. This shows the simplest + way to use a model. The construction and use of the model is + performed from within a single \c main() function: + + \snippet doc/src/snippets/shareddirmodel/main.cpp 0 + + The model is set up to use data from a default directory. We create two + views so that we can examine the items held in the model in two + different ways: + + \snippet doc/src/snippets/shareddirmodel/main.cpp 5 + + The views are constructed in the same way as other widgets. Setting up + a view to display the items in the model is simply a matter of calling its + \l{QAbstractItemView::setModel()}{setModel()} function with the directory + model as the argument. The calls to + \l{QAbstractItemView::setRootIndex()}{setRootIndex()} tell the views which + directory to display by supplying a \e{model index} that we obtain from + the directory model. + + The \c index() function used in this case is unique to QDirModel; we supply + it with a directory and it returns a model index. Model indexes are + discussed in the \l{Model Classes} chapter. + + The rest of the function just displays the views within a splitter + widget, and runs the application's event loop: + + \snippet doc/src/snippets/shareddirmodel/main.cpp 8 + + In the above example, we neglected to mention how to handle selections + of items. This subject is covered in more detail in the chapter on + \l{Handling Selections in Item Views}. Before examining how selections + are handled, you may find it useful to read the \l{Model Classes} chapter + which describes the concepts used in the model/view framework. +*/ + +/*! + \page model-view-model.html + \contentspage model-view-programming.html Contents + \previouspage Using Models and Views + \nextpage Creating New Models + + \title Model Classes + + \tableofcontents + + \section1 Basic Concepts + + In the model/view architecture, the model provides a standard interface + that views and delegates use to access data. In Qt, the standard + interface is defined by the QAbstractItemModel class. No matter how the + items of data are stored in any underlying data structure, all subclasses + of QAbstractItemModel represent the data as a hierarchical structure + containing tables of items. Views use this \e convention to access items + of data in the model, but they are not restricted in the way that they + present this information to the user. + + \image modelview-models.png + + Models also notify any attached views about changes to data through the + signals and slots mechanism. + + This chapter describes some basic concepts that are central to the way + item of data are accessed by other components via a model class. More + advanced concepts are discussed in later chapters. + + \section2 Model Indexes + + To ensure that the representation of the data is kept separate from the + way it is accessed, the concept of a \e{model index} is introduced. Each + piece of information that can be obtained via a model is represented by + a model index. Views and delegates use these indexes to request items of + data to display. + + As a result, only the model needs to know how to obtain data, and the type + of data managed by the model can be defined fairly generally. Model indexes + contain a pointer to the model that created them, and this prevents + confusion when working with more than one model. + + \snippet doc/src/snippets/code/doc_src_model-view-programming.qdoc 0 + + Model indexes provide \e temporary references to pieces of information, and + can be used to retrieve or modify data via the model. Since models may + reorganize their internal structures from time to time, model indexes may + become invalid, and \e{should not be stored}. If a long-term reference to a + piece of information is required, a \e{persistent model index} must be + created. This provides a reference to the information that the model keeps + up-to-date. Temporary model indexes are provided by the QModelIndex class, + and persistent model indexes are provided by the QPersistentModelIndex + class. + + To obtain a model index that corresponds to an item of data, three + properties must be specified to the model: a row number, a column number, + and the model index of a parent item. The following sections describe + and explain these properties in detail. + + \section2 Rows and Columns + + In its most basic form, a model can be accessed as a simple table in which + items are located by their row and column numbers. \e{This does not mean + that the underlying pieces of data are stored in an array structure}; the + use of row and column numbers is only a convention to allow components to + communicate with each other. We can retrieve information about any given + item by specifying its row and column numbers to the model, and we receive + an index that represents the item: + + \snippet doc/src/snippets/code/doc_src_model-view-programming.qdoc 1 + + Models that provide interfaces to simple, single level data structures like + lists and tables do not need any other information to be provided but, as + the above code indicates, we need to supply more information when obtaining + a model index. + + \table + \row \i \inlineimage modelview-tablemodel.png + \i \bold{Rows and columns} + + The diagram shows a representation of a basic table model in which each + item is located by a pair of row and column numbers. We obtain a model + index that refers to an item of data by passing the relevant row and + column numbers to the model. + + \snippet doc/src/snippets/code/doc_src_model-view-programming.qdoc 2 + + Top level items in a model are always referenced by specifying + \c QModelIndex() as their parent item. This is discussed in the next + section. + \endtable + + \section2 Parents of Items + + The table-like interface to item data provided by models is ideal when + using data in a table or list view; the row and column number system maps + exactly to the way the views display items. However, structures such as + tree views require the model to expose a more flexible interface to the + items within. As a result, each item can also be the parent of another + table of items, in much the same way that a top-level item in a tree view + can contain another list of items. + + When requesting an index for a model item, we must provide some information + about the item's parent. Outside the model, the only way to refer to an + item is through a model index, so a parent model index must also be given: + + \snippet doc/src/snippets/code/doc_src_model-view-programming.qdoc 3 + + \table + \row \i \inlineimage modelview-treemodel.png + \i \bold{Parents, rows, and columns} + + The diagram shows a representation of a tree model in which each item is + referred to by a parent, a row number, and a column number. + + Items "A" and "C" are represented as top-level siblings in the model: + + \snippet doc/src/snippets/code/doc_src_model-view-programming.qdoc 4 + + Item "A" has a number of children. A model index for item "B" is + obtained with the following code: + + \snippet doc/src/snippets/code/doc_src_model-view-programming.qdoc 5 + \endtable + + \section2 Item Roles + + Items in a model can perform various \e roles for other components, + allowing different kinds of data to be supplied for different situations. + For example, Qt::DisplayRole is used to access a string that can be + displayed as text in a view. Typically, items contain data for a number of + different roles, and the standard roles are defined by Qt::ItemDataRole. + + We can ask the model for the item's data by passing it the model index + corresponding to the item, and by specifying a role to obtain the type + of data we want: + + \snippet doc/src/snippets/code/doc_src_model-view-programming.qdoc 6 + + \table + \row \i \inlineimage modelview-roles.png + \i \bold{Item roles} + + The role indicates to the model which type of data is being referred to. + Views can display the roles in different ways, so it is important to + supply appropriate information for each role. + + The \l{Creating New Models} section covers some specific uses of roles in + more detail. + \endtable + + Most common uses for item data are covered by the standard roles defined in + Qt::ItemDataRole. By supplying appropriate item data for each role, models + can provide hints to views and delegates about how items should be + presented to the user. Different kinds of views have the freedom to + interpret or ignore this information as required. It is also possible to + define additional roles for application-specific purposes. + + \section2 Summary of Concepts + + \list + \o Model indexes give views and delegates information about the location + of items provided by models in a way that is independent of any + underlying data structures. + \o Items are referred to by their row and column numbers, and by the model + index of their parent items. + \o Model indexes are constructed by models at the request of other + components, such as views and delegates. + \o If a valid model index is specified for the parent item when an index is + requested using \l{QAbstractItemModel::index()}{index()}, the index + returned will refer to an item beneath that parent item in the + model. + The index obtained refers to a child of that item. + \o If an invalid model index is specified for the parent item when an index + is requested using \l{QAbstractItemModel::index()}{index()}, the index + returned will refer to a top-level item in the model. + \o The \l{Qt::ItemDataRole}{role} distinguishes between the + different kinds of data associated with an item. + \endlist + + \section2 Using Model Indexes + + To demonstrate how data can be retrieved from a model, using model + indexes, we set up a QDirModel without a view and display the + names of files and directories in a widget. + Although this does not show a normal way of using a model, it demonstrates + the conventions used by models when dealing with model indexes. + + We construct a directory model in the following way: + + \snippet doc/src/snippets/simplemodel-use/main.cpp 0 + + In this case, we set up a default QDirModel, obtain a parent index using + a specific implementation of \l{QDirModel::index()}{index()} provided by + that model, and we count the number of rows in the model using the + \l{QDirModel::rowCount()}{rowCount()} function. + + For simplicity, we are only interested in the items in the first column + of the model. We examine each row in turn, obtaining a model index for + the first item in each row, and read the data stored for that item + in the model. + + \snippet doc/src/snippets/simplemodel-use/main.cpp 1 + + To obtain a model index, we specify the row number, column number (zero + for the first column), and the appropriate model index for the parent + of all the items that we want. + The text stored in each item is retrieved using the model's + \l{QDirModel::data()}{data()} function. We specify the model index and + the \l{Qt::ItemDataRole}{DisplayRole} to obtain data for the + item in the form of a string. + + \snippet doc/src/snippets/simplemodel-use/main.cpp 2 + \codeline + \snippet doc/src/snippets/simplemodel-use/main.cpp 3 + + The above example demonstrates the basic principles used to retrieve + data from a model: + + \list + \i The dimensions of a model can be found using + \l{QAbstractItemModel::rowCount()}{rowCount()} and + \l{QAbstractItemModel::columnCount()}{columnCount()}. + These functions generally require a parent model index to be + specified. + \i Model indexes are used to access items in the model. The row, column, + and parent model index are needed to specify the item. + \i To access top-level items in a model, specify a null model index + as the parent index with \c QModelIndex(). + \i Items contain data for different roles. To obtain the data for a + particular role, both the model index and the role must be supplied + to the model. + \endlist + + + \section1 Further Reading + + New models can be created by implementing the standard interface provided + by QAbstractItemModel. In the \l{Creating New Models} chapter, we will + demonstrate this by creating a convenient ready-to-use model for holding + lists of strings. +*/ + +/*! + \page model-view-view.html + \contentspage model-view-programming.html Contents + \previouspage Creating New Models + \nextpage Handling Selections in Item Views + + \title View Classes + + \tableofcontents + + \section1 Concepts + + In the model/view architecture, the view obtains items of data from the + model and presents them to the user. The way that the data is + presented need not resemble the representation of the data provided by + the model, and may be \e{completely different} from the underlying data + structure used to store items of data. + + The separation of content and presentation is achieved by the use of a + standard model interface provided by QAbstractItemModel, a standard view + interface provided by QAbstractItemView, and the use of model indexes + that represent items of data in a general way. + Views typically manage the overall layout of the data obtained from + models. They may render individual items of data themselves, or use + \l{Delegate Classes}{delegates} to handle both rendering and editing + features. + + As well as presenting data, views handle navigation between items, + and some aspects of item selection. The views also implement basic + user interface features, such as context menus and drag and drop. + A view can provide default editing facilities for items, or it may + work with a \l{Delegate Classes}{delegate} to provide a custom + editor. + + A view can be constructed without a model, but a model must be + provided before it can display useful information. Views keep track of + the items that the user has selected through the use of + \l{Handling Selections in Item Views}{selections} which can be maintained + separately for each view, or shared between multiple views. + + Some views, such as QTableView and QTreeView, display headers as well + as items. These are also implemented by a view class, QHeaderView. + Headers usually access the same model as the view that contains them. + They retrieve data from the model using the + \l{QAbstractItemModel::headerData()} function, and usually display + header information in the form of a label. New headers can be + subclassed from the QHeaderView class to provide more specialized + labels for views. + + \section1 Using an Existing View + + Qt provides three ready-to-use view classes that present data from + models in ways that are familiar to most users. + QListView can display items from a model as a simple list, or in the + form of a classic icon view. QTreeView displays items from a + model as a hierarchy of lists, allowing deeply nested structures to be + represented in a compact way. QTableView presents items from a model + in the form of a table, much like the layout of a spreadsheet + application. + + \img standard-views.png + + The default behavior of the standard views shown above should be + sufficient for most applications. They provide basic editing + facilities, and can be customized to suit the needs of more specialized + user interfaces. + + \section2 Using a Model + + We take the string list model that \l{Creating New Models}{we created as + an example model}, set it up with some data, and construct a view to + display the contents of the model. This can all be performed within a + single function: + + \snippet doc/src/snippets/stringlistmodel/main.cpp 0 + + Note that the \c StringListModel is declared as a \l QAbstractItemModel. + This allows us to use the abstract interface to the model, and + ensures that the code will still work even if we replace the string list + model with a different model in the future. + + The list view provided by \l QListView is sufficient for presenting + the items in the string list model. We construct the view, and set up + the model using the following lines of code: + + \snippet doc/src/snippets/stringlistmodel/main.cpp 2 + \snippet doc/src/snippets/stringlistmodel/main.cpp 4 + + The view is shown in the normal way: + + \snippet doc/src/snippets/stringlistmodel/main.cpp 5 + + The view renders the contents of a model, accessing data via the model's + interface. When the user tries to edit an item, the view uses a default + delegate to provide an editor widget. + + \img stringlistmodel.png + + The above image shows how a QListView represents the data in the string + list model. Since the model is editable, the view automatically allows + each item in the list to be edited using the default delegate. + + \section2 Using Multiple Views onto the Same Model + + Providing multiple views onto the same model is simply a matter of + setting the same model for each view. In the following code we create + two table views, each using the same simple table model which we have + created for this example: + + \snippet doc/src/snippets/sharedtablemodel/main.cpp 0 + \codeline + \snippet doc/src/snippets/sharedtablemodel/main.cpp 1 + + The use of signals and slots in the model/view architecture means that + changes to the model can be propagated to all the attached views, + ensuring that we can always access the same data regardless of the + view being used. + + \img sharedmodel-tableviews.png + + The above image shows two different views onto the same model, each + containing a number of selected items. Although the data from the model + is shown consistently across view, each view maintains its own internal + selection model. This can be useful in certain situations but, for + many applications, a shared selection model is desirable. + + \section1 Handling Selections of Items + + The mechanism for handling selections of items within views is provided + by the \l QItemSelectionModel class. All of the standard views construct + their own selection models by default, and interact with them in the + normal way. The selection model being used by a view can be obtained + through the \l{QAbstractItemView::selectionModel()}{selectionModel()} + function, and a replacement selection model can be specified with + \l{QAbstractItemView::setSelectionModel()}{setSelectionModel()}. + The ability to control the selection model used by a view is useful + when we want to provide multiple consistent views onto the same model + data. + + Generally, unless you are subclassing a model or view, you will not + need to manipulate the contents of selections directly. However, the + interface to the selection model can be accessed, if required, and + this is explored in the chapter on + \l{Handling Selections in Item Views}. + + \section2 Sharing Selections Between Views + + Although it is convenient that the view classes provide their own + selection models by default, when we use more than one view onto the + same model it is often desirable that both the model's data and the + user's selection are shown consistently in all views. + Since the view classes allow their internal selection models to be + replaced, we can achieve a unified selection between views with the + following line: + + \snippet doc/src/snippets/sharedtablemodel/main.cpp 2 + + The second view is given the selection model for the first view. + Both views now operate on the same selection model, keeping both + the data and the selected items synchronized. + + \img sharedselection-tableviews.png + + In the example shown above, two views of the same type were used to + display the same model's data. However, if two different types of view + were used, the selected items may be represented very differently in + each view; for example, a contiguous selection in a table view can be + represented as a fragmented set of highlighted items in a tree view. + +*/ + +/*! + \page model-view-delegate.html + \contentspage model-view-programming.html Contents + \previouspage Handling Selections in Item Views + \nextpage Item View Convenience Classes + + \title Delegate Classes + + \tableofcontents + + \section1 Concepts + + Unlike the Model-View-Controller pattern, the model/view design does not + include a completely separate component for managing interaction with + the user. Generally, the view is responsible for the presentation of + model data to the user, and for processing user input. To allow some + flexibility in the way this input is obtained, the interaction is + performed by delegates. These components provide input capabilities + and are also responsible for rendering individual items in some views. + The standard interface for controlling delegates is defined in the + \l QAbstractItemDelegate class. + + Delegates are expected to be able to render their contents themselves + by implementing the \l{QItemDelegate::paint()}{paint()} + and \l{QItemDelegate::sizeHint()}{sizeHint()} functions. + However, simple widget-based delegates can subclass \l QItemDelegate + instead of \l QAbstractItemDelegate, and take advantage of the default + implementations of these functions. + + Editors for delegates can be implemented either by using widgets to manage + the editing process or by handling events directly. + The first approach is covered later in this chapter, and it is also + shown in the \l{Spin Box Delegate Example}{Spin Box Delegate} example. + + The \l{Pixelator Example}{Pixelator} example shows how to create a + custom delegate that performs specialized rendering for a table view. + + \section1 Using an Existing Delegate + + The standard views provided with Qt use instances of \l QItemDelegate + to provide editing facilities. This default implementation of the + delegate interface renders items in the usual style for each of the + standard views: \l QListView, \l QTableView, and \l QTreeView. + + All the standard roles are handled by the default delegate used by + the standard views. The way these are interpreted is described in the + QItemDelegate documentation. + + The delegate used by a view is returned by the + \l{QAbstractItemView::itemDelegate()}{itemDelegate()} function. + The \l{QAbstractItemView::setItemDelegate()}{setItemDelegate()} function + allows you to install a custom delegate for a standard view, and it is + necessary to use this function when setting the delegate for a custom + view. + + \section1 A Simple Delegate + + The delegate implemented here uses a \l QSpinBox to provide editing + facilities, and is mainly intended for use with models that display + integers. Although we set up a custom integer-based table model for + this purpose, we could easily have used \l QStandardItemModel instead + since the custom delegate will control data entry. We construct a + table view to display the contents of the model, and this will use + the custom delegate for editing. + + \img spinboxdelegate-example.png + + We subclass the delegate from \l QItemDelegate because we do not want + to write custom display functions. However, we must still provide + functions to manage the editor widget: + + \snippet examples/itemviews/spinboxdelegate/delegate.h 0 + + Note that no editor widgets are set up when the delegate is + constructed. We only construct an editor widget when it is needed. + + \section2 Providing an Editor + + In this example, when the table view needs to provide an editor, it + asks the delegate to provide an editor widget that is appropriate + for the item being modified. The + \l{QAbstractItemDelegate::createEditor()}{createEditor()} function is + supplied with everything that the delegate needs to be able to set up + a suitable widget: + + \snippet examples/itemviews/spinboxdelegate/delegate.cpp 1 + + Note that we do not need to keep a pointer to the editor widget because + the view takes responsibility for destroying it when it is no longer + needed. + + We install the delegate's default event filter on the editor to ensure + that it provides the standard editing shortcuts that users expect. + Additional shortcuts can be added to the editor to allow more + sophisticated behavior; these are discussed in the section on + \l{#EditingHints}{Editing Hints}. + + The view ensures that the editor's data and geometry are set + correctly by calling functions that we define later for these purposes. + We can create different editors depending on the model index supplied + by the view. For example, if we have a column of integers and a column + of strings we could return either a \c QSpinBox or a \c QLineEdit, + depending on which column is being edited. + + The delegate must provide a function to copy model data into the + editor. In this example, we read the data stored in the + \l{Qt::ItemDataRole}{display role}, and set the value in the + spin box accordingly. + + \snippet examples/itemviews/spinboxdelegate/delegate.cpp 2 + + In this example, we know that the editor widget is a spin box, but we + could have provided different editors for different types of data in + the model, in which case we would need to cast the widget to the + appropriate type before accessing its member functions. + + \section2 Submitting Data to the Model + + When the user has finished editing the value in the spin box, the view + asks the delegate to store the edited value in the model by calling the + \l{QAbstractItemDelegate::setModelData()}{setModelData()} function. + + \snippet examples/itemviews/spinboxdelegate/delegate.cpp 3 + + Since the view manages the editor widgets for the delegate, we only + need to update the model with the contents of the editor supplied. + In this case, we ensure that the spin box is up-to-date, and update + the model with the value it contains using the index specified. + + The standard \l QItemDelegate class informs the view when it has + finished editing by emitting the + \l{QAbstractItemDelegate::closeEditor()}{closeEditor()} signal. + The view ensures that the editor widget is closed and destroyed. In + this example, we only provide simple editing facilities, so we need + never emit this signal. + + All the operations on data are performed through the interface + provided by \l QAbstractItemModel. This makes the delegate mostly + independent from the type of data it manipulates, but some + assumptions must be made in order to use certain types of + editor widgets. In this example, we have assumed that the model + always contains integer values, but we can still use this + delegate with different kinds of models because \l{QVariant} + provides sensible default values for unexpected data. + + \section2 Updating the Editor's Geometry + + It is the responsibility of the delegate to manage the editor's + geometry. The geometry must be set when the editor is created, and + when the item's size or position in the view is changed. Fortunately, + the view provides all the necessary geometry information inside a + \l{QStyleOptionViewItem}{view option} object. + + \snippet examples/itemviews/spinboxdelegate/delegate.cpp 4 + + In this case, we just use the geometry information provided by the + view option in the item rectangle. A delegate that renders items with + several elements would not use the item rectangle directly. It would + position the editor in relation to the other elements in the item. + + \target EditingHints + \section2 Editing Hints + + After editing, delegates should provide hints to the other components + about the result of the editing process, and provide hints that will + assist any subsequent editing operations. This is achieved by + emitting the \l{QAbstractItemDelegate::closeEditor()}{closeEditor()} + signal with a suitable hint. This is taken care of by the default + QItemDelegate event filter which we installed on the spin box when + it was constructed. + + The behavior of the spin box could be adjusted to make it more user + friendly. In the default event filter supplied by QItemDelegate, if + the user hits \key Return to confirm their choice in the spin box, + the delegate commits the value to the model and closes the spin box. + We can change this behavior by installing our own event filter on the + spin box, and provide editing hints that suit our needs; for example, + we might emit \l{QAbstractItemDelegate::closeEditor()}{closeEditor()} + with the \l{QAbstractItemDelegate::EndEditHint}{EditNextItem} hint to + automatically start editing the next item in the view. + + Another approach that does not require the use of an event + filter is to provide our own editor widget, perhaps subclassing + QSpinBox for convenience. This alternative approach would give us + more control over how the editor widget behaves at the cost of + writing additional code. It is usually easier to install an event + filter in the delegate if you need to customize the behavior of + a standard Qt editor widget. + + Delegates do not have to emit these hints, but those that do not will + be less integrated into applications, and will be less usable than + those that emit hints to support common editing actions. +*/ + +/*! + \page model-view-selection.html + \contentspage model-view-programming.html Contents + \previouspage View Classes + \nextpage Delegate Classes + + \title Handling Selections in Item Views + + \tableofcontents + + \section1 Concepts + + The selection model used in the item view classes offers many improvements + over the selection model used in Qt 3. It provides a more general + description of selections based on the facilities of the model/view + architecture. Although the standard classes for manipulating selections are + sufficient for the item views provided, the selection model allows you to + create specialized selection models to suit the requirements for your own + item models and views. + + Information about the items selected in a view is stored in an instance of + the \l QItemSelectionModel class. This maintains model indexes for items in + a single model, and is independent of any views. Since there can be many + views onto a model, it is possible to share selections between views, + allowing applications to show multiple views in a consistent way. + + Selections are made up of \e{selection ranges}. These efficiently maintain + information about large selections of items by recording only the starting + and ending model indexes for each range of selected items. Non-contiguous + selections of items are constructed by using more than one selection range + to describe the selection. + + Selections are applied to a collection of model indexes held by a selection + model. The most recent selection of items applied is known as the + \e{current selection}. The effects of this selection can be modified even + after its application through the use of certain types of selection + commands. These are discussed later in this section. + + + \section2 Current Item and Selected Items + + In a view, there is always a current item and a selected item - two + independent states. An item can be the current item and selected at the + same time. The view is responsible for ensuring that there is always a + current item as keyboard navigation, for example, requires a current item. + + The table below highlights the differences between current item and + selected items. + + \table + \header + \o Current Item + \o Selected Items + + \row + \o There can only be one current item. + \o There can be multiple selected items. + \row + \o The current item will be changed with key navigation or mouse + button clicks. + \o The selected state of items is set or unset, depending on several + pre-defined modes - e.g., single selection, multiple selection, + etc. - when the user interacts with the items. + \row + \o The current item will be edited if the edit key, \gui F2, is + pressed or the item is double-clicked (provided that editing is + enabled). + \o The current item can be used together with an anchor to specify a + range that should be selected or deselected (or a combination of + the two). + \row + \o The current item is indicated by the focus rectangle. + \o The selected items are indicated with the selection rectangle. + \endtable + + When manipulating selections, it is often helpful to think of + \l QItemSelectionModel as a record of the selection state of all the items + in an item model. Once a selection model is set up, collections of items + can be selected, deselected, or their selection states can be toggled + without the need to know which items are already selected. The indexes of + all selected items can be retrieved at any time, and other components can + be informed of changes to the selection model via the signals and slots + mechanism. + + + \section1 Using a Selection Model + + The standard view classes provide default selection models that can + be used in most applications. A selection model belonging to one view + can be obtained using the view's + \l{QAbstractItemView::selectionModel()}{selectionModel()} function, + and shared between many views with + \l{QAbstractItemView::setSelectionModel()}{setSelectionModel()}, + so the construction of new selection models is generally not required. + + A selection is created by specifying a model, and a pair of model + indexes to a \l QItemSelection. This uses the indexes to refer to items + in the given model, and interprets them as the top-left and bottom-right + items in a block of selected items. + To apply the selection to items in a model requires the selection to be + submitted to a selection model; this can be achieved in a number of ways, + each having a different effect on the selections already present in the + selection model. + + + \section2 Selecting Items + + To demonstrate some of the principal features of selections, we construct + an instance of a custom table model with 32 items in total, and open a + table view onto its data: + + \snippet doc/src/snippets/itemselection/main.cpp 0 + + The table view's default selection model is retrieved for later use. + We do not modify any items in the model, but instead select a few + items that the view will display at the top-left of the table. To do + this, we need to retrieve the model indexes corresponding to the + top-left and bottom-right items in the region to be selected: + + \snippet doc/src/snippets/itemselection/main.cpp 1 + + To select these items in the model, and see the corresponding change + in the table view, we need to construct a selection object then apply + it to the selection model: + + \snippet doc/src/snippets/itemselection/main.cpp 2 + + The selection is applied to the selection model using a command + defined by a combination of + \l{QItemSelectionModel::SelectionFlag}{selection flags}. + In this case, the flags used cause the items recorded in the + selection object to be included in the selection model, regardless + of their previous state. The resulting selection is shown by the view. + + \img selected-items1.png + + The selection of items can be modified using various operations that + are defined by the selection flags. The selection that results from + these operations may have a complex structure, but will be represented + efficiently by the selection model. The use of different selection + flags to manipulate the selected items is described when we examine + how to update a selection. + + \section2 Reading the Selection State + + The model indexes stored in the selection model can be read using + the \l{QItemSelectionModel::selectedIndexes()}{selectedIndexes()} + function. This returns an unsorted list of model indexes that we can + iterate over as long as we know which model they are for: + + \snippet doc/src/snippets/reading-selections/window.cpp 0 + + The above code uses Qt's convenient \l{Generic Containers}{foreach + keyword} to iterate over, and modify, the items corresponding to the + indexes returned by the selection model. + + The selection model emits signals to indicate changes in the + selection. These notify other components about changes to both the + selection as a whole and the currently focused item in the item + model. We can connect the + \l{QItemSelectionModel::selectionChanged()}{selectionChanged()} + signal to a slot, and examine the items in the model that are selected or + deselected when the selection changes. The slot is called with two + \l{QItemSelection} objects: one contains a list of indexes that + correspond to newly selected items; the other contains indexes that + correspond to newly deselected items. + + In the following code, we provide a slot that receives the + \l{QItemSelectionModel::selectionChanged()}{selectionChanged()} + signal, fills in the selected items with + a string, and clears the contents of the deselected items. + + \snippet doc/src/snippets/updating-selections/window.cpp 0 + \snippet doc/src/snippets/updating-selections/window.cpp 1 + \codeline + \snippet doc/src/snippets/updating-selections/window.cpp 2 + + We can keep track of the currently focused item by connecting the + \l{QItemSelectionModel::currentChanged()}{currentChanged()} signal + to a slot that is called with two model indexes. These correspond to + the previously focused item, and the currently focused item. + + In the following code, we provide a slot that receives the + \l{QItemSelectionModel::currentChanged()}{currentChanged()} signal, + and uses the information provided to update the status bar of a + \l QMainWindow: + + \snippet doc/src/snippets/updating-selections/window.cpp 3 + + Monitoring selections made by the user is straightforward with these + signals, but we can also update the selection model directly. + + \section2 Updating a Selection + + Selection commands are provided by a combination of selection flags, + defined by \l{QItemSelectionModel::SelectionFlag}. + Each selection flag tells the selection model how to update its + internal record of selected items when either of the + \l{QItemSelection::select()}{select()} functions are called. + The most commonly used flag is the + \l{QItemSelectionModel::SelectionFlag}{Select} flag + which instructs the selection model to record the specified items as + being selected. The + \l{QItemSelectionModel::SelectionFlag}{Toggle} flag causes the + selection model to invert the state of the specified items, + selecting any deselected items given, and deselecting any currently + selected items. The \l{QItemSelectionModel::SelectionFlag}{Deselect} + flag deselects all the specified items. + + Individual items in the selection model are updated by creating a + selection of items, and applying them to the selection model. In the + following code, we apply a second selection of items to the table + model shown above, using the + \l{QItemSelectionModel::SelectionFlag}{Toggle} command to invert the + selection state of the items given. + + \snippet doc/src/snippets/itemselection/main.cpp 3 + + The results of this operation are displayed in the table view, + providing a convenient way of visualizing what we have achieved: + + \img selected-items2.png + + By default, the selection commands only operate on the individual + items specified by the model indexes. However, the flag used to + describe the selection command can be combined with additional flags + to change entire rows and columns. For example if you call + \l{QItemSelectionModel::select()}{select()} with only one index, but + with a command that is a combination of + \l{QItemSelectionModel::SelectionFlag}{Select} and + \l{QItemSelectionModel::SelectionFlag}{Rows}, the + entire row containing the item referred to will be selected. + The following code demonstrates the use of the + \l{QItemSelectionModel::SelectionFlag}{Rows} and + \l{QItemSelectionModel::SelectionFlag}{Columns} flags: + + \snippet doc/src/snippets/itemselection/main.cpp 4 + + Although only four indexes are supplied to the selection model, the + use of the + \l{QItemSelectionModel::SelectionFlag}{Columns} and + \l{QItemSelectionModel::SelectionFlag}{Rows} selection flags means + that two columns and two rows are selected. The following image shows + the result of these two selections: + + \img selected-items3.png + + The commands performed on the example model have all involved + accumulating a selection of items in the model. It is also possible + to clear the selection, or to replace the current selection with + a new one. + + To replace the current selection with a new selection, combine + the other selection flags with the + \l{QItemSelectionModel::SelectionFlag}{Current} flag. A command using + this flag instructs the selection model to replace its current collection + of model indexes with those specified in a call to + \l{QItemSelectionModel::select()}{select()}. + To clear all selections before you start adding new ones, + combine the other selection flags with the + \l{QItemSelectionModel::SelectionFlag}{Clear} flag. This + has the effect of resetting the selection model's collection of model + indexes. + + \section2 Selecting All Items in a Model + + To select all items in a model, it is necessary to create a + selection for each level of the model that covers all items in that + level. We do this by retrieving the indexes corresponding to the + top-left and bottom-right items with a given parent index: + + \snippet doc/src/snippets/reading-selections/window.cpp 2 + + A selection is constructed with these indexes and the model. The + corresponding items are then selected in the selection model: + + \snippet doc/src/snippets/reading-selections/window.cpp 3 + + This needs to be performed for all levels in the model. + For top-level items, we would define the parent index in the usual way: + + \snippet doc/src/snippets/reading-selections/window.cpp 1 + + For hierarchical models, the + \l{QAbstractItemModel::hasChildren()}{hasChildren()} function is used to + determine whether any given item is the parent of another level of + items. +*/ + +/*! + \page model-view-creating-models.html + \contentspage model-view-programming.html Contents + \previouspage Model Classes + \nextpage View Classes + + \title Creating New Models + + \tableofcontents + + \section1 Introduction + + The separation of functionality between the model/view components allows + models to be created that can take advantage of existing views. This + approach lets us present data from a variety of sources using standard + graphical user interface components, such as QListView, QTableView, and + QTreeView. + + The QAbstractItemModel class provides an interface that is flexible + enough to support data sources that arrange information in hierarchical + structures, allowing for the possibility that data will be inserted, + removed, modified, or sorted in some way. It also provides support for + drag and drop operations. + + The QAbstractListModel and QAbstractTableModel classes provide support + for interfaces to simpler non-hierarchical data structures, and are + easier to use as a starting point for simple list and table models. + + In this chapter, we create a simple read-only model to explore + the basic principles of the model/view architecture. Later in this + chapter, we will adapt this simple model so that items can be modified + by the user. + + For an example of a more complex model, see the + \l{itemviews/simpletreemodel}{Simple Tree Model} example. + + The requirements of QAbstractItemModel subclasses is described in more + detail in the \l{Model Subclassing Reference} document. + + \section1 Designing a Model + + When creating a new model for an existing data structure, it is important + to consider which type of model should be used to provide an interface + onto the data. If the data structure can be represented as a + list or table of items, you can subclass QAbstractListModel or + QAbstractTableModel since these classes provide suitable default + implementations for many functions. + + However, if the underlying data structure can only be represented by a + hierarchical tree structure, it is necessary to subclass + QAbstractItemModel. This approach is taken in the + \l{itemviews/simpletreemodel}{Simple Tree Model} example. + + In this chapter, we will implement a simple model based on a list of + strings, so the QAbstractListModel provides an ideal base class on + which to build. + + Whatever form the underlying data structure takes, it is + usually a good idea to supplement the standard QAbstractItemModel API + in specialized models with one that allows more natural access to the + underlying data structure. This makes it easier to populate the model + with data, yet still enables other general model/view components to + interact with it using the standard API. The model described below + provides a custom constructor for just this purpose. + + \section1 A Read-Only Example Model + + The model implemented here is a simple, non-hierarchical, read-only data + model based on the standard QStringListModel class. It has a \l QStringList + as its internal data source, and implements only what is needed to make a + functioning model. To make the implementation easier, we subclass + \l QAbstractListModel because it defines sensible default behavior for list + models, and it exposes a simpler interface than the \l QAbstractItemModel + class. + + When implementing a model it is important to remember that + \l QAbstractItemModel does not store any data itself, it merely + presents an interface that the views use to access the data. + For a minimal read-only model it is only necessary to implement a few + functions as there are default implementations for most of the + interface. The class declaration is as follows: + + + \snippet doc/src/snippets/stringlistmodel/model.h 0 + \snippet doc/src/snippets/stringlistmodel/model.h 1 + \codeline + \snippet doc/src/snippets/stringlistmodel/model.h 5 + + Apart from the model's constructor, we only need to implement two + functions: \l{QAbstractItemModel::rowCount()}{rowCount()} returns the + number of rows in the model and \l{QAbstractItemModel::data()}{data()} + returns an item of data corresponding to a specified model index. + + Well behaved models also implement + \l{QAbstractItemModel::headerData()}{headerData()} to give tree and + table views something to display in their headers. + + Note that this is a non-hierarchical model, so we don't have to worry + about the parent-child relationships. If our model was hierarchical, we + would also have to implement the + \l{QAbstractItemModel::index()}{index()} and + \l{QAbstractItemModel::parent()}{parent()} functions. + + The list of strings is stored internally in the \c stringList private + member variable. + + \section2 Dimensions of The Model + + We want the number of rows in the model to be the same as the number of + strings in the string list. We implement the + \l{QAbstractItemModel::rowCount()}{rowCount()} function with this in + mind: + + \snippet doc/src/snippets/stringlistmodel/model.cpp 0 + + Since the model is non-hierarchical, we can safely ignore the model index + corresponding to the parent item. By default, models derived from + QAbstractListModel only contain one column, so we do not need to + reimplement the \l{QAbstractItemModel::columnCount()}{columnCount()} + function. + + \section2 Model Headers and Data + + For items in the view, we want to return the strings in the string list. + The \l{QAbstractItemModel::data()}{data()} function is responsible for + returning the item of data that corresponds to the index argument: + + \snippet doc/src/snippets/stringlistmodel/model.cpp 1-data-read-only + + We only return a valid QVariant if the model index supplied is valid, + the row number is within the range of items in the string list, and the + requested role is one that we support. + + Some views, such as QTreeView and QTableView, are able to display headers + along with the item data. If our model is displayed in a view with headers, + we want the headers to show the row and column numbers. We can provide + information about the headers by subclassing the + \l{QAbstractItemModel::headerData()}{headerData()} function: + + \snippet doc/src/snippets/stringlistmodel/model.cpp 2 + + Again, we return a valid QVariant only if the role is one that we support. + The orientation of the header is also taken into account when deciding the + exact data to return. + + Not all views display headers with the item data, and those that do may + be configured to hide them. Nonetheless, it is recommended that you + implement the \l{QAbstractItemModel::headerData()}{headerData()} function + to provide relevant information about the data provided by the model. + + An item can have several roles, giving out different data depending on the + role specified. The items in our model only have one role, + \l{Qt::ItemDataRole}{DisplayRole}, so we return the data + for items irrespective of the role specified. + However, we could reuse the data we provide for the + \l{Qt::ItemDataRole}{DisplayRole} in + other roles, such as the + \l{Qt::ItemDataRole}{ToolTipRole} that views can use to + display information about items in a tooltip. + + \section1 An Editable Model + + The read-only model shows how simple choices could be presented to the + user but, for many applications, an editable list model is much more + useful. We can modify the read-only model to make the items editable + by changing the data() function we implemented for read-only, and + by implementing two extra functions: + \l{QAbstractItemModel::flags()}{flags()} and + \l{QAbstractItemModel::setData()}{setData()}. + The following function declarations are added to the class definition: + + \snippet doc/src/snippets/stringlistmodel/model.h 2 + \snippet doc/src/snippets/stringlistmodel/model.h 3 + + \section2 Making the Model Editable + + A delegate checks whether an item is editable before creating an + editor. The model must let the delegate know that its items are + editable. We do this by returning the correct flags for each item in + the model; in this case, we enable all items and make them both + selectable and editable: + + \snippet doc/src/snippets/stringlistmodel/model.cpp 3 + + Note that we do not have to know how the delegate performs the actual + editing process. We only have to provide a way for the delegate to set the + data in the model. This is achieved through the + \l{QAbstractItemModel::setData()}{setData()} function: + + \snippet doc/src/snippets/stringlistmodel/model.cpp 4 + \snippet doc/src/snippets/stringlistmodel/model.cpp 5 + + In this model, the item in the string list that corresponds to the + model index is replaced by the value provided. However, before we + can modify the string list, we must make sure that the index is + valid, the item is of the correct type, and that the role is + supported. By convention, we insist that the role is the + \l{Qt::ItemDataRole}{EditRole} since this is the role used by the + standard item delegate. For boolean values, however, you can use + Qt::CheckStateRole and set the Qt::ItemIsUserCheckable flag; a + checkbox will then be used for editing the value. The underlying + data in this model is the same for all roles, so this detail just + makes it easier to integrate the model with standard components. + + When the data has been set, the model must let the views know that some + data has changed. This is done by emitting the + \l{QAbstractItemModel::dataChanged()}{dataChanged()} signal. Since only + one item of data has changed, the range of items specified in the signal + is limited to just one model index. + + Also the data() function needs to be changed to add the Qt::EditRole test: + + \snippet doc/src/snippets/stringlistmodel/model.cpp 1 + + \section2 Inserting and Removing Rows + + It is possible to change the number of rows and columns in a model. In the + string list model it only makes sense to change the number of rows, so we + only reimplement the functions for inserting and removing rows. These are + declared in the class definition: + + \snippet doc/src/snippets/stringlistmodel/model.h 4 + + Since rows in this model correspond to strings in a list, the + \c insertRows() function inserts a number of empty strings into the string + list before the specified position. The number of strings inserted is + equivalent to the number of rows specified. + + The parent index is normally used to determine where in the model the + rows should be added. In this case, we only have a single top-level list + of strings, so we just insert empty strings into that list. + + \snippet doc/src/snippets/stringlistmodel/model.cpp 6 + \snippet doc/src/snippets/stringlistmodel/model.cpp 7 + + The model first calls the + \l{QAbstractItemModel::beginInsertRows()}{beginInsertRows()} function to + inform other components that the number of rows is about to change. The + function specifies the row numbers of the first and last new rows to be + inserted, and the model index for their parent item. After changing the + string list, it calls + \l{QAbstractItemModel::endInsertRows()}{endInsertRows()} to complete the + operation and inform other components that the dimensions of the model + have changed, returning true to indicate success. + + The function to remove rows from the model is also simple to write. + The rows to be removed from the model are specified by the position and + the number of rows given. + We ignore the parent index to simplify our implementation, and just + remove the corresponding items from the string list. + + \snippet doc/src/snippets/stringlistmodel/model.cpp 8 + \snippet doc/src/snippets/stringlistmodel/model.cpp 9 + + The \l{QAbstractItemModel::beginRemoveRows()}{beginRemoveRows()} function + is always called before any underlying data is removed, and specifies the + first and last rows to be removed. This allows other components to access + the data before it becomes unavailable. + After the rows have been removed, the model emits + \l{QAbstractItemModel::endRemoveRows()}{endRemoveRows()} to finish the + operation and let other components know that the dimensions of the model + have changed. + + \section1 Next Steps + + We can display the data provided by this model, or any other model, using + the \l QListView class to present the model's items in the form of a vertical + list. + For the string list model, this view also provides a default editor so that + the items can be manipulated. We examine the possibilities made available by + the standard view classes in the chapter on \l{View Classes}. + + The \l{Model Subclassing Reference} document discusses the requirements of + QAbstractItemModel subclasses in more detail, and provides a guide to the + virtual functions that must be implemented to enable various features in + different types of models. +*/ + +/*! + \page model-view-convenience.html + \contentspage model-view-programming.html Contents + \previouspage Delegate Classes + \nextpage Using Drag and Drop with Item Views + + \title Item View Convenience Classes + + \tableofcontents + + \section1 Overview + + Alongside the model/view classes, Qt 4 also includes standard widgets to + provide classic item-based container widgets. These behave in a similar + way to the item view classes in Qt 3, but have been rewritten to use the + underlying model/view framework for performance and maintainability. The + old item view classes are still available in the compatibility library + (see the \l{porting4.html}{Porting Guide} for more information). + + The item-based widgets have been given names which reflect their uses: + \c QListWidget provides a list of items, \c QTreeWidget displays a + multi-level tree structure, and \c QTableWidget provides a table of cell + items. Each class inherits the behavior of the \c QAbstractItemView + class which implements common behavior for item selection and header + management. + + \section1 List Widgets + + Single level lists of items are typically displayed using a \c QListWidget + and a number of \c{QListWidgetItem}s. A list widget is constructed in the + same way as any other widget: + + \snippet doc/src/snippets/qlistwidget-using/mainwindow.cpp 0 + + List items can be added directly to the list widget when they are + constructed: + + \snippet doc/src/snippets/qlistwidget-using/mainwindow.cpp 3 + + They can also be constructed without a parent list widget and added to + a list at some later time: + + \snippet doc/src/snippets/qlistwidget-using/mainwindow.cpp 6 + \snippet doc/src/snippets/qlistwidget-using/mainwindow.cpp 7 + + Each item in a list can display a text label and an icon. The colors + and font used to render the text can be changed to provide a customized + appearance for items. Tooltips, status tips, and "What's + This?" help are all easily configured to ensure that the list is properly + integrated into the application. + + \snippet doc/src/snippets/qlistwidget-using/mainwindow.cpp 8 + + By default, items in a list are presented in the order of their creation. + Lists of items can be sorted according to the criteria given in + \l{Qt::SortOrder} to produce a list of items that is sorted in forward or + reverse alphabetical order: + + \snippet doc/src/snippets/qlistwidget-using/mainwindow.cpp 4 + \snippet doc/src/snippets/qlistwidget-using/mainwindow.cpp 5 + + + \section1 Tree Widgets + + Trees or hierarchical lists of items are provided by the \c QTreeWidget + and \c QTreeWidgetItem classes. Each item in the tree widget can have + child items of its own, and can display a number of columns of + information. Tree widgets are created just like any other widget: + + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 0 + + Before items can be added to the tree widget, the number of columns must + be set. For example, we could define two columns, and create a header + to provide labels at the top of each column: + + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 1 + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 2 + + The easiest way to set up the labels for each section is to supply a string + list. For more sophisticated headers, you can construct a tree item, + decorate it as you wish, and use that as the tree widget's header. + + Top-level items in the tree widget are constructed with the tree widget as + their parent widget. They can be inserted in an arbitrary order, or you + can ensure that they are listed in a particular order by specifying the + previous item when constructing each item: + + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 3 + \codeline + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 4 + + Tree widgets deal with top-level items slightly differently to other + items from deeper within the tree. Items can be removed from the top + level of the tree by calling the tree widget's + \l{QTreeWidget::takeTopLevelItem()}{takeTopLevelItem()} function, but + items from lower levels are removed by calling their parent item's + \l{QTreeWidgetItem::takeChild()}{takeChild()} function. + Items are inserted in the top level of the tree with the + \l{QTreeWidget::insertTopLevelItem()}{insertTopLevelItem()} function. + At lower levels in the tree, the parent item's + \l{QTreeWidgetItem::insertChild()}{insertChild()} function is used. + + It is easy to move items around between the top level and lower levels + in the tree. We just need to check whether the items are top-level items + or not, and this information is supplied by each item's \c parent() + function. For example, we can remove the current item in the tree widget + regardless of its location: + + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 10 + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 11 + + Inserting the item somewhere else in the tree widget follows the same + pattern: + + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 8 + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 9 + + + \section1 Table Widgets + + Tables of items similar to those found in spreadsheet applications + are constructed with the \c QTableWidget and \c QTableWidgetItem. These + provide a scrolling table widget with headers and items to use within it. + + Tables can be created with a set number of rows and columns, or these + can be added to an unsized table as they are needed. + + \snippet doc/src/snippets/qtablewidget-using/mainwindow.h 0 + \snippet doc/src/snippets/qtablewidget-using/mainwindow.cpp 0 + + Items are constructed outside the table before being added to the table + at the required location: + + \snippet doc/src/snippets/qtablewidget-using/mainwindow.cpp 3 + + Horizontal and vertical headers can be added to the table by constructing + items outside the table and using them as headers: + + \snippet doc/src/snippets/qtablewidget-using/mainwindow.cpp 1 + + Note that the rows and columns in the table begin at zero. + + \section1 Common Features + + There are a number of item-based features common to each of the + convenience classes that are available through the same interfaces + in each class. We present these in the following sections with some + examples for different widgets. + Look at the list of \l{Model/View Classes} for each of the widgets + for more details about the use of each function used. + + \section2 Hidden Items + + It is sometimes useful to be able to hide items in an item view widget + rather than remove them. Items for all of the above widgets can be + hidden and later shown again. You can determine whether an item is hidden + by calling the isItemHidden() function, and items can be hidden with + \c setItemHidden(). + + Since this operation is item-based, the same function is available for + all three convenience classes. + + \section2 Selections + + The way items are selected is controlled by the widget's selection mode + (\l{QAbstractItemView::SelectionMode}). + This property controls whether the user can select one or many items and, + in many-item selections, whether the selection must be a continuous range + of items. The selection mode works in the same way for all of the + above widgets. + + \table + \row + \i \img selection-single.png + \i \bold{Single item selections:} + Where the user needs to choose a single item from a widget, the + default \c SingleSelection mode is most suitable. In this mode, the + current item and the selected item are the same. + + \row + \i \img selection-multi.png + \i \bold{Multi-item selections:} + In this mode, the user can toggle the selection state of any item in the + widget without changing the existing selection, much like the way + non-exclusive checkboxes can be toggled independently. + + \row + \i \img selection-extended.png + \i \bold{Extended selections:} + Widgets that often require many adjacent items to be selected, such + as those found in spreadsheets, require the \c ExtendedSelection mode. + In this mode, continuous ranges of items in the widget can be selected + with both the mouse and the keyboard. + Complex selections, involving many items that are not adjacent to other + selected items in the widget, can also be created if modifier keys are + used. + + If the user selects an item without using a modifier key, the existing + selection is cleared. + \endtable + + The selected items in a widget are read using the \c selectedItems() + function, providing a list of relevant items that can be iterated over. + For example, we can find the sum of all the numeric values within a + list of selected items with the following code: + + \snippet doc/src/snippets/qtablewidget-using/mainwindow.cpp 4 + + Note that for the single selection mode, the current item will be in + the selection. In the multi-selection and extended selection modes, the + current item may not lie within the selection, depending on the way the + user formed the selection. + + \section2 Searching + + It is often useful to be able to find items within an item view widget, + either as a developer or as a service to present to users. All three + item view convenience classes provide a common \c findItems() function + to make this as consistent and simple as possible. + + Items are searched for by the text that they contain according to + criteria specified by a selection of values from Qt::MatchFlags. + We can obtain a list of matching items with the \c findItems() + function: + + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 6 + \snippet doc/src/snippets/qtreewidget-using/mainwindow.cpp 7 + + The above code causes items in a tree widget to be selected if they + contain the text given in the search string. This pattern can also be + used in the list and table widgets. +*/ + +/*! + \page model-view-dnd.html + \contentspage model-view-programming.html Contents + \previouspage Item View Convenience Classes + \nextpage Proxy Models + + \title Using Drag and Drop with Item Views + + \tableofcontents + + \section1 Overview + + Qt's drag and drop infrastructure is fully supported by the model/view framework. + Items in lists, tables, and trees can be dragged within the views, and data can be + imported and exported as MIME-encoded data. + + The standard views automatically support internal drag and drop, where items are + moved around to change the order in which they are displayed. By default, drag and + drop is not enabled for these views because they are configured for the simplest, + most common uses. To allow items to be dragged around, certain properties of the + view need to be enabled, and the items themselves must also allow dragging to occur. + + The requirements for a model that only allows items to be exported from a + view, and which does not allow data to be dropped into it, are fewer than + those for a fully-enabled drag and drop model. + + See also the \l{Model Subclassing Reference} for more information about + enabling drag and drop support in new models. + + \section1 Using Convenience Views + + Each of the types of item used with QListWidget, QTableWidget, and QTreeWidget + is configured to use a different set of flags by default. For example, each + QListWidgetItem or QTreeWidgetItem is initially enabled, checkable, selectable, + and can be used as the source of a drag and drop operation; each QTableWidgetItem + can also be edited and used as the target of a drag and drop operation. + + Although all of the standard items have one or both flags set for drag and drop, + you generally need to set various properties in the view itself to take advantage + of the built-in support for drag and drop: + + \list + \o To enable item dragging, set the view's + \l{QAbstractItemView::dragEnabled}{dragEnabled} property to \c true. + \o To allow the user to drop either internal or external items within the view, + set the view's \l{QAbstractScrollArea::}{viewport()}'s + \l{QWidget::acceptDrops}{acceptDrops} property to \c true. + \o To show the user where the item currently being dragged will be placed if + dropped, set the view's \l{QAbstractItemView::showDropIndicator}{showDropIndicator} + property. This provides the user with continuously updating information about + item placement within the view. + \endlist + + For example, we can enable drag and drop in a list widget with the following lines + of code: + + \snippet doc/src/snippets/qlistwidget-dnd/mainwindow.cpp 0 + + The result is a list widget which allows the items to be copied + around within the view, and even lets the user drag items between + views containing the same type of data. In both situations, the + items are copied rather than moved. + + To enable the user to move the items around within the view, we + must set the list widget's \l {QAbstractItemView::}{dragDropMode}: + + \snippet doc/src/snippets/qlistwidget-dnd/mainwindow.cpp 1 + + \section1 Using Model/View Classes + + Setting up a view for drag and drop follows the same pattern used with the + convenience views. For example, a QListView can be set up in the same way as a + QListWidget: + + \snippet doc/src/snippets/qlistview-dnd/mainwindow.cpp 0 + + Since access to the data displayed by the view is controlled by a model, the + model used also has to provide support for drag and drop operations. The + actions supported by a model can be specified by reimplementing the + QAbstractItemModel::supportedDropActions() function. For example, copy and + move operations are enabled with the following code: + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 10 + + Although any combination of values from Qt::DropActions can be given, the + model needs to be written to support them. For example, to allow Qt::MoveAction + to be used properly with a list model, the model must provide an implementation + of QAbstractItemModel::removeRows(), either directly or by inheriting the + implementation from its base class. + + \section2 Enabling Drag and Drop for Items + + Models indicate to views which items can be dragged, and which will accept drops, + by reimplementing the QAbstractItemModel::flags() function to provide suitable + flags. + + For example, a model which provides a simple list based on QAbstractListModel + can enable drag and drop for each of the items by ensuring that the flags + returned contain the \l Qt::ItemIsDragEnabled and \l Qt::ItemIsDropEnabled + values: + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 7 + + Note that items can be dropped into the top level of the model, but dragging is + only enabled for valid items. + + In the above code, since the model is derived from QStringListModel, we + obtain a default set of flags by calling its implementation of the flags() + function. + + \section2 Encoding Exported Data + + When items of data are exported from a model in a drag and drop operation, they + are encoded into an appropriate format corresponding to one or more MIME types. + Models declare the MIME types that they can use to supply items by reimplementing + the QAbstractItemModel::mimeTypes() function, returning a list of standard MIME + types. + + For example, a model that only provides plain text would provide the following + implementation: + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 9 + + The model must also provide code to encode data in the advertised format. This + is achieved by reimplementing the QAbstractItemModel::mimeData() function to + provide a QMimeData object, just as in any other drag and drop operation. + + The following code shows how each item of data, corresponding to a given list of + indexes, is encoded as plain text and stored in a QMimeData object. + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 8 + + Since a list of model indexes is supplied to the function, this approach is general + enough to be used in both hierarchical and non-heirarchical models. + + Note that custom datatypes must be declared as \l{QMetaObject}{meta objects} + and that stream operators must be implemented for them. See the QMetaObject + class description for details. + + \section2 Inserting Dropped Data into a Model + + The way that any given model handles dropped data depends on both its type + (list, table, or tree) and the way its contents is likely to be presented to + the user. Generally, the approach taken to accommodate dropped data should + be the one that most suits the model's underlying data store. + + Different types of model tend to handle dropped data in different ways. List + and table models only provide a flat structure in which items of data are + stored. As a result, they may insert new rows (and columns) when data is + dropped on an existing item in a view, or they may overwrite the item's + contents in the model using some of the data supplied. Tree models are + often able to add child items containing new data to their underlying data + stores, and will therefore behave more predictably as far as the user + is concerned. + + Dropped data is handled by a model's reimplementation of + QAbstractItemModel::dropMimeData(). For example, a model that handles a + simple list of strings can provide an implementation that handles data + dropped onto existing items separately to data dropped into the top level + of the model (i.e., onto an invalid item). + + The model first has to make sure that the operation should be acted on, + the data supplied is in a format that can be used, and that its destination + within the model is valid: + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 0 + \snippet doc/src/snippets/qlistview-dnd/model.cpp 1 + + A simple one column string list model can indicate failure if the data + supplied is not plain text, or if the column number given for the drop + is invalid. + + The data to be inserted into the model is treated differently depending on + whether it is dropped onto an existing item or not. In this simple example, + we want to allow drops between existing items, before the first item in the + list, and after the last item. + + When a drop occurs, the model index corresponding to the parent item will + either be valid, indicating that the drop occurred on an item, or it will + be invalid, indicating that the drop occurred somewhere in the view that + corresponds to top level of the model. + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 2 + + We initially examine the row number supplied to see if we can use it + to insert items into the model, regardless of whether the parent index is + valid or not. + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 3 + + If the parent model index is valid, the drop occurred on an item. In this + simple list model, we find out the row number of the item and use that + value to insert dropped items into the top level of the model. + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 4 + + When a drop occurs elsewhere in the view, and the row number is unusable, + we append items to the top level of the model. + + In hierarchical models, when a drop occurs on an item, it would be better to + insert new items into the model as children of that item. In the simple + example shown here, the model only has one level, so this approach is not + appropriate. + + \section2 Decoding Imported Data + + Each implementation of \l{QAbstractItemModel::dropMimeData()}{dropMimeData()} must + also decode the data and insert it into the model's underlying data structure. + + For a simple string list model, the encoded items can be decoded and streamed + into a QStringList: + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 5 + + The strings can then be inserted into the underlying data store. For consistency, + this can be done through the model's own interface: + + \snippet doc/src/snippets/qlistview-dnd/model.cpp 6 + + Note that the model will typically need to provide implementations of the + QAbstractItemModel::insertRows() and QAbstractItemModel::setData() functions. + + \sa {Item Views Puzzle Example} +*/ + +/*! + \page model-view-proxy-models.html + \contentspage model-view-programming.html Contents + \previouspage Using Drag and Drop with Item Views + \nextpage Model Subclassing Reference + + \title Proxy Models + + \tableofcontents + + \section1 Overview + + In the model/view framework, items of data supplied by a single model can be shared + by any number of views, and each of these can possibly represent the same information + in completely different ways. + Custom views and delegates are effective ways to provide radically different + representations of the same data. However, applications often need to provide + conventional views onto processed versions of the same data, such as differently-sorted + views onto a list of items. + + Although it seems appropriate to perform sorting and filtering operations as internal + functions of views, this approach does not allow multiple views to share the results + of such potentially costly operations. The alternative approach, involving sorting + within the model itself, leads to the similar problem where each view has to display + items of data that are organized according to the most recent processing operation. + + To solve this problem, the model/view framework uses proxy models to manage the + information supplied between individual models and views. Proxy models are components + that behave like ordinary models from the perspective of a view, and access data from + source models on behalf of that view. The signals and slots used by the model/view + framework ensure that each view is updated appropriately no matter how many proxy models + are placed between itself and the source model. + + \section1 Using Proxy Models + + Proxy models can be inserted between an existing model and any number of views. + Qt is supplied with a standard proxy model, QSortFilterProxyModel, that is usually + instantiated and used directly, but can also be subclassed to provide custom filtering + and sorting behavior. The QSortFilterProxyModel class can be used in the following way: + + \snippet doc/src/snippets/qsortfilterproxymodel/main.cpp 0 + \codeline + \snippet doc/src/snippets/qsortfilterproxymodel/main.cpp 1 + + Since proxy models are inherit from QAbstractItemModel, they can be connected to + any kind of view, and can be shared between views. They can also be used to + process the information obtained from other proxy models in a pipeline arrangement. + + The QSortFilterProxyModel class is designed to be instantiated and used directly + in applications. More specialized proxy models can be created by subclassing this + classes and implementing the required comparison operations. + + \section1 Customizing Proxy Models + + Generally, the type of processing used in a proxy model involves mapping each item of + data from its original location in the source model to either a different location in + the proxy model. In some models, some items may have no corresponding location in the + proxy model; these models are \e filtering proxy models. Views access items using + model indexes provided by the proxy model, and these contain no information about the + source model or the locations of the original items in that model. + + QSortFilterProxyModel enables data from a source model to be filtered before + being supplied to views, and also allows the contents of a source model to + be supplied to views as pre-sorted data. + + \section2 Custom Filtering Models + + The QSortFilterProxyModel class provides a filtering model that is fairly versatile, + and which can be used in a variety of common situations. For advanced users, + QSortFilterProxyModel can be subclassed, providing a mechanism that enables custom + filters to be implemented. + + Subclasses of QSortFilterProxyModel can reimplement two virtual functions that are + called whenever a model index from the proxy model is requested or used: + + \list + \o \l{QSortFilterProxyModel::filterAcceptsColumn()}{filterAcceptsColumn()} is used to + filter specific columns from part of the source model. + \o \l{QSortFilterProxyModel::filterAcceptsRow()}{filterAcceptsRow()} is used to filter + specific rows from part of the source model. + \endlist + + The default implementations of the above functions in QSortFilterProxyModel + return true to ensure that all items are passed through to views; reimplementations + of these functions should return false to filter out individual rows and columns. + + \section2 Custom Sorting Models + + QSortFilterProxyModel instances use Qt's built-in qStableSort() function to set up + mappings between items in the source model and those in the proxy model, allowing a + sorted hierarchy of items to be exposed to views without modifying the structure of the + source model. To provide custom sorting behavior, reimplement the + \l{QSortFilterProxyModel::lessThan()}{lessThan()} function to perform custom + comparisons. +*/ + +/*! + \page model-view-model-subclassing.html + \contentspage model-view-programming.html Contents + \previouspage Proxy Models + + \title Model Subclassing Reference + + \tableofcontents + + \section1 Introduction + + Model subclasses need to provide implementations of many of the virtual functions + defined in the QAbstractItemModel base class. The number of these functions that need + to be implemented depends on the type of model - whether it supplies views with + a simple list, a table, or a complex hierarchy of items. Models that inherit from + QAbstractListModel and QAbstractTableModel can take advantage of the default + implementations of functions provided by those classes. Models that expose items + of data in tree-like structures must provide implementations for many of the + virtual functions in QAbstractItemModel. + + The functions that need to be implemented in a model subclass can be divided into three + groups: + + \list + \o \bold{Item data handling:} All models need to implement functions to enable views and + delegates to query the dimensions of the model, examine items, and retrieve data. + \o \bold{Navigation and index creation:} Hierarchical models need to provide functions + that views can call to navigate the tree-like structures they expose, and obtain + model indexes for items. + \o \bold{Drag and drop support and MIME type handling:} Models inherit functions that + control the way that internal and external drag and drop operations are performed. + These functions allow items of data to be described in terms of MIME types that + other components and applications can understand. + \endlist + + For more information, see the \l + {"Item View Classes" Chapter of C++ GUI Programming with Qt 4}. + + \section1 Item Data Handling + + Models can provide varying levels of access to the data they provide: They can be + simple read-only components, some models may support resizing operations, and + others may allow items to be edited. + + \section2 Read-Only Access + + To provide read-only access to data provided by a model, the following functions + \e{must} be implemented in the model's subclass: + + \table 90% + \row \o \l{QAbstractItemModel::flags()}{flags()} + \o Used by other components to obtain information about each item provided by + the model. In many models, the combination of flags should include + Qt::ItemIsEnabled and Qt::ItemIsSelectable. + \row \o \l{QAbstractItemModel::data()}{data()} + \o Used to supply item data to views and delegates. Generally, models only + need to supply data for Qt::DisplayRole and any application-specific user + roles, but it is also good practice to provide data for Qt::ToolTipRole, + Qt::AccessibleTextRole, and Qt::AccessibleDescriptionRole. + See the Qt::ItemDataRole enum documentation for information about the types + associated with each role. + \row \o \l{QAbstractItemModel::headerData()}{headerData()} + \o Provides views with information to show in their headers. The information is + only retrieved by views that can display header information. + \row \o \l{QAbstractItemModel::rowCount()}{rowCount()} + \o Provides the number of rows of data exposed by the model. + \endtable + + These four functions must be implemented in all types of model, including list models + (QAbstractListModel subclasses) and table models (QAbstractTableModel subclasses). + + Additionally, the following functions \e{must} be implemented in direct subclasses + of QAbstractTableModel and QAbstractItemModel: + + \table 90% + \row \o \l{QAbstractItemModel::columnCount()}{columnCount()} + \o Provides the number of columns of data exposed by the model. List models do not + provide this function because it is already implemented in QAbstractListModel. + \endtable + + \section2 Editable Items + + Editable models allow items of data to be modified, and may also provide + functions to allow rows and columns to be inserted and removed. To enable + editing, the following functions must be implemented correctly: + + \table 90% + \row \o \l{QAbstractItemModel::flags()}{flags()} + \o Must return an appropriate combination of flags for each item. In particular, + the value returned by this function must include \l{Qt::ItemIsEditable} in + addition to the values applied to items in a read-only model. + \row \o \l{QAbstractItemModel::setData()}{setData()} + \o Used to modify the item of data associated with a specified model index. + To be able to accept user input, provided by user interface elements, this + function must handle data associated with Qt::EditRole. + The implementation may also accept data associated with many different kinds + of roles specified by Qt::ItemDataRole. After changing the item of data, + models must emit the \l{QAbstractItemModel::dataChanged()}{dataChanged()} + signal to inform other components of the change. + \row \o \l{QAbstractItemModel::setHeaderData()}{setHeaderData()} + \o Used to modify horizontal and vertical header information. After changing + the item of data, models must emit the + \l{QAbstractItemModel::headerDataChanged()}{headerDataChanged()} + signal to inform other components of the change. + \endtable + + \section2 Resizable Models + + All types of model can support the insertion and removal of rows. Table models + and hierarchical models can also support the insertion and removal of columns. + It is important to notify other components about changes to the model's dimensions + both \e before and \e after they occur. As a result, the following functions + can be implemented to allow the model to be resized, but implementations must + ensure that the appropriate functions are called to notify attached views and + delegates: + + \table 90% + \row \o \l{QAbstractItemModel::insertRows()}{insertRows()} + \o Used to add new rows and items of data to all types of model. + Implementations must call + \l{QAbstractItemModel::beginInsertRows()}{beginInsertRows()} \e before + inserting new rows into any underlying data structures, and call + \l{QAbstractItemModel::endInsertRows()}{endInsertRows()} + \e{immediately afterwards}. + \row \o \l{QAbstractItemModel::removeRows()}{removeRows()} + \o Used to remove rows and the items of data they contain from all types of model. + Implementations must call + \l{QAbstractItemModel::beginRemoveRows()}{beginRemoveRows()} + \e before inserting new columns into any underlying data structures, and call + \l{QAbstractItemModel::endRemoveRows()}{endRemoveRows()} + \e{immediately afterwards}. + \row \o \l{QAbstractItemModel::insertColumns()}{insertColumns()} + \o Used to add new columns and items of data to table models and hierarchical models. + Implementations must call + \l{QAbstractItemModel::beginInsertColumns()}{beginInsertColumns()} \e before + rows are removed from any underlying data structures, and call + \l{QAbstractItemModel::endInsertColumns()}{endInsertColumns()} + \e{immediately afterwards}. + \row \o \l{QAbstractItemModel::removeColumns()}{removeColumns()} + \o Used to remove columns and the items of data they contain from table models and + hierarchical models. + Implementations must call + \l{QAbstractItemModel::beginRemoveColumns()}{beginRemoveColumns()} + \e before columns are removed from any underlying data structures, and call + \l{QAbstractItemModel::endRemoveColumns()}{endRemoveColumns()} + \e{immediately afterwards}. + \endtable + + Generally, these functions should return true if the operation was successful. + However, there may be cases where the operation only partly succeeded; for example, + if less than the specified number of rows could be inserted. In such cases, the + model should return false to indicate failure to enable any attached components to + handle the situation. + + The signals emitted by the functions called in implementations of the resizing + API give attached components the chance to take action before any data becomes + unavailable. The encapsulation of insert and remove operations with begin and end + functions also enable the model to manage + \l{QPersistentModelIndex}{persistent model indexes} correctly. + + Normally, the begin and end functions are capable of informing other components + about changes to the model's underlying structure. For more complex changes to the + model's structure, perhaps involving internal reorganization or sorting of data, + it is necessary to emit the \l{QAbstractItemModel::layoutChanged()}{layoutChanged()} + signal to cause any attached views to be updated. + + \section2 Lazy Population of Model Data + + Lazy population of model data effectively allows requests for information + about the model to be deferred until it is actually needed by views. + + Some models need to obtain data from remote sources, or must perform + time-consuming operations to obtain information about the way the + data is organized. Since views generally request as much information + as possible in order to accurately display model data, it can be useful + to restrict the amount of information returned to them to reduce + unnecessary follow-up requests for data. + + In hierarchical models where finding the number of children of a given + item is an expensive operation, it is useful to ensure that the model's + \l{QAbstractItemModel::}{rowCount()} implementation is only called when + necessary. In such cases, the \l{QAbstractItemModel::}{hasChildren()} + function can be reimplemented to provide an inexpensive way for views to + check for the presence of children and, in the case of QTreeView, draw + the appropriate decoration for their parent item. + + Whether the reimplementation of \l{QAbstractItemModel::}{hasChildren()} + returns \c true or \c false, it may not be necessary for the view to call + \l{QAbstractItemModel::}{rowCount()} to find out how many children are + present. For example, QTreeView does not need to know how many children + there are if the parent item has not been expanded to show them. + + If it is known that many items will have children, reimplementing + \l{QAbstractItemModel::}{hasChildren()} to unconditionally return \c true + is sometimes a useful approach to take. This ensures that each item can + be later examined for children while making initial population of model + data as fast as possible. The only disadvantage is that items without + children may be displayed incorrectly in some views until the user + attempts to view the non-existent child items. + + + \section1 Navigation and Model Index Creation + + Hierarchical models need to provide functions that views can call to navigate the + tree-like structures they expose, and obtain model indexes for items. + + \section2 Parents and Children + + Since the structure exposed to views is determined by the underlying data + structure, it is up to each model subclass to create its own model indexes + by providing implementations of the following functions: + + \table 90% + \row \o \l{QAbstractItemModel::index()}{index()} + \o Given a model index for a parent item, this function allows views and delegates + to access children of that item. If no valid child item - corresponding to the + specified row, column, and parent model index, can be found, the function + must return QModelIndex(), which is an invalid model index. + \row \o \l{QAbstractItemModel::parent()}{parent()} + \o Provides a model index corresponding to the parent of any given child item. + If the model index specified corresponds to a top-level item in the model, or if + there is no valid parent item in the model, the function must return + an invalid model index, created with the empty QModelIndex() constructor. + \endtable + + Both functions above use the \l{QAbstractItemModel::createIndex()}{createIndex()} + factory function to generate indexes for other components to use. It is normal for + models to supply some unique identifier to this function to ensure that + the model index can be re-associated with its corresponding item later on. + + \section1 Drag and Drop Support and MIME Type Handling + + The model/view classes support drag and drop operations, providing default behavior + that is sufficient for many applications. However, it is also possible to customize + the way items are encoded during drag and drop operations, whether they are copied + or moved by default, and how they are inserted into existing models. + + Additionally, the convenience view classes implement specialized behavior that + should closely follow that expected by existing developers. + The \l{#Convenience Views}{Convenience Views} section provides an overview of this + behavior. + + \section2 MIME Data + + By default, the built-in models and views use an internal MIME type + (\c{application/x-qabstractitemmodeldatalist}) to pass around information about + model indexes. This specifies data for a list of items, containing the row and + column numbers of each item, and information about the roles that each item + supports. + + Data encoded using this MIME type can be obtained by calling + QAbstractItemModel::mimeData() with a QModelIndexList containing the items to + be serialized. + \omit + The following types are used to store information about + each item as it is streamed into a QByteArray and stored in a QMimeData object: + + \table 90% + \header \o Description \o Type + \row \o Row \o int + \row \o Column \o int + \row \o Data for each role \o QMap<int, QVariant> + \endtable + + This information can be retrieved for use in non-model classes by calling + QMimeData::data() with the \c{application/x-qabstractitemmodeldatalist} MIME + type and streaming out the items one by one. + \endomit + + When implementing drag and drop support in a custom model, it is possible to + export items of data in specialized formats by reimplementing the following + function: + + \table 90% + \row \o \l{QAbstractItemModel::mimeData()}{mimeData()} + \o This function can be reimplemented to return data in formats other + than the default \c{application/x-qabstractitemmodeldatalist} internal + MIME type. + + Subclasses can obtain the default QMimeData object from the base class + and add data to it in additional formats. + \endtable + + For many models, it is useful to provide the contents of items in common format + represented by MIME types such as \c{text/plain} and \c{image/png}. Note that + images, colors and HTML documents can easily be added to a QMimeData object with + the QMimeData::setImageData(), QMimeData::setColorData(), and + QMimeData::setHtml() functions. + + \section2 Accepting Dropped Data + + When a drag and drop operation is performed over a view, the underlying model is + queried to determine which types of operation it supports and the MIME types + it can accept. This information is provided by the + QAbstractItemModel::supportedDropActions() and QAbstractItemModel::mimeTypes() + functions. Models that do not override the implementations provided by + QAbstractItemModel support copy operations and the default internal MIME type + for items. + + When serialized item data is dropped onto a view, the data is inserted into + the current model using its implementation of QAbstractItemModel::dropMimeData(). + The default implementation of this function will never overwrite any data in the + model; instead, it tries to insert the items of data either as siblings of an + item, or as children of that item. + + To take advantage of QAbstractItemModel's default implementation for the built-in + MIME type, new models must provide reimplementations of the following functions: + + \table 90% + \row \o \l{QAbstractItemModel::insertRows()}{insertRows()} + \o {1, 2} These functions enable the model to automatically insert new data using + the existing implementation provided by QAbstractItemModel::dropMimeData(). + \row \o \l{QAbstractItemModel::insertColumns()}{insertColumns()} + \row \o \l{QAbstractItemModel::setData()}{setData()} + \o Allows the new rows and columns to be populated with items. + \row \o \l{QAbstractItemModel::setItemData()}{setItemData()} + \o This function provides more efficient support for populating new items. + \endtable + + To accept other forms of data, these functions must be reimplemented: + + \table 90% + \row \o \l{QAbstractItemModel::supportedDropActions()}{supportedDropActions()} + \o Used to return a combination of \l{Qt::DropActions}{drop actions}, + indicating the types of drag and drop operations that the model accepts. + \row \o \l{QAbstractItemModel::mimeTypes()}{mimeTypes()} + \o Used to return a list of MIME types that can be decoded and handled by + the model. Generally, the MIME types that are supported for input into + the model are the same as those that it can use when encoding data for + use by external components. + \row \o \l{QAbstractItemModel::dropMimeData()}{dropMimeData()} + \o Performs the actual decoding of the data transferred by drag and drop + operations, determines where in the model it will be set, and inserts + new rows and columns where necessary. How this function is implemented + in subclasses depends on the requirements of the data exposed by each + model. + \endtable + + If the implementation of the \l{QAbstractItemModel::dropMimeData()}{dropMimeData()} + function changes the dimensions of a model by inserting or removing rows or + columns, or if items of data are modified, care must be taken to ensure that + all relevant signals are emitted. It can be useful to simply call + reimplementations of other functions in the subclass, such as + \l{QAbstractItemModel::setData()}{setData()}, + \l{QAbstractItemModel::insertRows()}{insertRows()}, and + \l{QAbstractItemModel::insertColumns()}{insertColumns()}, to ensure that the + model behaves consistently. + + In order to ensure drag operations work properly, it is important to + reimplement the following functions that remove data from the model: + + \list + \o \l{QAbstractItemModel::}{removeRows()} + \o \l{QAbstractItemModel::}{removeRow()} + \o \l{QAbstractItemModel::}{removeColumns()} + \o \l{QAbstractItemModel::}{removeColumn()} + \endlist + + For more information about drag and drop with item views, refer to + \l{Using Drag and Drop with Item Views}. + + \section2 Convenience Views + + The convenience views (QListWidget, QTableWidget, and QTreeWidget) override + the default drag and drop functionality to provide less flexible, but more + natural behavior that is appropriate for many applications. For example, + since it is more common to drop data into cells in a QTableWidget, replacing + the existing contents with the data being transferred, the underlying model + will set the data of the target items rather than insert new rows and columns + into the model. For more information on drag and drop in convenience views, + you can see \l{Using Drag and Drop with Item Views}. + + \section1 Performance Optimization for Large Amounts of Data + + The \l{QAbstractItemModel::}{canFetchMore()} function checks if the parent + has more data available and returns true or false accordingly. The + \l{QAbstractItemModel::}{fetchMore()} function fetches data based on the + parent specified. Both these functions can be combined, for example, in a + database query involving incremental data to populate a QAbstractItemModel. + We reimplement \l{QAbstractItemModel::}{canFetchMore()} to indicate if there + is more data to be fetched and \l{QAbstractItemModel::}{fetchMore()} to + populate the model as required. + + Another example would be dynamically populated tree models, where we + reimplement \l{QAbstractItemModel::}{fetchMore()} when a branch in the tree + model is expanded. + + If your reimplementation of \l{QAbstractItemModel::}{fetchMore()} adds rows + to the model, you need to call \l{QAbstractItemModel::}{beginInsertRows()} + and \l{QAbstractItemModel::}{endInsertRows()}. Also, both + \l{QAbstractItemModel::}{canFetchMore()} and \l{QAbstractItemModel::} + {fetchMore()} must be reimplemented as their default implementation returns + false and does nothing. +*/ |