summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorPaul Olav Tvete <paul.tvete@nokia.com>2009-10-14 14:51:20 (GMT)
committerPaul Olav Tvete <paul.tvete@nokia.com>2009-10-14 14:51:20 (GMT)
commit1c313a529ff0893c43c3ccaabe92c4e015acf891 (patch)
tree4e9b735c04e6579763474dd844eef13a8985ac64 /doc
parent7750f3821c7cd526c33bfa09378378da3980a2e6 (diff)
parent81bc22dbd71e2dd0e25156e753afc6d94d808de9 (diff)
downloadQt-1c313a529ff0893c43c3ccaabe92c4e015acf891.zip
Qt-1c313a529ff0893c43c3ccaabe92c4e015acf891.tar.gz
Qt-1c313a529ff0893c43c3ccaabe92c4e015acf891.tar.bz2
Merge branch '4.6' into lighthouse
Conflicts: src/gui/kernel/qapplication.cpp src/gui/kernel/qwidget.cpp
Diffstat (limited to 'doc')
-rw-r--r--doc/src/demos/mediaplayer.qdoc2
-rw-r--r--doc/src/development/designer-manual.qdoc3
-rw-r--r--doc/src/development/qmake-manual.qdoc105
-rw-r--r--doc/src/diagrams/programs/standard_views.py82
-rw-r--r--doc/src/examples/ahigl.qdoc572
-rw-r--r--doc/src/examples/ftp.qdoc34
-rw-r--r--doc/src/examples/musicplayerexample.qdoc38
-rw-r--r--doc/src/frameworks-technologies/gestures.qdoc2
-rw-r--r--doc/src/frameworks-technologies/model-view-programming.qdoc51
-rw-r--r--doc/src/getting-started/demos.qdoc2
-rw-r--r--doc/src/getting-started/examples.qdoc11
-rw-r--r--doc/src/getting-started/installation.qdoc62
-rw-r--r--doc/src/getting-started/known-issues.qdoc144
-rw-r--r--doc/src/howtos/appicon.qdoc4
-rw-r--r--doc/src/howtos/exceptionsafety.qdoc (renamed from doc/src/exceptionsafety.qdoc)10
-rw-r--r--doc/src/images/gradient.pngbin0 -> 222 bytes
-rw-r--r--doc/src/images/graphicseffect-bloom.pngbin0 -> 79982 bytes
-rw-r--r--doc/src/images/graphicseffect-effects.pngbin395669 -> 486123 bytes
-rw-r--r--doc/src/images/graphicseffect-plain.pngbin0 -> 68763 bytes
-rw-r--r--doc/src/images/pbuffers-example.pngbin203754 -> 192554 bytes
-rw-r--r--doc/src/images/qt-colors.pngbin3711 -> 11701 bytes
-rw-r--r--doc/src/images/qt-embedded-architecture.pngbin22388 -> 8511 bytes
-rw-r--r--doc/src/images/shareddirmodel.pngbin33024 -> 45891 bytes
-rw-r--r--doc/src/images/standard-views.pngbin78278 -> 44495 bytes
-rw-r--r--doc/src/images/xml-schema.pngbin0 -> 48931 bytes
-rw-r--r--doc/src/index.qdoc12
-rw-r--r--doc/src/internationalization/i18n.qdoc3
-rw-r--r--doc/src/platforms/compiler-notes.qdoc14
-rw-r--r--doc/src/platforms/emb-opengl.qdoc247
-rw-r--r--doc/src/platforms/platform-notes.qdoc4
-rw-r--r--doc/src/platforms/qt-embedded.qdoc7
-rw-r--r--doc/src/platforms/s60-introduction.qdoc (renamed from doc/src/s60-introduction.qdoc)45
-rw-r--r--doc/src/platforms/supported-platforms.qdoc15
-rw-r--r--doc/src/platforms/symbian-exceptionsafety.qdoc (renamed from doc/src/symbian-exceptionsafety.qdoc)0
-rw-r--r--doc/src/porting/qt4-interview.qdoc8
-rw-r--r--doc/src/qt-resources.qdoc (renamed from doc/src/snippets/code/doc_src_examples_ahigl.qdoc)13
-rw-r--r--doc/src/qt-webpages.qdoc2
-rw-r--r--doc/src/qt4-intro.qdoc128
-rw-r--r--doc/src/snippets/colors/colors.pro2
-rw-r--r--doc/src/snippets/colors/main.cpp52
-rw-r--r--doc/src/snippets/colors/window.cpp131
-rw-r--r--doc/src/snippets/colors/window.h53
-rw-r--r--doc/src/snippets/gestures/qgesture.cpp32
-rw-r--r--doc/src/snippets/shareddirmodel/main.cpp5
-rw-r--r--doc/src/snippets/simplemodel-use/main.cpp2
-rw-r--r--doc/src/snippets/statemachine/main2.cpp4
46 files changed, 864 insertions, 1037 deletions
diff --git a/doc/src/demos/mediaplayer.qdoc b/doc/src/demos/mediaplayer.qdoc
index 9e6b3f9..17ae79b 100644
--- a/doc/src/demos/mediaplayer.qdoc
+++ b/doc/src/demos/mediaplayer.qdoc
@@ -40,7 +40,7 @@
****************************************************************************/
/*!
- \example demos/mediaplayer
+ \example demos/qmediaplayer
\title Media Player
The Media Player demonstration shows how \l{Phonon Module}{Phonon}
diff --git a/doc/src/development/designer-manual.qdoc b/doc/src/development/designer-manual.qdoc
index 4f4db85..bfd8066 100644
--- a/doc/src/development/designer-manual.qdoc
+++ b/doc/src/development/designer-manual.qdoc
@@ -61,9 +61,6 @@
\l{Getting To Know Qt Designer} document. For a quick tutorial on how to
use \QD, refer to \l{A Quick Start to Qt Designer}.
- Qt Designer 4.6 boasts a long list of improvements. For a detailed list of
- what is new, refer \l{What's New in Qt Designer 4.6}.
-
\image designer-multiple-screenshot.png
For more information on using \QD, you can take a look at the following
diff --git a/doc/src/development/qmake-manual.qdoc b/doc/src/development/qmake-manual.qdoc
index f2cae5b..d040d3d 100644
--- a/doc/src/development/qmake-manual.qdoc
+++ b/doc/src/development/qmake-manual.qdoc
@@ -920,7 +920,7 @@
{deployment guide for Windows}.
- \section1 S60
+ \section1 Symbian platform
Features specific to this platform include handling of static data,
capabilities, stack and heap size, compiler specific options, and unique
@@ -940,7 +940,7 @@
\section2 Stack and heap size
- Symbian uses predefined sizes for stacks and heaps. If an
+ The Symbian platform uses predefined sizes for stacks and heaps. If an
application exceeds either limit, it may crash or fail to complete its
task. Crashes that seem to have no reason can often be traced back to
insufficient stack and/or heap sizes.
@@ -952,7 +952,7 @@
\snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 130
- The default values depend on the version of the S60 SDK you're using.
+ The default values depend on the version of the Symbian SDK you're using.
\section2 Compiler specific options
@@ -983,8 +983,7 @@
an official UID, please contact Nokia. Both \c SID and \c VID default to empty values.
For more information about unique identifiers and their meaning for
- Symbian applications, please refer to the
- \l{http://www.symbian.com/developer/techlib/v9.2docs/doc_source/ToolsAndUtilities/BuildTools/UsingUids.guide.html}{respective S60 SDK documentation}.
+ Symbian applications, please refer to the Symbian SDK documentation.
\section2 Capabilities
@@ -1000,8 +999,7 @@
\snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 134
- For more information about capabilities, please refer to the
- \l{http://www.symbian.com/developer/techlib/v9.2docs/doc_source/guide/platsecsdk/index.html}{respective S60 SDK documentation}.
+ For more information about capabilities, please refer to the Symbian SDK documentation.
*/
/*!
@@ -1095,7 +1093,7 @@
\target BLD_INF_RULES
\section1 BLD_INF_RULES
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Generic \c bld.inf file content can be specified with \c BLD_INF_RULES variables.
The section of \c bld.inf file where each rule goes is appended to
@@ -1288,7 +1286,7 @@
The build process for bundles is also influenced by
the contents of the \l{#QMAKE_BUNDLE_DATA}{QMAKE_BUNDLE_DATA} variable.
- These options only have an effect on Symbian:
+ These options only have an effect on the Symbian platform:
\table 95%
\header \o Option \o Description
@@ -1345,7 +1343,7 @@
\target DEPLOYMENT
\section1 DEPLOYMENT
- \e {This is only used on Windows CE and Symbian.}
+ \e {This is only used on Windows CE and the Symbian platform.}
Specifies which additional files will be deployed. Deployment means the
transfer of files from the development system to the target device or
@@ -1363,8 +1361,8 @@
The default deployment target path for Windows CE is
\c{%CSIDL_PROGRAM_FILES%\target}, which usually gets expanded to
- \c{\Program Files\target}. For Symbian, the default target is the application
- private directory on the drive it is installed to.
+ \c{\Program Files\target}. For the Symbian platform, the default target
+is the application private directory on the drive it is installed to.
It is also possible to specify multiple \c sources to be deployed on
target \c paths. In addition, different variables can be used for
@@ -1375,10 +1373,10 @@
\snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 29
\note In Windows CE all linked Qt libraries will be deployed to the path
- specified by \c{myFiles.path}. In Symbian all libraries and executables
+ specified by \c{myFiles.path}. On Symbian platform all libraries and executables
will always be deployed to the \\sys\\bin of the installation drive.
- Since the Symbian build system automatically moves binaries to certain
+ Since the Symbian platform build system automatically moves binaries to certain
directories under the epoc32 directory, custom plugins, executables or
dynamically loadable libraries need special handling. When deploying
extra executables or dynamically loadable libraries, the target path
@@ -1393,13 +1391,13 @@
\snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 128
- In Symbian, generic PKG file content can also be specified with this
+ On the Symbian platform, generic PKG file content can also be specified with this
variable. You can use either \c pkg_prerules or \c pkg_postrules to
pass raw data to PKG file. The strings in \c pkg_prerules are added before
package-body and \c pkg_postrules after. The strings defined in
\c pkg_postrules or \c pkg_prerules are not parsed by qmake, so they
should be in a format understood by Symbian package generation tools.
- Please consult Symbian documentation for correct syntax.
+ Please consult the Symbian platform documentation for correct syntax.
For example, to deploy DLL and add a new dependency:
@@ -1424,7 +1422,7 @@
override languages statement, you must override also package-header
statement and all other statements which are language specific.
- In Symbian, the \c default_deployment item specifies
+ On the Symbian platform, the \c default_deployment item specifies
default platform dependencies. It can be overwritten if a more
restrictive set is needed - e.g. if a specific
device is required to run the application.
@@ -1436,7 +1434,7 @@
\target DEPLOYMENT_PLUGIN
\section1 DEPLOYMENT_PLUGIN
- \e {This is only used on Windows CE and Symbian.}
+ \e {This is only used on Windows CE and the Symbian platform.}
This variable specifies the Qt plugins that will be deployed. All plugins
available in Qt can be explicitly deployed to the device. See
@@ -1446,9 +1444,9 @@
If the application depends on plugins, these plugins have to be specified
manually.
- \note In Symbian, all plugins supported by this variable will be deployed
- by default with Qt libraries, so generally using this variable is not
- needed.
+ \note On the Symbian platform, all plugins supported by this variable
+will be deployed by default with Qt libraries, so generally using this
+variable is not needed.
For example:
@@ -1556,7 +1554,7 @@
\target ICON
\section1 ICON
- This variable is used only in MAC and S60 to set the application icon.
+ This variable is used only in MAC and the Symbian platform to set the application icon.
Please see \l{Setting the Application Icon}{the application icon documentation}
for more information.
@@ -1623,10 +1621,10 @@
This variable contains a list of libraries to be linked into the project.
You can use the Unix \c -l (library) and -L (library path) flags and qmake
- will do the correct thing with these libraries on Windows and Symbian
- (namely this means passing the full path of the library to the linker). The
- only limitation to this is the library must exist, for qmake to find which
- directory a \c -l lib lives in.
+ will do the correct thing with these libraries on Windows and the
+ Symbian platform (namely this means passing the full path of the library to
+ the linker). The only limitation to this is the library must exist, for
+ qmake to find which directory a \c -l lib lives in.
For example:
@@ -1647,7 +1645,8 @@
explicitly specify the library to be used by including the \c{.lib}
file name suffix.
- \bold{Note:} On S60, the build system makes a distinction between shared and
+ \bold{Note:} On the Symbian platform, the build system makes a
+distinction between shared and
static libraries. In most cases, qmake will figure out which library you
are refering to, but in some cases you may have to specify it explicitly to
get the expected behavior. This typically happens if you are building a
@@ -1693,7 +1692,7 @@
\target MMP_RULES
\section1 MMP_RULES
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Generic MMP file content can be specified with this variable.
@@ -2013,8 +2012,9 @@
the \c QMAKE_CXXFLAGS_DEBUG and \c QMAKE_CXXFLAGS_RELEASE variables,
respectively.
- \bold{Note:} On S60, this variable can be used to pass architecture specific
- options to each compiler in the Symbian build system. For example:
+ \bold{Note:} On the Symbian platform, this variable can be used to pass
+architecture specific options to each compiler in the Symbian build system.
+For example:
\snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 131
@@ -2812,7 +2812,7 @@
\target RSS_RULES
\section1 RSS_RULES
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Generic RSS file content can be specified with this variable. The syntax is
similar to \c MMP_RULES and \c BLD_INF_RULES.
@@ -2832,10 +2832,12 @@
\snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 145
- This example will install the application to MyFolder in S60 application
- shell. In addition it will make the application to be launched in background.
+ This example will install the application to MyFolder in the Symbian
+ platform application shell. In addition it will make the application to
+ be launched in background.
- For detailed list of possible RSS statements, please refer to Symbian OS help.
+ For detailed list of possible RSS statements, please refer to the
+ Symbian platform help.
\note You should not use \c RSS_RULES variable to set the following RSS statements:
@@ -2848,7 +2850,7 @@
\target S60_VERSION
\section1 S60_VERSION
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Contains the version number of the underlying S60 SDK; e.g. "5.0".
@@ -2918,15 +2920,15 @@
\target TARGET.CAPABILITY
\section1 TARGET.CAPABILITY
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies which platform capabilities the application should have. For more
- information, please refer to the S60 SDK documentation.
+ information, please refer to the Symbian SDK documentation.
\target TARGET.EPOCALLOWDLLDATA
\section1 TARGET.EPOCALLOWDLLDATA
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies whether static data should be allowed in the application. Symbian
disallows this by default in order to save memory. To use it, set this to 1.
@@ -2934,7 +2936,7 @@
\target TARGET.EPOCHEAPSIZE
\section1 TARGET.EPOCHEAPSIZE
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies the minimum and maximum heap size of the application. The program
will refuse to run if the minimum size is not available when it starts. For
@@ -2945,7 +2947,7 @@
\target TARGET.EPOCSTACKSIZE
\section1 TARGET.EPOCSTACKSIZE
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies the maximum stack size of the application. For example:
@@ -2954,38 +2956,38 @@
\target TARGET.SID
\section1 TARGET.SID
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies which secure identifier to use for the target application or
- library. For more information, see the S60 SDK documentation.
+ library. For more information, see the Symbian SDK documentation.
\target TARGET.UID2
\section1 TARGET.UID2
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies which unique identifier 2 to use for the target application or
library. If this variable is not specified, it defaults to the same value
- as TARGET.UID3. For more information, see the S60 SDK documentation.
+ as TARGET.UID3. For more information, see the Symbian SDK documentation.
\target TARGET.UID3
\section1 TARGET.UID3
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies which unique identifier 3 to use for the target application or
library. If this variable is not specified, a UID3 suitable for development
and debugging will be generated automatically. However, applications being
released should always define this variable. For more information, see the
- S60 SDK documentation.
+ Symbian SDK documentation.
\target TARGET.VID
\section1 TARGET.VID
- \e {This is only used on Symbian.}
+ \e {This is only used on the Symbian platform.}
Specifies which vendor identifier to use for the target application or
- library. For more information, see the S60 SDK documentation.
+ library. For more information, see the Symbian SDK documentation.
\section1 TARGET_EXT
@@ -3862,9 +3864,10 @@
\o Indicates that the output should not be added to the list of objects to be linked in.
\endtable
- \note Symbian specific: Generating objects to be linked in is not supported in Symbian,
- so either the \c CONFIG option \c no_link or variable \c variable_out
- should always be defined for extra compilers.
+ \note Symbian platform specific: Generating objects to be linked in is
+ not supported on the Symbian platform, so either the \c CONFIG option
+ \c no_link or variable \c variable_out should always be defined for
+ extra compilers.
*/
diff --git a/doc/src/diagrams/programs/standard_views.py b/doc/src/diagrams/programs/standard_views.py
new file mode 100644
index 0000000..5581387
--- /dev/null
+++ b/doc/src/diagrams/programs/standard_views.py
@@ -0,0 +1,82 @@
+#!/usr/bin/env python
+#############################################################################
+##
+## Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+## All rights reserved.
+## Contact: Nokia Corporation (qt-info@nokia.com)
+##
+## This file is part of the test suite 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 Technology Preview License Agreement accompanying
+## this package.
+##
+## 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.1, included in the file LGPL_EXCEPTION.txt in this package.
+##
+## If you have questions regarding the use of this file, please contact
+## Nokia at qt-info@nokia.com.
+##
+##
+##
+##
+##
+##
+##
+##
+## $QT_END_LICENSE$
+##
+#############################################################################
+
+import sys
+from PyQt4.QtCore import QDir, Qt
+from PyQt4.QtGui import *
+
+app = QApplication(sys.argv)
+
+background = QWidget()
+palette = QPalette()
+palette.setColor(QPalette.Window, QColor(Qt.white))
+background.setPalette(palette)
+
+model = QFileSystemModel()
+model.setRootPath(QDir.currentPath())
+
+treeView = QTreeView(background)
+treeView.setModel(model)
+treeView.setRootIndex(model.index(QDir.currentPath()))
+
+listView = QListView(background)
+listView.setModel(model)
+listView.setRootIndex(model.index(QDir.currentPath()))
+
+tableView = QTableView(background)
+tableView.setModel(model)
+tableView.setRootIndex(model.index(QDir.currentPath()))
+
+selection = QItemSelectionModel(model)
+treeView.setSelectionModel(selection)
+listView.setSelectionModel(selection)
+tableView.setSelectionModel(selection)
+
+layout = QHBoxLayout(background)
+layout.addWidget(listView)
+layout.addSpacing(24)
+layout.addWidget(treeView, 1)
+layout.addSpacing(24)
+layout.addWidget(tableView)
+background.show()
+
+sys.exit(app.exec_())
diff --git a/doc/src/examples/ahigl.qdoc b/doc/src/examples/ahigl.qdoc
deleted file mode 100644
index c5e2387..0000000
--- a/doc/src/examples/ahigl.qdoc
+++ /dev/null
@@ -1,572 +0,0 @@
-/****************************************************************************
-**
-** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
-** All rights reserved.
-** 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 Technology Preview License Agreement accompanying
-** this package.
-**
-** 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.1, included in the file LGPL_EXCEPTION.txt in this package.
-**
-** If you have questions regarding the use of this file, please contact
-** Nokia at qt-info@nokia.com.
-**
-**
-**
-**
-**
-**
-**
-**
-** $QT_END_LICENSE$
-**
-****************************************************************************/
-
-/*!
- \example qws/ahigl
- \title OpenGL for Embedded Systems Example
-
- \section1 Introduction
-
- This example demonstrates how you can use OpenGL for Embedded
- Systems (ES) in your own screen driver and \l{add your graphics
- driver to Qt for Embedded Linux}. In \l{Qt for Embedded Linux},
- painting is done in software, normally performed in two steps:
- First, each client renders its windows onto its window surface in
- memory using a paint engine. Then the server uses the screen
- driver to compose the window surface images and copy the
- composition to the screen. (See the \l{Qt for Embedded Linux
- Architecture} documentation for details.)
-
- This example is not for the novice. It assumes the reader is
- familiar with both OpenGL and the screen driver framework
- demonstrated in the \l {Accelerated Graphics Driver Example}.
-
- An OpenGL screen driver for Qt for Embedded Linux can use OpenGL ES
- in three ways. First, the \l{QWSServer}{Qt for Embedded Linux server}
- can use the driver to compose multiple window images and then show the
- composition on the screen. Second, clients can use the driver to
- accelerate OpenGL painting operations using the QOpenGLPaintEngine
- class. Finally, clients can use the driver to do OpenGL operations
- with instances of the QGLWidget class. This example implements all
- three cases.
-
- The example uses an implementation of OpenGL ES from
- \l {http://ati.amd.com}{ATI} for the
- \l {http://ati.amd.com/products/imageon238x/}{Imageon 2380}. The
- OpenGL include files gl.h and egl.h must be installed to compile
- the example, and the OpenGL and EGL libraries must be installed
- for linking. If your target device is different, you must install
- the include files and libraries for that device, and you also
- might need to modify the example source code, if any API signatures
- in your EGL library differ from the ones used here.
-
- After compiling and linking the example source, install the
- screen driver plugin with the command \c {make install}. To
- start an application that uses the plugin, you can either set the
- environment variable \l QWS_DISPLAY and then start the
- application, or just start the application with the \c -display
- switch, as follows:
-
- \snippet doc/src/snippets/code/doc_src_examples_ahigl.qdoc 0
-
- The example driver also implements an animated transition effect
- for use when showing new windows or reshowing windows that have
- been minimized. To enable this transition effect, run the
- application with \c {-display ahigl:effects}.
-
- \section1 The Class Definitions
-
- The example comprises three main classes plus some helper classes.
- The three main classes are the plugin (QAhiGLScreenPlugin), which
- is defined in qscreenahiglplugin.cpp, the screen driver
- (QAhiGLScreen), which is defined in qscreenahigl_qws.h, and the
- window surface (QAhiGLWindowSurface), which is defined in
- qwindowsurface_ahigl_p.h. The "Ahi" prefix in these class names
- stands for \e {ATI Handheld Interface}. The example was written
- for the ATI Imageon 2380, but it can also be used as a template
- for other ATI handheld devices.
-
- \section2 The Plugin Class Definition
-
- The screen driver plugin is class QAhiGLScreenPlugin.
-
- \snippet examples/qws/ahigl/qscreenahiglplugin.cpp 0
-
- QAhiGLScreenPlugin is derived from class QScreenDriverPlugin,
- which in turn is derived from QObject.
-
- \section2 The Screen Driver Class Definitions
-
- The screen driver classes are the public class QAhiGLScreen and
- its private implementation class QAhiGLScreenPrivate. QAhiGLScreen
- is derived from QGLScreen, which is derived from QScreen. If your
- screen driver will only do window compositions and display them,
- then you can derive your screen driver class directly from
- QScreen. But if your screen driver will do accelerated graphics
- rendering operations with the QOpenGLPaintEngine, or if it will
- handle instances of class QGLWidget, then you must derive your
- screen driver class from QGLScreen.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.h 0
-
- All functions in the public API of class QAhiGLScreen are virtual
- functions declared in its base classes. hasOpenGL() is declared in
- QGLScreen. It simply returns true indicating our example screen
- driver does support OpenGL operations. The other functions in the
- public API are declared in QScreen. They are called by the
- \l{QWSServer}{Qt for Embedded Linux server} at the appropriate times.
-
- Note that class QScreen is a documented class but class QGLScreen
- is not. This is because the design of class QGLScreen is not yet
- final.
-
- The only data member in class QAhiGLScreen is a standard d_ptr,
- which points to an instance of the driver's private implementation
- class QAhiGLScreenPrivate. The driver's internal state is stored
- in the private class. Using the so-called d-pointer pattern allows
- you to make changes to the driver's internal design without
- breaking binary compatibility.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 0
-
- Class QAhiGLScreenPrivate is derived from QObject so that it can
- use the Qt signal/slot mechanism. QAhiGLScreen is not a QObject,
- so it can't use the signal/slot mechanism. Signals meant for our
- screen driver are received by slots in the private implementation
- class, in this case, windowEvent() and redrawScreen().
-
- \section2 The Window Surface Class Definitions
-
- The window surface classes are QAhiGLWindowSurface and its private
- implementation class QAhiGLWindowSurfacePrivate. We create class
- QAhiGLWindowSurface so the screen driver can use the OpenGL paint
- engine and the OpenGL widget, classes QOpenGLPaintEngine and
- QGLWidget. QAhiGLWindowSurface is derived from the more general
- OpenGL window surface class, QWSGLWindowSurface, which is derived
- from QWSWindowSurface.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl_p.h 0
-
- In addition to implementing the standard functionality required by
- any new subclass of QWSWindowSurface, QAhiGLWindowSurface also
- contains the textureId() function used by QAhiGLScreen.
-
- The same d-pointer pattern is used in this window surface class.
- The private implementation class is QAhiGLWindowSurfacePrivate. It
- allows making changes to the state variables of the window surface
- without breaking binary compatibility.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 0
-
- In this case, our private implementation class has no member
- functions except for its constructor. It contains only public data
- members which hold state information for the window surface.
-
- \section2 The Helper Classes
-
- The example screen driver maintains a static \l {QMap} {map} of
- all the \l {QWSWindow} {windows} it is showing on the screen.
- Each window is mapped to an instance of struct WindowInfo.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 2
-
- As each new window is created, an instance of struct WindowInfo is
- allocated and inserted into the window map. WindowInfo uses a
- GLuint to identify the OpenGL texture it creates for the window.
- Note that the example driver, in addition to drawing windows using
- OpenGL, also supports drawing windows in the normal way without
- OpenGL, but it uses an OpenGL texture for the rendering operations
- in either case. Top-level windows that are drawn without OpenGL
- are first rendered in the normal way into a shared memory segment,
- which is then converted to a OpenGL texture and drawn to the
- screen.
-
- To animate the window transition effect, WindowInfo uses an
- instance of the helper class ShowAnimation. The animation is
- created by the windowEvent() slot in QAhiGLScreenPrivate, whenever
- a \l {QWSServer::WindowEvent} {Show} window event is emitted by
- the \l {QWSServer} {window server}. The server emits this signal
- when a window is shown the first time and again later, when the
- window is reshown after having been minimized.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 1
-
- Class ShowAnimation is derived from the QTimeLine class, which is
- used for controlling animations. QTimeLine is a QObject, so
- ShowAnimation can use the Qt signal/slot mechanism. We will see
- how the timeline's \l {QTimeLine::valueChanged()} {valueChanged()}
- and \l {QTimeLine::finished()} {finished()} signals are used to
- control the animation and then destroy the instance of
- ShowAnimation, when the animation ends. The ShowAnimation
- constructor needs the pointer to the screen driver's private
- implementation class so it can set up these signal/slot
- connections.
-
- \section1 The Class Implementations
-
- \section2 The Plugin Class Implementation
-
- QAhiGLScreenPlugin is a straightforward derivation of
- QScreenDriverPlugin. It reimplements \l{QScreenDriverPlugin::}{keys()}
- and \l{QScreenDriverPlugin::}{create()}. They are
- called as needed by the \l{QWSServer}{Qt for Embedded Linux server.}
- Recall that the server detects that the ahigl screen driver has
- been requested, either by including "ahigl" in the value for the
- environment variable QWS_DISPLAY, or by running your application
- with a command line like the following.
-
- \snippet doc/src/snippets/code/doc_src_examples_ahigl.qdoc 1
-
- The server calls \l {QScreenDriverPlugin::} {keys()}, which
- returns a \l {QStringList} containing the singleton "ahigl"
- matching the requested screen driver and telling the server that
- it can use our example screen driver. The server then calls \l
- {QScreenDriverPlugin::} {create()}, which creates the instance of
- QAhiGLScreen.
-
- \snippet examples/qws/ahigl/qscreenahiglplugin.cpp 1
-
- In the code snippet above, the macro Q_EXPORT_PLUGIN2 is used to export
- the plugin class, QAhiGLScreen, for the qahiglscreen plugin.
- Further information regarding plugins and how to create them
- can be found at \l{How to Create Qt Plugins}.
-
- \section2 The Screen Driver Class Implementations
-
- The plugin creates the singleton instance of QAhiGLScreen. The
- constructor is passed a \c displayId, which is used in the base
- class QGLScreen to identify the server that the screen driver is
- connected to. The constructor also creates its instance of
- QAhiGLScreenPrivate, which instantiates a QTimer. The timeout()
- signal of this timer is connected to the redrawScreen() slot so
- the timer can be used to limit the frequency of actual drawing
- operations in the hardware.
-
- The public API of class QAhiGLScreen consists of implementations
- of virtual functions declared in its base classes. The function
- hasOpenGL() is declared in base class QGLScreen. The others are
- declared in base class QScreen.
-
- The \l {QScreen::}{connect()} function is the first one called by
- the server after the screen driver is constructed. It initializes
- the QScreen data members to hardcoded values that describe the ATI
- screen. A better implementation would query the hardware for the
- corresponding values in its current state and use those. It asks
- whether the screen driver was started with the \c effects option
- and sets the \c doEffects flag accordingly.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 7
-
- The \l {QScreen::}{initDevice()} function is called by the server
- after \l {QScreen::}{connect()}. It uses EGL library functions to
- initialize the ATI hardware. Note that some data structures used
- in this example are specific to the EGL implementation used, e.g.,
- the DummyScreen structure.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 8
-
- Note the signal/slot connection at the bottom of initDevice(). We
- connect the server's QWSServer::windowEvent() signal to the
- windowEvent() slot in the screen driver's private implementation
- class. The windowEvent() slot handles three window events,
- QWSServer::Create, QWSServer::Destroy, and QWSServer::Show.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 5
-
- The function manages instances of the helper classes associated
- with each window. When a QWSServer::Create event occurs, it means
- a new top-level \l {QWSWindow} {window} has been created. In this
- case, an instance of helper class WindowInfo is created and
- inserted into the window map with the pointer to the new \l
- {QWSWindow} {window} as its key. When a QWSServer::Destroy event
- occurs, a window is being destroyed, and its mapping is removed
- from the window map. These two events are straightforward. The
- tricky bits happen when a QWSServer::Show event occurs. This case
- occurs when a window is shown for the first time and when it is
- reshown after having been minimized. If the window transition
- effect has been enabled, a new instance of the helper class
- ShowAnimation is created and stored in a QPointer in the window's
- instance of WindowInfo. The constructor of ShowAnimation
- automatically \l {QTimeLine::start()} {starts} the animation of
- the transition effect.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 3
-
- To ensure that a ShowAnimation is not deleted until its animation
- ends, the \l {QTimeLine::finished()} {finished()} signal is
- connected to the \l {QObject::deleteLater()} {deleteLater()} slot.
- When the animation ends, the finished() signal is emitted and the
- deleteLater() slot deletes the ShowAnimation. The key here is that
- the pointer to the ShowAnimation is stored in a QPointer in the
- WindowInfo class. This QPointer will also be notified when the
- ShowAnimation is deleted, so the QPointer in WindowInfo can null
- itself out, if and only if it is still pointing to the instance
- of ShowAnimation being deleted.
-
- The \l {QTimeLine::valueForTime()} {valueForTime()} function in
- QTimeLine is reimplemented in ShowAnimation to return time values
- that represent a curved path for the window transition effect.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 4
-
- valueForTime() is called internally, when the time interval it
- computed during the previous call has elapsed. If it computes a
- next time value that is different from the one computed
- previously, the \l {QTimeLine::valueChanged()} {valueChanged()}
- signal is emitted. The ShowAnimation constructor shown above
- connects this signal to the redrawScreen() slot in the screen
- driver's private implementation class. This is how the animation
- actually happens.
-
- The screen driver's implementation of \l {QScreen::}
- {exposeRegion()} is where the main work of the screen driver is
- meant to be done, i.e., updating the screen. It is called by the
- \l {QWSServer} {window system} to update a particular window's
- region of the screen. But note that it doesn't actually update the
- screen, i.e., it doesn't actually call redrawScreen() directly,
- but starts the updateTimer, which causes redrawScreen() to be
- called once for each updateTimer interval. This means that all
- calls to exposeRegion() during an updateTimer interval are handled
- by a single call to redrawScreen(). Thus updateTimer can be used
- to limit the frequency of screen updates.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 13
-
- The call to the private function invalidateTexture() destroys
- the window's existing texture (image). This ensures that a new
- texture will be created for the window, when redrawScreen() is
- eventually called.
-
- But there is a caveat to using updateTimer to limit the frequency
- of screen updates. When the driver's animated transition effect
- for new windows is enabled and a new window is being shown for the
- first time or reshown after having been minimized, an instance of
- ShowAnimation is created to run the animation. The valueChanged()
- signal of this ShowAnimation is also connected to the
- redrawScreen() slot, and QTimeLine, the base class of our
- ShowAnimation, uses its own, internal timer to limit the speed of
- the animation. This means that in the driver as currently written,
- if the window transition effect is enabled (i.e. if the plugin is
- started, with \c {-display ahigl:effects}), then redrawScreen()
- can be called both when the update timer times out and when the
- ShowAnimation timer times out, so the screen might get updated
- more often than the frequency established by the update timer.
- This may or may not be a bug, depending on your own hardware, if
- you use this example as a template for your own OpenGL driver.
-
- The screen driver's private function redrawScreen() constructs
- the window compositions. It is called only by the function of the
- same name in the screen driver's private implementation class.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 6
-
- Recall that this redrawScreen() in the private implementation
- class is a slot function connected to two signals, the \c
- timeout() signal of the updateTimer in the private implementation
- class, and the valueChanged() signal of the helper class
- ShowAnimation. Thus, the screen is only ever updated when a
- timeout of one of the two timers occurs. This is important for two
- reasons. First, the screen is meant to be updated no more than
- once per updateTimer interval. Second, however, if the animated
- window transition effect is requested, the screen might be updated
- more often than that, and this might be a bug if the hardware
- can't handle more frequent updates.
-
- The redrawScreen() in QAhiGLScreen begins by using standard
- OpenGL to fill the screen with the background color.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 10
-
- Next it iterates over the list of all \l {QWSWindow} {client
- windows} obtained from the \l {QWSServer} {server}, extracting
- from each window its instance of QWSWIndowSurface, then using that
- window surface to create an OpenGL texture, and finally calling
- the helper function drawWindow() to draw the texture on the
- screen.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 11
-
- Note the call to glBindTexture() immediately before the call to
- drawWindow(). This call binds the identifer \c GL_TEXTURE_2D to
- the texture we have just created. This makes our texture
- accessible to functions in the OpenGL libraries. If you miss that
- point, digging into the internals of drawWindow() won't make much
- sense.
-
- Finally, the cursor is added to the window composition, and in the
- last statement, the whole thing is displayed on the screen.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 12
-
- The call to \c drawWindow(win,progress), in addition to passing a
- pointer to the window to be redrawn, also passes the \c progress
- parameter obtained by calling \l {QTimeLine::currentValue()} on
- the window's instance of ShowAnimation. Recall that the current
- value of the timeline is updated internally by a timer local to
- the timeline, and the redrawScreen() slot is called whenever the
- current value changes. The progress value will only be used if
- the animated transition effect has been enabled. These extra calls
- of redrawScreen() may cause the screen to be updated more often
- than the rate determined by updateTimer. This must be taken
- into account, if you set your updateTimer to timeout at the
- maximum screen update frequency your hardware can handle.
-
- The drawWindow() function is not shown here and not explained
- further, but the call to drawWindow() is the entry point to a
- hierarchy of private helper functions that execute sequences of
- OpenGL and EGL library calls. The reader is assumed to be familiar
- enough with the OpenGL and EGL APIs to understand the code in
- these helper functions on his own. Besides drawWindow(), the list
- of these helper functions includes drawQuad(), drawQuadWavyFlag(),
- the two overloadings of drawQuad_helper() (used by drawQuad() and
- drawQuadWacyFlag()), and setRectCoords().
-
- Note the two different ways the window's texture can be created in
- redrawScreen(). If the window surface is an OpenGL window surface
- (QAhiGLWindowSurface described below), the texture is obtained
- from the window surface directly by calling its textureId()
- function. But when the window surface is not an OpenGL one, the
- static function createTexture() is called with the window
- surface's \l {QImage} {image} to copy that image into an OpenGL
- texture. This is done with the EGL functions glTexImage2D() and
- glTexSubImage2D(). createTexture() is another function that
- should be understandable for exsperienced OpenGL users, so it is
- not shown or explained further here.
-
- The two implementations of \l {QScreen::}{createSurface()} are for
- instantiating new window surfaces. The overloading with the widget
- parameter is called in the client.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 14
-
- If the parameter is an \l {QGLWidget} {OpenGL widget}, or, when it
- isn't an OpenGL widget but its size is no bigger than 256 x 256,
- we instantiate our subclass QAhiGLWindowSurface. Otherwise, we
- instantiate a QWSWindowSurface. The size contraint is a
- limitation of the OpenGL ES libraries we are using for our ATI
- device.
-
- Note the test at the top of the function asking if our application
- process is the \l {QApplication::GuiServer} {server}. We only
- create instances of QAhiGLWindowSurface if our client is in the
- server process. This is because of an implementation restriction
- required by the OpenGL library used in the example. They only
- support use of OpenGL in the server process. Hence a client can
- use the QAhiGLWindowSurface if the client is in the server
- process.
-
- The other overloading of createSurface() is called by the
- server to create a window surface that will hold a copy of a
- client side window surface.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 15
-
- This overloading accepts a QString parameter identifying the type
- of window surface to instantiate. QAhiGLWindowSurface is
- instantiated if the parameter is \c ahigl. Otherwise, a normal
- QWSWindowSurface is instantiated. The client's window surface
- communicates its image data to the server's window surface through
- shared memory.
-
- The implementation of \l {QScreen::}{setMode()}, is a stub in this
- example. It would normally reset the frame buffer's resolution.
- Its parameters are the \e width, \e height, and the bit \e depth
- for the frame buffer's new resolution. If you implement setMode()
- in your screen driver, remember that it must emit a signal to warn
- other applications to redraw their frame buffers with the new
- resolution. There is no significance to setMode() not being
- implemented in this example. It simply wasn't implemented.
- However, the stub had to be included because QScreen declares
- setMode() to be pure virtual.
-
- Before the application exits, the server will call \l {QScreen::}
- {shutdownDevice()} to release the hardware resources. This is also
- done using EGL library functions.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 9
-
- The server will also call \l {QScreen::}{disconnect()}, but this
- function is only a stub in this example.
-
- \section2 The window Surface Class Implementations
-
- QAhiGLScreen creates instances of QAhiGLWindowSurface in its two
- createSurface() functions, and there are two constructors for
- QAhiGLWindowSurface that correspond to these two versions of
- createSurface(). The constructor accepting a \l {QWidget} {widget}
- parameter is called by the client side version of createSurface(),
- and the constructor without the \l {QWidget} {widget} parameter is
- called by the server side version. There will be a window surface
- constructed on the server side for each one constructed on the
- client side.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 1
- \codeline
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 2
-
- The constructors create an instance of QAhiGLWindowSurfacePrivate,
- the private implementation class, which contains all the state
- variables for QAhiGLWindowSurface. The client side constructor
- also creates an instance of QWSGLPaintDevice, the OpenGL paint
- device, for return by \l {QWSWindowSurface::} {paintDevice()}.
- This ensures that all \l {QPainter}s used on this surface will use
- an OpenGL enabled QPaintEngine. It is a bit of jiggery pokery,
- which is required because \l {QWSWindowSurface::} {paintDevice()}
- is declared pure virtual. Normally, the client side constructor
- will be called with an \l {QGLWidget}{OpenGL widget}, which has
- its own \l {QWidget::} {paintEngine()} function that returns the
- global static OpenGL paint engine, but because the constructor
- also accepts a normal \l {QWidget}{widget}, it must be able to
- find the OpenGL paint engine in that case as well, so since \l
- {QWSWindowSurface::} {paintDevice()} must be implemented anyway,
- the constructor creates an instance of QWSGLPaintDevice, which can
- always return the global static pointer to QOpenGLPaintEngine.
-
- The OpenGL library implementation used for this example only
- supports one OpenGL context. This context is therefore shared
- among the single instance of QAhiGLScreen and all instances of
- QAhiGLWindowSurface. It is passed to both constructors.
-
- This example uses the OpenGL frame buffer object extension, which
- allows for accelerating OpenGL painting operations. Using this
- OpenGL extension, painting operations are performed in a frame
- buffer object, which QAhiGLScreen later uses to construct window
- compositions on the screen. Allocation of the frame buffer object
- is performed in \l {QWindowSurface::} {setGeometry()}. A safer way
- to use this extension would be to first test to see if the
- extension is supported by your OpenGL library, and use a different
- approach if it is not.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 3
-
- Since there can be several instances of the QAhiGLWindowSurface, we need
- to make sure that the correct framebuffer object is active before painting.
- This is done by reimplementing \l QWindowSurface::beginPaint():
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 4
-
- Finally we need to make sure that whenever a widget grows beyond the size
- supported by this driver (256 x 256), the surface is deleted and a new
- standard surface is created instead. This is handled by reimplementing
- \l QWSWindowSurface::isValid():
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 5
-*/
diff --git a/doc/src/examples/ftp.qdoc b/doc/src/examples/ftp.qdoc
index ec8584c..8fded88 100644
--- a/doc/src/examples/ftp.qdoc
+++ b/doc/src/examples/ftp.qdoc
@@ -78,13 +78,13 @@
\l{QFtp::Command}{commands} we request are finished, the progress
of current commands, and information about files on the server.
- \snippet examples/network/ftp/ftpwindow.h 0
+ \snippet examples/network/qftp/ftpwindow.h 0
We will look at each slot when we examine the \c FtpWindow
implementation in the next section. We also make use of a few
private variables:
- \snippet examples/network/ftp/ftpwindow.h 1
+ \snippet examples/network/qftp/ftpwindow.h 1
The \c isDirectory hash keeps a history of all entries explored on
the FTP server, and registers whether an entry represents a
@@ -98,7 +98,7 @@
We move on to the slots, starting with \c connectOrDisconnect().
- \snippet examples/network/ftp/ftpwindow.cpp 0
+ \snippet examples/network/qftp/ftpwindow.cpp 0
If \c ftp is already pointing to a QFtp object, we QFtp::Close its
FTP connection and delete the object it points to. Note that we do
@@ -106,7 +106,7 @@
to finish its abort operation.
\dots
- \snippet examples/network/ftp/ftpwindow.cpp 1
+ \snippet examples/network/qftp/ftpwindow.cpp 1
If we get here, \c connectOrDisconnect() was called to establish a
new FTP connection. We create a new QFtp for our new connection,
@@ -118,7 +118,7 @@
is emitted repeatedly during an FTP file transfer, giving us
progress reports.
- \snippet examples/network/ftp/ftpwindow.cpp 2
+ \snippet examples/network/qftp/ftpwindow.cpp 2
The \gui {Ftp Server} line edit contains the IP address or
hostname of the server to which we want to connect. We first check
@@ -134,39 +134,39 @@
We move on to the \c downloadFile() slot:
- \snippet examples/network/ftp/ftpwindow.cpp 3
+ \snippet examples/network/qftp/ftpwindow.cpp 3
\dots
- \snippet examples/network/ftp/ftpwindow.cpp 4
+ \snippet examples/network/qftp/ftpwindow.cpp 4
We first fetch the name of the file, which we find in the selected
item of \c fileList. We then start the download by using
QFtp::get(). QFtp will send progress signals during the download
and a signal when the download is completed.
- \snippet examples/network/ftp/ftpwindow.cpp 5
+ \snippet examples/network/qftp/ftpwindow.cpp 5
QFtp supports canceling the download of files.
- \snippet examples/network/ftp/ftpwindow.cpp 6
+ \snippet examples/network/qftp/ftpwindow.cpp 6
The \c ftpCommandFinished() slot is called when QFtp has
finished a QFtp::Command. If an error occurred during the
command, QFtp will set \c error to one of the values in
the QFtp::Error enum; otherwise, \c error is zero.
- \snippet examples/network/ftp/ftpwindow.cpp 7
+ \snippet examples/network/qftp/ftpwindow.cpp 7
After login, the QFtp::list() function will list the top-level
directory on the server. addToList() is connected to
QFtp::listInfo(), and will be invoked for each entry in that
directory.
- \snippet examples/network/ftp/ftpwindow.cpp 8
+ \snippet examples/network/qftp/ftpwindow.cpp 8
When a \l{QFtp::}{Get} command is finished, a file has finished
downloading (or an error occurred during the download).
- \snippet examples/network/ftp/ftpwindow.cpp 9
+ \snippet examples/network/qftp/ftpwindow.cpp 9
After a \l{QFtp::}{List} command is performed, we have to check if
no entries were found (in which case our \c addToList() function
@@ -174,7 +174,7 @@
Let's continue with the \c addToList() slot:
- \snippet examples/network/ftp/ftpwindow.cpp 10
+ \snippet examples/network/qftp/ftpwindow.cpp 10
When a new file has been resolved during a QFtp::List command,
this slot is invoked with a QUrlInfo describing the file. We
@@ -182,26 +182,26 @@
does not have a current item, we set the new item to be the
current item.
- \snippet examples/network/ftp/ftpwindow.cpp 11
+ \snippet examples/network/qftp/ftpwindow.cpp 11
The \c processItem() slot is called when an item is double clicked
in the \gui {File List}. If the item represents a directory, we
want to load the contents of that directory with QFtp::list().
- \snippet examples/network/ftp/ftpwindow.cpp 12
+ \snippet examples/network/qftp/ftpwindow.cpp 12
\c cdToParent() is invoked when the user requests to go to the
parent directory of the one displayed in the file list. After
changing the directory, we QFtp::List its contents.
- \snippet examples/network/ftp/ftpwindow.cpp 13
+ \snippet examples/network/qftp/ftpwindow.cpp 13
The \c updateDataTransferProgress() slot is called regularly by
QFtp::dataTransferProgress() when a file download is in progress.
We use a QProgressDialog to show the download progression to the
user.
- \snippet examples/network/ftp/ftpwindow.cpp 14
+ \snippet examples/network/qftp/ftpwindow.cpp 14
The \c enableDownloadButton() is called whenever the current item
in \c fileList changes. If the item represents a file, the \gui
diff --git a/doc/src/examples/musicplayerexample.qdoc b/doc/src/examples/musicplayerexample.qdoc
index 41c9f3a..7145583 100644
--- a/doc/src/examples/musicplayerexample.qdoc
+++ b/doc/src/examples/musicplayerexample.qdoc
@@ -40,7 +40,7 @@
****************************************************************************/
/*!
- \example phonon/musicplayer
+ \example phonon/qmusicplayer
\title Music Player Example
The Music Player Example shows how to use Phonon - the multimedia
@@ -90,7 +90,7 @@
look at them when we walk through the \c MainWindow
implementation.
- \snippet examples/phonon/musicplayer/mainwindow.h 2
+ \snippet examples/phonon/qmusicplayer/mainwindow.h 2
We use the \l{Phonon::}{SeekSlider} to move the current playback
position in the media stream, and the \l{Phonon::}{VolumeSlider}
@@ -99,7 +99,7 @@
metaInformationProvider, to get the meta information from the
music files. More on this later.
- \snippet examples/phonon/musicplayer/mainwindow.h 1
+ \snippet examples/phonon/qmusicplayer/mainwindow.h 1
The \l{Phonon::}{MediaObject} informs us of the state of the playback and
properties of the media it is playing back through a series of
@@ -116,7 +116,7 @@
We start with the constructor:
- \snippet examples/phonon/musicplayer/mainwindow.cpp 0
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 0
We start by instantiating our media and audio output objects.
As mentioned, the media object knows how to playback
@@ -130,20 +130,20 @@
paths. Objects are connected using the \c createPath() function,
which is part of the Phonon namespace.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 1
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 1
We also connect signals of the media object to slots in our \c
MainWindow. We will examine them shortly.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 2
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 2
Finally, we call private helper functions to set up the GUI.
The \c setupUi() function contains code for setting up the seek
, and volume slider. We move on to \c setupUi():
- \snippet examples/phonon/musicplayer/mainwindow.cpp 3
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 3
\dots
- \snippet examples/phonon/musicplayer/mainwindow.cpp 4
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 4
After creating the widgets, they must be supplied with the
\l{Phonon::}{MediaObject} and \l{Phonon::}{AudioOutput} objects
@@ -152,12 +152,12 @@
In the \c setupActions(), we connect the actions for the play,
pause, and stop tool buttons, to slots of the media object.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 5
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 5
We move on to the slots of \c MainWindow, starting with \c
addFiles():
- \snippet examples/phonon/musicplayer/mainwindow.cpp 6
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 6
In the \c addFiles() slot, we add files selected by the user to
the \c sources list. We then set the first source selected on the
@@ -169,7 +169,7 @@
stateChanged() signal. The \c stateChanged() slot is connected
to this signal.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 9
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 9
The \l{Phonon::MediaObject::}{errorString()} function gives a
description of the error that is suitable for users of a Phonon
@@ -177,7 +177,7 @@
helps us determine whether it is possible to try to play the same
file again.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 10
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 10
We update the GUI when the playback state changes, i.e., when it
starts, pauses, stops, or resumes.
@@ -188,26 +188,26 @@
The \c tick() slot is connected to a \l{Phonon::}{MediaObject} signal which is
emitted when the playback position changes:
- \snippet examples/phonon/musicplayer/mainwindow.cpp 11
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 11
The \c time is given in milliseconds.
When the table is clicked on with the mouse, \c tableClick()
is invoked:
- \snippet examples/phonon/musicplayer/mainwindow.cpp 12
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 12
Since we stop the media object, we first check whether it is
currently playing. \c row contains the row in the table that was
clicked upon; the indices of \c sources follows the table, so we
can simply use \c row to find the new source.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 13
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 13
When the media source changes, we simply need to select the
corresponding row in the table.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 14
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 14
When \c metaStateChanged() is invoked, \c
metaInformationProvider has resolved the meta data for its current
@@ -220,7 +220,7 @@
music table. A file might not contain the meta data requested,
in which case an empty string is returned.
- \snippet examples/phonon/musicplayer/mainwindow.cpp 15
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 15
If we have media sources in \c sources of which meta information
is not resolved, we set a new source on the \c
@@ -229,7 +229,7 @@
We move on to the \c aboutToFinish() slot:
- \snippet examples/phonon/musicplayer/mainwindow.cpp 16
+ \snippet examples/phonon/qmusicplayer/mainwindow.cpp 16
When a file is finished playing, the Music Player will move on and
play the next file in the table. This slot is connected to the
@@ -244,5 +244,5 @@
\l{QCoreApplication::}{setApplicationName()}. This is because
D-Bus, which is used by Phonon on Linux systems, demands this.
- \snippet examples/phonon/musicplayer/main.cpp 1
+ \snippet examples/phonon/qmusicplayer/main.cpp 1
*/
diff --git a/doc/src/frameworks-technologies/gestures.qdoc b/doc/src/frameworks-technologies/gestures.qdoc
index 1e3cc47..158a273 100644
--- a/doc/src/frameworks-technologies/gestures.qdoc
+++ b/doc/src/frameworks-technologies/gestures.qdoc
@@ -102,8 +102,6 @@
\snippet examples/gestures/imageviewer/imagewidget.cpp swipe slot start
- \snippet examples/gestures/imageviewer/imagewidget.cpp swipe slot finish
-
Here, we examine the direction in which the user swiped the widget and modify
its contents accordingly.
diff --git a/doc/src/frameworks-technologies/model-view-programming.qdoc b/doc/src/frameworks-technologies/model-view-programming.qdoc
index bc884df..f0f20b4 100644
--- a/doc/src/frameworks-technologies/model-view-programming.qdoc
+++ b/doc/src/frameworks-technologies/model-view-programming.qdoc
@@ -215,8 +215,8 @@
\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 QFileSystemModel 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
@@ -313,14 +313,14 @@
\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,
+ QFileSystemModel. 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
+ QFileSystemModel 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
+ QFileSystemModel 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.
@@ -328,22 +328,25 @@
\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
+ to use with QFileSystemModel. 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
+ We set up a QFileSystemModel 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
+ The model is set up to use data from a certain file system. The call to
+ \l{QFileSystemModel::}{setRootPath()} tell the model which drive on the
+ file system to expose to the views.
+
+ 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
@@ -351,13 +354,13 @@
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.
+ model as the argument. We filter the data supplied by the model by calling
+ the \l{QAbstractItemView::}{setRootIndex()} function on each view, passing
+ a suitable \e{model index} from the file system model for the current
+ directory.
- 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
+ The \c index() function used in this case is unique to QFileSystemModel; 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
@@ -556,19 +559,19 @@
\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
+ indexes, we set up a QFileSystemModel 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:
+ We construct a file system 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.
+ In this case, we set up a default QFileSystemModel, obtain a parent index
+ using a specific implementation of \l{QFileSystemModel::}{index()}
+ provided by that model, and we count the number of rows in the model using
+ the \l{QFileSystemModel::}{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
@@ -581,7 +584,7 @@
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
+ \l{QFileSystemModel::}{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.
diff --git a/doc/src/getting-started/demos.qdoc b/doc/src/getting-started/demos.qdoc
index 532715e..8f2829a 100644
--- a/doc/src/getting-started/demos.qdoc
+++ b/doc/src/getting-started/demos.qdoc
@@ -157,7 +157,7 @@
\section1 Phonon
\list
- \o \l{demos/mediaplayer}{Media Player} demonstrates how the \l{Phonon Module} can be
+ \o \l{demos/qmediaplayer}{Media Player} demonstrates how the \l{Phonon Module} can be
used to implement a basic media player application.
\endlist
diff --git a/doc/src/getting-started/examples.qdoc b/doc/src/getting-started/examples.qdoc
index 543a2e1..d72f816 100644
--- a/doc/src/getting-started/examples.qdoc
+++ b/doc/src/getting-started/examples.qdoc
@@ -295,6 +295,8 @@
\o \image animation-examples.png
\o
+ These examples show to to use the \l{The Animation Framework}{animation framework}
+ to build highly animated, high-performance GUIs.
\row
\o{2,1} \l{Gestures Examples}{\bold{Gestures}}
@@ -322,6 +324,8 @@
\o \image activeqt-examples.png ActiveQt
\o
+ These examples demonstrate how to write ActiveX controls and control servers
+ with Qt, and how to use ActiveX controls and COM objects in a Qt application.
\row
\o{2,1} \l{Qt Quarterly}{\bold{Qt Quarterly}}
@@ -823,7 +827,7 @@
\list
\o \l{phonon/capabilities}{Capabilities}\raisedaster
- \o \l{phonon/musicplayer}{Music Player}\raisedaster
+ \o \l{phonon/qmusicplayer}{Music Player}\raisedaster
\endlist
*/
@@ -1073,9 +1077,13 @@
\contentspage Qt Examples
\nextpage D-Bus Examples
+ The API of the gesture framework is not yet finalized and
+ still subject to change.
+\omit
\list
\o \l{widgets/imageviewer}{Image Viewer}
\endlist
+\endomit
*/
/*!
@@ -1113,7 +1121,6 @@
\o \l{qws/svgalib}{Accelerated Graphics Driver}\raisedaster
\o \l{qws/dbscreen}{Double Buffered Graphics Driver}\raisedaster
\o \l{qws/mousecalibration}{Mouse Calibration}\raisedaster
- \o \l{qws/ahigl}{OpenGL for Embedded Systems}\raisedaster
\o \l{qws/simpledecoration}{Simple Decoration}\raisedaster
\endlist
*/
diff --git a/doc/src/getting-started/installation.qdoc b/doc/src/getting-started/installation.qdoc
index 539c1d5..8269552 100644
--- a/doc/src/getting-started/installation.qdoc
+++ b/doc/src/getting-started/installation.qdoc
@@ -497,22 +497,22 @@ in the \l{Qt for Windows CE Requirements} document.
We hope you will enjoy using Qt. Good luck!
*/
-/*! \page install-S60-installer.html
+/*! \page install-Symbian-installer.html
-\title Installing Qt on S60 using binary package
+\title Installing Qt on the Symbian platform using binary package
\ingroup qts60
-\brief How to install Qt on S60 using the binary package.
+\brief How to install Qt on the Symbian platform using the binary package.
-\note Qt for S60 has some requirements that are given in more detail
-in the \l{Qt for S60 Requirements} document.
+\note Qt for Symbian platform has some requirements that are given in more detail
+in the \l{Qt for Symbian platform Requirements} document.
\list 1
\o Install Qt
- Run \c{qt-s60-%VERSION%.exe} and follow the instructions.
+ Run \c{qt-symbian-opensource-%VERSION%.exe} and follow the instructions.
- \note Qt must be installed on the same drive as the S60 SDK you are
+ \note Qt must be installed on the same drive as the Symbian SDK you are
using, and the install path must not contain any spaces.
\o Running Qt demos
@@ -520,14 +520,14 @@ in the \l{Qt for S60 Requirements} document.
We've included a subset of the Qt demos in this package for you
to try out. An excellent starting point is the "fluidlauncher"
demo. To run the demo on a real device, you first have to install
- \c{qt_for_s60.sis} and \c{fluidlauncher.sis} found in the Qt installation
+ \c{qt.sis} and \c{fluidlauncher.sis} found in the Qt installation
directory. Begin by connecting your phone using the USB cable and
selecting "PC Suite mode". In Windows Explorer right click on the
\c{.sis} files and select "Install with Nokia Application Installer"
and follow the instructions.
To run the demos and examples on the emulator, you need to build them first.
- Open the "Qt for S60 Command Prompt" from the Start menu and type:
+ Open the "Qt for Symbian platform Command Prompt" from the Start menu and type:
\snippet doc/src/snippets/code/doc_src_installation.qdoc 25
@@ -536,27 +536,29 @@ in the \l{Qt for S60 Requirements} document.
\snippet doc/src/snippets/code/doc_src_installation.qdoc 27
- For more information about building and running Qt programs on S60,
- see \l{S60 - Introduction to using Qt}.
+ For more information about building and running Qt programs on the
+Symbian platform,
+ see \l{Symbian platform - Introduction to using Qt}.
We hope you will enjoy using Qt.
\endlist
*/
-/*! \page install-S60.html
+/*! \page install-Symbian.html
-\title Installing Qt on S60
+\title Installing Qt on the Symbian platform
\ingroup installation
\ingroup qts60
-\brief How to install Qt on S60
+\brief How to install Qt for the Symbian platform
-\note Qt for S60 has some requirements that are given in more detail
-in the \l{Qt for S60 Requirements} document.
+\note Qt for the Symbian platform has some requirements that are given in more detail
+in the \l{Qt for Symbian platform Requirements} document.
-\note \bold {This document describes how to install and configure Qt for S60 from scratch.
+\note \bold {This document describes how to install and configure Qt for
+the Symbian platform from scratch.
If you are using pre-built binaries, follow the instructions
-\l{Installing Qt on S60 using binary package}{here}.}
+\l{Installing Qt on the Symbian platform using binary package}{here}.}
\list 1
@@ -565,7 +567,7 @@ If you are using pre-built binaries, follow the instructions
Uncompress the package into the directory you want Qt installed,
e.g. \c{C:\Qt\%VERSION%}.
- \note Qt must be installed on the same drive as the S60 SDK you are
+ \note Qt must be installed on the same drive as the Symbian SDK you are
using, and the install path must not contain any spaces.
\o Environment variables
@@ -580,13 +582,13 @@ If you are using pre-built binaries, follow the instructions
On Windows the PATH can be extended by navigating to
"Control Panel->System->Advanced->Environment variables".
- In addition, you must configure the environment for use with the S60
+ In addition, you must configure the environment for use with the Symbian
emulator. This is done by locating the Carbide.c++ submenu on the Start
menu, and choosing "Configure environment for WINSCW command line".
\o Configure Qt
- To configure Qt for S60, do:
+ To configure Qt for the Symbian platform, do:
\snippet doc/src/snippets/code/doc_src_installation.qdoc 23
to build the tools using MinGW, and the libraries using abld.
@@ -633,8 +635,8 @@ If you are using pre-built binaries, follow the instructions
\snippet doc/src/snippets/code/doc_src_installation.qdoc 27
- For more information about building and running Qt programs on S60,
- see \l{S60 - Introduction to using Qt}.
+ For more information about building and running Qt programs on the
+Symbian platform, see \l{Symbian platform - Introduction to using Qt}.
We hope you will enjoy using Qt.
@@ -669,7 +671,7 @@ If you are using pre-built binaries, follow the instructions
\list
\o \l{Qt for Embedded Linux Requirements}
\o \l{Qt for Mac OS X Requirements}
- \o \l{Qt for S60 Requirements}
+ \o \l{Qt for Symbian platform Requirements}
\o \l{Qt for Windows CE Requirements}
\o \l{Qt for Windows Requirements}
\o \l{Qt for X11 Requirements}
@@ -953,13 +955,13 @@ If you are using pre-built binaries, follow the instructions
*/
/*!
- \page requirements-s60.html
- \title Qt for S60 Requirements
+ \page requirements-symbian.html
+ \title Qt for Symbian platform Requirements
\ingroup installation
- \brief Setting up the S60 environment for Qt.
+ \brief Setting up the Symbian platform environment for Qt.
\previouspage General Qt Requirements
- Qt for S60 requires the following software installed on your development PC:
+ Qt for Symbian platform requires the following software installed on your development PC:
\list
\o \l{http://www.mingw.org/}{MinGW 3.4.5 or higher}, or another windows compiler to build the tools.
\o \l{http://www.forum.nokia.com/main/resources/tools_and_sdks/carbide_cpp/}{Carbide.c++ v2.0.0 or higher}
@@ -970,13 +972,13 @@ If you are using pre-built binaries, follow the instructions
\endlist
\o \l{http://www.forum.nokia.com/main/resources/tools_and_sdks/S60SDK/}{S60 Platform SDK 3rd Edition FP1 or higher}
\o \l{http://www.forum.nokia.com/main/resources/technologies/openc_cpp/}{Open C/C++ v1.6.0 or higher}.
- Install this to all S60 SDKs you plan to use Qt with.
+ Install this to all Symbian SDKs you plan to use Qt with.
\o Building Qt libraries requires \l{http://www.arm.com/products/DevTools/RVCT.html}{RVCT} 2.2 [build 686] or later,
which is not available free of charge.
\endlist
Running Qt on real device requires the following packages to be installed on your device.
- The packages can be found in the S60 SDK where you installed Open C/C++:
+ The packages can be found in the Symbian SDK where you installed Open C/C++:
\list
\o \c{nokia_plugin\openc\s60opencsis\pips_s60_<version>.sis}
\o \c{nokia_plugin\openc\s60opencsis\openc_ssl_s60_<version>.sis}
diff --git a/doc/src/getting-started/known-issues.qdoc b/doc/src/getting-started/known-issues.qdoc
index 6f8eb66..0b63423 100644
--- a/doc/src/getting-started/known-issues.qdoc
+++ b/doc/src/getting-started/known-issues.qdoc
@@ -45,52 +45,23 @@
\ingroup platform-specific
\brief A summary of known issues in Qt %VERSION% at the time of release.
- An up-to-date list of known issues with Qt %VERSION% can be found via the
- \l{Task Tracker} on the Qt website which provides additional information
- about known issues and tasks related to Qt.
+ This page documents known problems with the packaging and installation in
+ Qt %VERSION%, as well as issues with third party software that we have
+ not been able to work around. For a list of such issues in previous Qt
+ versions refer to this page in the respective documentation.
- \section1 General Issues
+ For a list list of known bugs in Qt %VERSION%, see the \l{Task Tracker}
+ on the Qt website.
- When running Qt applications on Windows or with \c{-graphicssystem raster},
- any process that triggers a QWidget::update() from within a destructor
- might result in a crash.
+ An overview of known issues may also be found at:
+ \l{http://qt.gitorious.org/qt/pages/Qt460BetaKnownIssues}
+ {Known Issues Wiki}.
+ \section1 Installation Issues
- \section1 Issues with Third Party Software
-
- \section2 X11 Hardware Support
-
- \list
- \o There is a bug in the 169.xx NVIDIA drivers on certain GeForce 8 series
- cards that is triggered by the OpenGL paint engine when using QPainter
- on a QGLWidget to draw paths and polygons. Some other painting
- operations that end up in the path fallback are affected as well. The
- bug causes the whole X server to repeatedly hang for several seconds at
- a time.
- \o There is an issue with NVIDIA's 9xxx driver series on X11 that causes a
- crash in cases where there are several \l{QGLContext}s and the extended
- composition modes are used (the composition modes between and including
- QPainter::CompositionMode_Multiply and
- QPainter::CompositionMode_Exclusion). This affects the composition mode
- demo in Qt 4.5, for example. The crash does not occur in newer versions
- of the drivers.
- \endlist
-
- \section2 Windows Hardware Support
-
- \list
- \o When using version 6.14.11.6921 of the NVIDIA drivers for the GeForce
- 6600 GT under Windows XP, Qt applications which use drag and drop will
- display reduced size drag and drop icons when run alongside
- applications that use OpenGL. This problem can be worked around by
- reducing the level of graphics acceleration provided by the driver, or
- by disabling hardware acceleration completely.
- \endlist
-
- \section2 Windows Software Issues
+ \section2 Building the Source Package on Windows 7
\list
-
\o When building Qt 4.5.0 with Windows 7, the build fails with an error
message regarding failing to embed manifest. This a known issue with
Windows 7, explained in the Windows 7 SDK Beta
@@ -116,12 +87,60 @@
}
\endcode
- \o Under certain circumstances Visual Studio Integration v1.4.0 will not
- be able to install the integration for Visual Studio 2005 on Windows
- Vista. An error message states that .NET Framework v2.0 Service Pack 1
- is not installed. This is due to a problem with the built-in
- installation of this on Windows Vista. This issue can be fixed by
- installing .NET Framework version 3.5.
+ \section2 Installing the Source Package on Unix systems
+
+ \o If you download a Zip source package, you will need to convert
+ Windows-style line endings (CR/LF) to Unix-style line-endings (LF) when
+ you uncompress the package. To do this, give the "-a" option when you
+ run the "unzip' command.
+
+ If you fail to supply the "-a" option when unzipping the package, you
+ will see the following error message when you attempt to execute the
+ configure command:
+ "bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory"
+ \endlist
+
+ \section2 Installing on Mac OS X 10.6 "Snow Leopard"
+ \list
+ \o Performing a new install of the Qt 4.6 beta on Snow Leopard
+ triggers a bug in the installer that causes the install to fail.
+ Updating an existing Qt installation works fine.
+
+ There are two workarounds, either disable spotlight for the target
+ drive during the install, or do a custom install where you deselect
+ documentation and examples. Run the installer again as a full
+ install to get the documentation and examples installed.
+ \endlist
+
+ \section1 Issues with Third Party Software
+
+ \section2 X11
+
+ \list
+ \o There is a bug in the 169.xx NVIDIA drivers on certain GeForce 8 series
+ cards that is triggered by the OpenGL paint engine when using QPainter
+ on a QGLWidget to draw paths and polygons. Some other painting
+ operations that end up in the path fallback are affected as well. The
+ bug causes the whole X server to repeatedly hang for several seconds at
+ a time.
+ \o There is an issue with NVIDIA's 9xxx driver series on X11 that causes a
+ crash in cases where there are several \l{QGLContext}s and the extended
+ composition modes are used (the composition modes between and including
+ QPainter::CompositionMode_Multiply and
+ QPainter::CompositionMode_Exclusion). This affects the composition mode
+ demo in Qt 4.5, for example. The crash does not occur in newer versions
+ of the drivers.
+ \endlist
+
+ \section2 Windows
+
+ \list
+ \o When using version 6.14.11.6921 of the NVIDIA drivers for the GeForce
+ 6600 GT under Windows XP, Qt applications which use drag and drop will
+ display reduced size drag and drop icons when run alongside
+ applications that use OpenGL. This problem can be worked around by
+ reducing the level of graphics acceleration provided by the driver, or
+ by disabling hardware acceleration completely.
\o With NVIDIA GeForce 7950 GT (driver version 6.14.11.7824), a fullscreen
QGLWidget flickers when child widgets are shown/hidden. The workaround
@@ -133,42 +152,11 @@
\endlist
-
- \section2 Mac OS X Software Support
+ \section2 Mac OS X
\list
\o If a sheet is opened for a given window, clicking the title bar of that
window will cause it to flash. This behavior has been reported to Apple
(bug number 5827676).
\endlist
-
-
- \section2 Installing source packages on Unix systems
-
- \list
- \o If you download a Zip source package, you will need to convert
- Windows-style line endings (CR/LF) to Unix-style line-endings (LF) when
- you uncompress the package. To do this, give the "-a" option when you
- run the "unzip' command.
-
- If you fail to supply the "-a" option when unzipping the package, you
- will see the following error message when you attempt to execute the
- configure command:
- "bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory"
- \endlist
-
-
- \section2 Running evaluation packages on Windows XP
-
- \list
- \o If running the qt-win-eval-%VERSION%-vs2008.exe package on a Windows XP
- system, you may encounter the following error message:
- "The application failed to start because the application configuration
- is incorrect. Reinstalling the application may fix this problem.".
-
- This error occurs because the version of the CRT component on the
- system is incorrect. Visual Studio 2008 requires CRT90 while Windows
- XP comes with CRT80. To solve this problem, please install the 2008 CRT
- redistributable package from Microsoft.
- \endlist
*/
diff --git a/doc/src/howtos/appicon.qdoc b/doc/src/howtos/appicon.qdoc
index ece2dcf..4108c11 100644
--- a/doc/src/howtos/appicon.qdoc
+++ b/doc/src/howtos/appicon.qdoc
@@ -213,9 +213,9 @@
The GNOME developer website is at \l{http://developer.gnome.org/}.
- \section1 Setting the Application Icon on S60 platforms
+ \section1 Setting the Application Icon on the Symbian platform
- In order to set the application icon for S60 applications, you need
+ In order to set the application icon for Symbian platform applications, you need
an SVG-T icon. For information on how to create SVG-T compliant icons,
please refer to
\l{http://wiki.forum.nokia.com/index.php/How_to_create_application_icon(SVG)_in_S60_3rd_edition/}
diff --git a/doc/src/exceptionsafety.qdoc b/doc/src/howtos/exceptionsafety.qdoc
index b70df6b..fa1427b 100644
--- a/doc/src/exceptionsafety.qdoc
+++ b/doc/src/howtos/exceptionsafety.qdoc
@@ -42,7 +42,7 @@
/*!
\page exceptionsafety.html
\title Exception Safety
- \ingroup architecture
+ \ingroup best-practices
\brief A guide to exception safety in Qt.
\bold {Preliminary warning}: Exception safety is not feature complete!
@@ -144,12 +144,12 @@
\section1 Platform-Specific Exception Handling
- \section2 Symbian (Qt for S60)
+ \section2 The Symbian platform
The Symbian platform implements its own exception system that differs from the standard
- C++ mechanism. When using Qt for S60, and especially when writing code to access Symbian
- functionality directly, it may be necessary to know about the underlying implementation
- and how it interacts with Qt.
+ C++ mechanism. When using Qt for Symbian platform, and especially when writing code to
+ access Symbian functionality directly, it may be necessary to know about the underlying
+ implementation and how it interacts with Qt.
The \l{Exception Safety with Symbian} document shows how to use the facilities provided
by Qt to use exceptions as safely as possible.
diff --git a/doc/src/images/gradient.png b/doc/src/images/gradient.png
new file mode 100644
index 0000000..2ef36ed
--- /dev/null
+++ b/doc/src/images/gradient.png
Binary files differ
diff --git a/doc/src/images/graphicseffect-bloom.png b/doc/src/images/graphicseffect-bloom.png
new file mode 100644
index 0000000..dace7eb
--- /dev/null
+++ b/doc/src/images/graphicseffect-bloom.png
Binary files differ
diff --git a/doc/src/images/graphicseffect-effects.png b/doc/src/images/graphicseffect-effects.png
index 3709014..609bef9 100644
--- a/doc/src/images/graphicseffect-effects.png
+++ b/doc/src/images/graphicseffect-effects.png
Binary files differ
diff --git a/doc/src/images/graphicseffect-plain.png b/doc/src/images/graphicseffect-plain.png
new file mode 100644
index 0000000..8b4c1c4
--- /dev/null
+++ b/doc/src/images/graphicseffect-plain.png
Binary files differ
diff --git a/doc/src/images/pbuffers-example.png b/doc/src/images/pbuffers-example.png
index bafb05a..c34a6fd 100644
--- a/doc/src/images/pbuffers-example.png
+++ b/doc/src/images/pbuffers-example.png
Binary files differ
diff --git a/doc/src/images/qt-colors.png b/doc/src/images/qt-colors.png
index 524123f..331c975 100644
--- a/doc/src/images/qt-colors.png
+++ b/doc/src/images/qt-colors.png
Binary files differ
diff --git a/doc/src/images/qt-embedded-architecture.png b/doc/src/images/qt-embedded-architecture.png
index d3f8edc..20b3e7f 100644
--- a/doc/src/images/qt-embedded-architecture.png
+++ b/doc/src/images/qt-embedded-architecture.png
Binary files differ
diff --git a/doc/src/images/shareddirmodel.png b/doc/src/images/shareddirmodel.png
index 6daa9d3..7b9fded 100644
--- a/doc/src/images/shareddirmodel.png
+++ b/doc/src/images/shareddirmodel.png
Binary files differ
diff --git a/doc/src/images/standard-views.png b/doc/src/images/standard-views.png
index 836ae36..c804551 100644
--- a/doc/src/images/standard-views.png
+++ b/doc/src/images/standard-views.png
Binary files differ
diff --git a/doc/src/images/xml-schema.png b/doc/src/images/xml-schema.png
new file mode 100644
index 0000000..b1bcecc
--- /dev/null
+++ b/doc/src/images/xml-schema.png
Binary files differ
diff --git a/doc/src/index.qdoc b/doc/src/index.qdoc
index ed4bbbe..f376af2 100644
--- a/doc/src/index.qdoc
+++ b/doc/src/index.qdoc
@@ -79,15 +79,15 @@
</td>
</tr>
<tr>
- <th class="largeheader">
+ <th class="titleheader">
Fundamentals</th>
- <th class="largeheader">
+ <th class="titleheader">
User Interface Design</th>
- <th class="largeheader">
+ <th class="titleheader">
Technologies</th>
</tr>
<tr>
- <td valign="top" class="largeindex">
+ <td valign="top">
<ul>
<li><a href="object.html">The Qt Object Model</a></li>
<li><a href="eventsandfilters.html">Event System</a></li>
@@ -96,7 +96,7 @@
<li><a href="platform-specific.html">Platform Specifics</a></li>
</ul>
</td>
- <td valign="top" class="largeindex">
+ <td valign="top">
<ul>
<li><a href="widgets-and-layouts.html">Widgets and Layouts</a></li>
<li><a href="application-windows.html">Application Windows</a></li>
@@ -105,7 +105,7 @@
<li><a href="webintegration.html">Integrating Web Content</a></li>
</ul>
</td>
- <td valign="top" class="largeindex">
+ <td valign="top">
<ul>
<li><a href="io.html">Input/Output</a> and <a href="resources.html">Resources</a></li>
<li><a href="network-programming.html">Network Programming</a></li>
diff --git a/doc/src/internationalization/i18n.qdoc b/doc/src/internationalization/i18n.qdoc
index 121c822..e873f4e 100644
--- a/doc/src/internationalization/i18n.qdoc
+++ b/doc/src/internationalization/i18n.qdoc
@@ -42,6 +42,9 @@
/*!
\group i18n
\title Qt Classes for Internationalization
+
+ See \l{Internationalization with Qt} for information on how to use these classes
+ in your applications.
*/
/*!
diff --git a/doc/src/platforms/compiler-notes.qdoc b/doc/src/platforms/compiler-notes.qdoc
index 5b5240a..4577bf0 100644
--- a/doc/src/platforms/compiler-notes.qdoc
+++ b/doc/src/platforms/compiler-notes.qdoc
@@ -204,10 +204,22 @@
\section2 Sun Studio
- Qt is tested using Sun Studio 8 (Sun CC 5.5). Go to
+ Qt is tested using Sun Studio 12 (Sun CC 5.9). Go to
\l{Sun Studio Patches} page on Sun's Web site to download
the latest patches for your Sun compiler.
+ Please note that Qt 4.6 is stricter in its STL requirements and
+ that the default STL implementation used by Sun CC does not pass
+ those requirements. This does not affect binary compatibility and
+ you can continue to use STL in your own code, but Qt's
+ STL-compatibility functions will be disabled.
+
+ Sun CC ships with a secondary STL implementation (called stlport4)
+ which is standards-compliant and can be used by Qt. You can enable
+ it by passing the -library=stlport4 option to the compiler. Note
+ that this does not affect Qt's binary compatibility, but it may
+ affect that of other libraries and programs that use STL.
+
\section2 Sun WorkShop 5.0
Sun WorkShop 5.0 is not supported with Qt 4.
diff --git a/doc/src/platforms/emb-opengl.qdoc b/doc/src/platforms/emb-opengl.qdoc
index fea09bb..2ed5d04 100644
--- a/doc/src/platforms/emb-opengl.qdoc
+++ b/doc/src/platforms/emb-opengl.qdoc
@@ -57,20 +57,20 @@ of the \l {http://www.opengl.org}{OpenGL} standard.
Because it is meant for use in embedded systems, it has a smaller,
more constrained API.
-For reference, Nokia provides a plugin which integrates \l
-{http://www.khronos.org/opengles}{OpenGL ES} with Qt for Embedded Linux,
-but Qt for Embedded Linux can be adapted to a wide range of OpenGL
-versions.
+For reference, Nokia provides support for integrating \l
+{http://www.khronos.org/opengles}{OpenGL ES} with Qt for Embedded Linux
+for drawing into a QGLWidget.
-There are three ways to use OpenGL with Qt for Embedded Linux:
-\list
- \o Perform OpenGL 3D graphics operations in applications;
- \o Accelerate normal 2D painting operations;
- \o Implement window compositing and special effects.
-\endlist
+The current implementation supports OpenGL and 2D painting within a
+QGLWidget. Using OpenGL to accelerate regular widgets and compositing
+top-level windows with OpenGL are not currently supported. These issues
+will be addressed in future versions of Qt.
-Qt for Embedded Linux is shipped with a reference integration example
-that demonstrates all three uses.
+It is recommended that Qt for Embedded Linux is configured with the
+\c{-DQT_QWS_CLIENTBLIT} and \c{-DQT_NO_QWS_CURSOR} options for optimum
+performance. OpenGL is rendered direct to the screen and these options
+prevent Qt for Embedded Linux from trying to do its own non-OpenGL
+compositing on the QGLWidget contents.
\section2 Using OpenGL 3D Graphics in Applications
@@ -82,146 +82,149 @@ To use OpenGL-enabled widgets in a Qt for Embedded Linux application,
all that is required is to subclass the QGLWidget and draw into instances of
the subclass with standard OpenGL functions.
+Note that on most embedded hardware, the OpenGL implementation is
+actually \l{http://www.khronos.org/opengles/1_X/}{OpenGL/ES 1.1} or
+\l{http://www.khronos.org/opengles/2_X/}{OpenGL/ES 2.0}. When painting
+within a QGLWidget::paintGL() override, it is necessary to limit the
+application to only the features that are present in the OpenGL/ES
+implementation.
+
\section2 Using OpenGL to Accelerate Normal 2D Painting
-Qt provides QOpenGLPaintEngine, a subclass of QPaintEngine that
-translates QPainter operations into OpenGL calls. This specialized
-paint engine can be used to improve 2D rendering performance on
-appropriate hardware. It can also overlay controls and decorations
-onto 3D scenes drawn using OpenGL.
+Qt provides a subclass of QPaintEngine that translates QPainter operations
+into OpenGL calls (there are actually two subclasses, one for OpenGL/ES 1.1
+and another for OpenGL/ES 2.0). This specialized paint engine can be used
+to improve 2D rendering performance on appropriate hardware. It can also
+overlay controls and decorations onto 3D scenes drawn using OpenGL.
+
+As mentioned above, the OpenGL paint engine is not currently supported
+in regular widgets. However, any application that uses QGraphicsView
+can set a QGLWidget as the viewport and obtain access to the
+OpenGL paint engine that way:
+
+\code
+QGraphicsView view(&scene);
+view.setViewport(new QGLWidget);
+view.setViewportUpdateMode(QGraphicsView::FullViewportUpdate);
+view.showFullScreen();
+\endcode
+
+It is recommended that the QGraphicsView::FullViewportUpdate flag
+be set because the default double-buffered behavior of QGLWidget
+does not support partial updates. It is also recommended that the
+window be shown full-screen because that usually has the best
+performance on current OpenGL/ES implementations.
+
+Once a QGraphicsView has been initialized as above, regular widgets
+can be added to the canvas using QGraphicsProxyWidget if the
+application requires them.
\section2 Using OpenGL to Implement Window Compositing and Effects
-Qt for Embedded Linux includes a complete windowing system, which implements
-real transparency. The windowing system can be accelerated using
-OpenGL to implement top level window compositing. This makes it easy
-to add 3D effects to applications, for instance when windows are
-minimized or maximized.
-
-\section1 Acceleration Architecture
-
-The diagram below shows the Qt for Embedded Linux painting architecture.
-
-\image qt-embedded-opengl3.png
-
-A client process widget uses a paint engine to draw into a window
-surface. The server then combines the window surfaces and displays the
-composition on the screen. This architecture lets you
-control the steps of the painting process by subclassing.
-
-Subclassing QPaintEngine allows you to implement the QPainter API
-using accelerated hardware. Subclassing QWindowSurface lets you
-decide the properties of the space your widgets will draw themselves
-into, as well as which paint engine they should use to draw themselves
-into that space. Subclassing QScreen lets you control the creation of
-window surfaces and lets you decide how to implement window
-compositing. Using subclassing, your implementation work is minimized
-since you can reuse base class functionality you don't need to change.
+Compositing effects can be simulated by adjusting the opacity and
+other parameters of the items within a QGraphicsView canvas on a
+QGLWidget viewport.
-The elements of an accelerated Qt for Embedded Linux system are shown in the
-diagram below.
+While Qt for Embedded Linux does include a complete windowing system,
+using OpenGL to composite regular window surfaces can be quite difficult.
+Most of Qt for Embedded Linux assumes that the window surface is a plain
+raster memory buffer, with QGLWidget being the sole exception.
+The need to constantly re-upload the raster memory buffers into OpenGL
+textures for compositing can have a significant impact on performance,
+which is why we do not recommend implementing that form of compositing.
+We intend to address this problem in future versions of Qt.
-\image qt-embedded-opengl1.png
+\section1 Integrating OpenGL/ES into Qt for Embedded Linux
-The applications, using the Qt API, do not depend on the presence of
-the acceleration plugin. The plugin uses the graphics hardware to
-accelerate painting primitives. Any operations not accelerated by the
-plugin are done in software by the software paint engine.
+\section2 Reference Integration
-To integrate an OpenGL implementation into Qt for Embedded Linux for a
-particular platform, you use the same mechanisms you would use for
-writing any other accelerated driver. Base classes, e.g., QGLScreen
-and QWSGLWindowSurface, are provided to minimize the need for
-reimplementing common functionality.
+The reference integration for OpenGL into Qt for Embedded Linux
+is for the PowerVR chipset from \l{http://www.imgtec.com/}{Imagination
+Technologies}. It consists of two components: \c{pvreglscreen} which
+provides the Qt for Embedded Linux screen driver, and \c{QWSWSEGL}
+which implements a plug-in to the PowerVR EGL implementation to
+implement low-level OpenGL drawing surfaces.
-\section1 The Reference Integration
+\section2 Integrating Other Chipsets
-The \l{OpenGL for Embedded Systems Example} is the reference implementation
-for integrating OpenGL ES and \l{http://www.khronos.org/egl/}{EGL} with
-the graphics acceleration architecture of Qt for Embedded Linux.
-(\l{http://www.khronos.org/egl/}{EGL} is a library that binds OpenGL ES to
-native windowing systems.)
+In this section we discuss the essential features of the reference
+integration that need to be provided for any other chipset integration.
-The diagram below shows how OpenGL ES is used within the acceleration architecture:
+The QtOpenGL module assumes that a QGLWidget can be represented
+by a \c EGLNativeWindowType value in some underlying window system
+implementation, and that \c{eglSwapBuffers()} is sufficient to copy
+the contents of the native window to the screen when requested.
-\image qt-embedded-opengl2.png
+However, many EGL implementations do not have a pre-existing window system.
+Usually only a single full-screen window is provided, and everything else
+must be simulated some other way. This can be a problem because
+of QtOpenGL's assumptions. We intend to address these assumptions in a
+future version of Qt, but for now it is the responsibility of the integrator
+to provide a rudimentary window system within the EGL implementation.
+This is the purpose of \c{QWSWSEGL} in the reference integration.
-The example implements a screen driver plugin that demonstrates all
-three uses of OpenGL in Qt for Embedded Linux: 2D graphics acceleration, 3D
-graphics operations using the \l {QtOpenGL module}, and top-level
-window compositing and special effects. The applications still do
-not talk directly to the accelerated plugin.
+If it isn't possible for the EGL implementation to provide a rudimentary
+window system, then full-screen windows using QGLWidget can be supported,
+but very little else.
-For 2D graphics, applications use the normal Qt painting API. The example accelerates 2D
-painting by using the QOpenGLPaintEngine, which is included in the \l {QtOpenGL module}.
+The screen driver needs to inherit from QGLScreen and perform the
+following operations in its constructor:
-For 3D graphics applications use the OpenGL API directly, together with the functionality
-in the Qt OpenGL support classes. The example supports this by creating a
-QWSGLWindowSurface whenever a QGLWidget is instantiated.
+\snippet src/plugins/gfxdrivers/powervr/pvreglscreen/pvreglscreen.cpp 0
-All access to the display is done through OpenGL. The example subclasses
-QWSGLWindowSurface implementation and uses the \l
-{http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt}
-{OpenGL Framebuffer Object extension} to draw windows into an offscreen buffer. This
-lets the example use OpenGL to implement top level window compositing of opaque and
-semi-transparent windows, and to provide a 3D animated transition effect as each new
-window is shown.
+The \c{setSurfaceFunctions()} call supplies an object that takes care
+of converting Qt paint devices such as widgets and pixmaps into
+\c EGLNativeWindowType and \c EGLNativePixmapType values. Here we
+only support native windows. Because OpenGL rendering is direct to
+the screen, we also indicate that client blit is supported.
-The specific OpenGL library being used by the example restricts all
-OpenGL operations to occur in a single process. Hence the example
-creates instances of QWSGLWindowSurface only in the server process.
-Other processes then perform 2D graphics by creating instances
-of the standard QWindowSurface classes for client processes. The
-standard window surface performs software-based rendering into a
-shared memory segment. The server then transfers the contents of this
-shared memory into an OpenGL texture before they are drawn onto the
-screen during window compositing.
+Next, we override the \c{createSurface()} functions in QGLScreen:
-\omit
+\snippet src/plugins/gfxdrivers/powervr/pvreglscreen/pvreglscreen.cpp 1
-\section1 Future Directions
+Even if Qt for Embedded Linux is used in single-process mode, it is
+necessary to create both client-side and server-side versions of the
+window surface. In our case, the server-side is just a stub because
+the client side directly renders to the screen.
-\section2 API Improvements
+Note that we only create a \c{PvrEglWindowSurface} if the widget is a
+QGLWidget. All other widgets use the normal raster processing.
+It can be tempting to make \c{createSurface()} create an OpenGL
+window surface for other widget types as well. This has not been
+extensively tested and we do not recommend its use at this time.
-Nokia is now working on enhancing the API for integrating OpenGL
-with Qt for Embedded Linux. The current design plan includes the following
-features:
+The other main piece is the creation of the \c EGLNativeWindowType
+value for the widget. This is done in the \c{createNativeWindow()}
+override:
-\list
+\snippet src/plugins/gfxdrivers/powervr/pvreglscreen/pvreglscreen.cpp 2
- \o Provide convenience classes, e.g., QEGLScreen and
- QWSEGLWindowSurface, which implement common uses of the EGL
- API. These classes will simplify implementing an OpenGL ES
- integration.
+The details of what needs to be placed in this function will vary
+from chipset to chipset. The simplest is to return the native window
+handle corresponding to the "root" full-screen window:
- \o Extend the screen driver API to provide more control over window
- properties and animations, and provide a software-based integration
- to enable testing on the desktop.
+\code
+*native = rootWindowHandle;
+return true;
+\endcode
- \o Improve performance as opportunities arise.
+The most common value for \c rootWindowHandle is zero, but this may
+not always be the case. Consult the chipset documentation for the
+actual value to use. The important thing is that whatever value is
+returned must be suitable for passing to the \c{eglCreateWindowSurface()}
+function of the chipset's EGL implementation.
-\endlist
+In the case of PowerVR, the rudimentary window system in \c{QWSWSEGL}
+provides a \c PvrQwsDrawable object to represent the \c EGLNativeWindowType
+value for the widget.
-\section2 OpenVG Support
+\section1 OpenVG Support
\l {http://www.khronos.org/openvg} {OpenVG} is a dedicated API for 2D
graphics on mobile devices. It is therefore more likely to be a better
-alternative for 2D acceleration than OpenGL. Until recently, no
-OpenVG-capable hardware has been available, so Nokia has not yet
-included an OpenVG solution in Qt for Embedded Linux.
-
-However, Nokia has done a feasibility study, implementing an
-OpenVG paint engine on top of a software OpenVG implementation.
-Assuming availability of the appropriate hardware, this OpenVG paint
-engine can easily be completed and integrated using the existing
-acceleration architecture. Since OpenVG shares the same EGL layer as
-OpenGL ES, the work already done on the OpenGL integration can be
-reused.
-
-Related technologies included in the \l
-{http://www.khronos.org/openkode} {OpenKODE} API set will also be
-considered.
-
-\endomit
+alternative for 2D acceleration than OpenGL/ES. Acceleration of
+regular widgets is supported with OpenVG, unlike with OpenGL/ES.
+See \l{OpenVG Rendering in Qt} for more information on the
+OpenVG support in Qt.
*/
diff --git a/doc/src/platforms/platform-notes.qdoc b/doc/src/platforms/platform-notes.qdoc
index 5be66f8..9896b08 100644
--- a/doc/src/platforms/platform-notes.qdoc
+++ b/doc/src/platforms/platform-notes.qdoc
@@ -67,6 +67,8 @@
\tableofcontents{1 Platform Notes - Windows}
\o \l{Platform Notes - Mac OS X}
\tableofcontents{1 Platform Notes - Mac OS X}
+ \o \l{Platform Notes - Symbian}
+ \tableofcontents{1 Platform Notes - Symbian}
\o \l{Platform Notes - Embedded Linux}
\tableofcontents{1 Platform Notes - Embedded Linux}
\o \l{Platform Notes - Windows CE}
@@ -409,7 +411,7 @@
to run on. More information about the combinations of platforms and compilers
supported by Qt can be found on the \l{Supported Platforms} page.
- For information about mixing exceptions with symbian leaves,
+ For information about mixing exceptions with Symbian leaves,
see \l{Exception Safety with Symbian}
\section1 Multimedia and Phonon Support
diff --git a/doc/src/platforms/qt-embedded.qdoc b/doc/src/platforms/qt-embedded.qdoc
index 0b2c2ac..c39a967 100644
--- a/doc/src/platforms/qt-embedded.qdoc
+++ b/doc/src/platforms/qt-embedded.qdoc
@@ -54,7 +54,7 @@
Currently, three embedded platforms are supported by Qt:
\table 90%
- \header \o Embedded Linux \o Windows CE \o S60
+ \header \o Embedded Linux \o Windows CE \o Symbian platform
\row
\o \l{Qt for Embedded Linux} is designed to be used on Linux devices
without X11 or existing graphical environments. This flavor of
@@ -67,8 +67,9 @@
Applications use the appropriate style for the embedded
environment and use native features, such as menus, to conform
to the native style guidelines.
- \o \l{S60 - Introduction to using Qt}{Qt for S60} is used to create
- applications running in existing S60 environments.
+ \o \l{Symbian platform - Introduction to using Qt}{Qt for the Symbian
+platform} is used to create
+ applications running in existing Symbian platform environments.
Applications use the appropriate style for the embedded
environment and use native features, such as menus, to conform
to the native style guidelines.
diff --git a/doc/src/s60-introduction.qdoc b/doc/src/platforms/s60-introduction.qdoc
index d0a1976..5fd0cbe 100644
--- a/doc/src/s60-introduction.qdoc
+++ b/doc/src/platforms/s60-introduction.qdoc
@@ -40,35 +40,36 @@
****************************************************************************/
/*!
- \page s60-with-qt-introduction.html
+ \page symbian-with-qt-introduction.html
- \title S60 - Introduction to using Qt
- \brief An introduction to Qt for S60 developers.
+ \title Symbian platform - Introduction to using Qt
+ \brief An introduction to Qt for Symbian platform developers.
\ingroup howto
\ingroup qts60
\tableofcontents
\section1 Required tools
-
- See \l{Qt for S60 Requirements} to see what tools are required to use Qt for S60.
+
+ See \l{Qt for Symbian platform Requirements} to see what tools are
+ required to use Qt for Symbian platform.
\section1 Installing Qt and running demos
-
- Follow the instructions found in \l{Installing Qt on S60 using binary package} to learn how
+
+ Follow the instructions found in \l{Installing Qt on the Symbian platform using binary package} to learn how
to install Qt using binary package and how to build and run Qt demos.
- Follow the instructions found in \l{Installing Qt on S60} to learn how to install Qt using
+ Follow the instructions found in \l{Installing Qt on the Symbian platform} to learn how to install Qt using
using source package and how to build and run the Qt demos.
\section1 Building your own applications
If you are new to Qt development, have a look at \l{How to Learn Qt}.
In general, the difference between developing a
- Qt application on S60 compared to any of the other platforms supported
+ Qt application on the Symbian platform compared to any of the other platforms supported
by Qt is not that big.
- Once you have crated a \c .pro file for your project, generate the
+ Once you have created a \c .pro file for your project, generate the
Carbide specific \c Bld.inf and \c .mmp files this way:
\snippet doc/src/snippets/code/doc_src_s60-introduction.qdoc 0
@@ -76,10 +77,10 @@
For more information on how to use qmake have a look at the \l
{qmake Tutorial}.
- Now you can build the Qt on S60 application with standard build
- tools. By default, running \c make will produce binaries for the
- emulator. However, S60 comes with several alternative build targets,
- as shown in the table below:
+ Now you can build the Qt for the Symbian platform application with
+ standard build tools. By default, running \c make will produce binaries for
+ the emulator. However, the Symbian platform comes with several alternative
+ build targets, as shown in the table below:
\table
\row \o \c debug-winscw \o Build debug binaries for the emulator (default).
@@ -110,19 +111,19 @@
target. For example, the following sequence will generate the needed makefiles,
build the project for \c debug-winscw and \c release-armv5, and create
self-signed \c .sis file for \c release-armv5 target:
-
+
\snippet doc/src/snippets/code/doc_src_s60-introduction.qdoc 2
If you want to use different certificate information or override the default
target for \c .sis file creation you can use the environment variables as
shown in the table below:
-
+
\table
\row \o \c QT_SIS_OPTIONS \o Options accepted by \c .sis creation.
-i, install the package right away using PC suite.
-c=<file>, read certificate information from a file.
- Execute \c{perl createpackage.pl} for more information
- about options.
+ Execute the \c{createpackage.pl} script without any
+ parameters for more information about options.
By default no otions are given.
\row \o \c QT_SIS_TARGET \o Target for which \c .sis file is created.
Accepted values are build targets listed in
@@ -134,15 +135,15 @@
\row \o \c QT_SIS_PASSPHRASE \o The certificate's private key file's passphrase.
By default empty.
\endtable
-
+
For example:
-
+
\snippet doc/src/snippets/code/doc_src_s60-introduction.qdoc 4
The environment variables for \c make can also be given as parameters:
-
+
\snippet doc/src/snippets/code/doc_src_s60-introduction.qdoc 3
-
+
If you want to install the program immediately, make sure that the device
is connected to the computer in "PC Suite" mode, and run \c sis target
with the \c QT_SIS_OPTIONS=-i, like this:
diff --git a/doc/src/platforms/supported-platforms.qdoc b/doc/src/platforms/supported-platforms.qdoc
index 5f72ce3..4c3929a 100644
--- a/doc/src/platforms/supported-platforms.qdoc
+++ b/doc/src/platforms/supported-platforms.qdoc
@@ -78,7 +78,7 @@
\row \o Linux (32 and 64-bit)
\o gcc 4.2
\row \o Microsoft Windows XP
- \o gcc 3.4.2 (MinGW) (32-bit), MSVC 2003, 2005 (32 and 64-bit)
+ \o gcc 4.4 (MinGW) (32-bit), MSVC 2003, 2005 (32 and 64-bit)
\row \o Microsoft Windows Vista
\o MSVC 2005, 2008
\row \o Microsoft Windows Vista 64bit
@@ -104,6 +104,8 @@
\table
\header \o Platform
\o Compilers
+ \row \o Windows XP, Vista
+ \o gcc 3.4.2 (MinGW)
\omit
\row \o Windows 7
\o MSVC 2008
@@ -126,6 +128,8 @@
\o Intel Compiler
\row \o Embedded Linux QWS (Mips, PowerPC)
\o gcc (\l{http:\\www.codesourcery.com}{Codesourcery version)}
+ \row \o Embedded Linux X11 (ARM)
+ \o gcc (\l{http://www.scratchbox.org/}{Scratchbox)}
\row \o Windows CE 6.0 (ARMv4i, x86, MIPS)
\o MSVC 2008 WinCE 6.0 Professional
\endtable
@@ -134,7 +138,14 @@
All platforms not specifically listed above are not supported by Nokia. Nokia does
not run its unit test suite or perform any other internal tests on platforms not
- listed above. Qt users should note, however, that there may be various open source
+ listed above.
+
+ Even though some Tier 3 platforms are available under the Qt Commercial License,
+ technical support is not included in that license.
+ However, \l{How to Order}{contact our sales team} to find out about the
+ availability of other services for those platforms.
+
+ Qt users should note, however, that there may be various open source
projects, community users and/or Qt partners who are able to provide assistance with
platforms not supported by Nokia.
diff --git a/doc/src/symbian-exceptionsafety.qdoc b/doc/src/platforms/symbian-exceptionsafety.qdoc
index 88f4d03..88f4d03 100644
--- a/doc/src/symbian-exceptionsafety.qdoc
+++ b/doc/src/platforms/symbian-exceptionsafety.qdoc
diff --git a/doc/src/porting/qt4-interview.qdoc b/doc/src/porting/qt4-interview.qdoc
index 29d9f5c..fd3fb36 100644
--- a/doc/src/porting/qt4-interview.qdoc
+++ b/doc/src/porting/qt4-interview.qdoc
@@ -109,8 +109,8 @@
\list
\o QStandardItemModel is a minimal convenience model that developers
can use to manage items of data.
- \o QDirModel provides directory information for use with QListView and
- QTreeView.
+ \o QFileSystemModel provides directory information for use with QListView
+ and QTreeView.
\o QStringListModel is a convenience model that can be used to hold
strings for views such as QListView and QComboBox.
\endlist
@@ -153,7 +153,7 @@
In this example, we display the contents of a model using two
different views, and share the user's selection between
- them. We will use the QDirModel supplied with Qt because it
+ them. We will use the QFileSystemModel supplied with Qt because it
requires very little configuration, and provides existing data to
the views.
@@ -174,7 +174,7 @@
\image interview-shareddirmodel.png
- The model/view architecture allows us to replace the QDirModel in
+ The model/view architecture allows us to replace the QFileSystemModel in
this example with a completely different model, one that will perhaps
obtain data from a remote server, or from a database.
diff --git a/doc/src/snippets/code/doc_src_examples_ahigl.qdoc b/doc/src/qt-resources.qdoc
index ccdce8b..3b31660 100644
--- a/doc/src/snippets/code/doc_src_examples_ahigl.qdoc
+++ b/doc/src/qt-resources.qdoc
@@ -39,11 +39,8 @@
**
****************************************************************************/
-//! [0]
-myApplication -qws -display ahigl
-//! [0]
-
-
-//! [1]
-myApplication -qws -display ahigl
-//! [1]
+/*!
+ \page qt-resources.html
+ \title Not Used
+ \image gradient.png
+*/
diff --git a/doc/src/qt-webpages.qdoc b/doc/src/qt-webpages.qdoc
index e02cd19..7287656 100644
--- a/doc/src/qt-webpages.qdoc
+++ b/doc/src/qt-webpages.qdoc
@@ -145,7 +145,7 @@
*/
/*!
- \externalpage http://qt.nokia.com/contact
+ \externalpage http://qt.nokia.com/about/contact-us
\title How to Order
*/
diff --git a/doc/src/qt4-intro.qdoc b/doc/src/qt4-intro.qdoc
index 03d9b29..cecff0e 100644
--- a/doc/src/qt4-intro.qdoc
+++ b/doc/src/qt4-intro.qdoc
@@ -464,6 +464,7 @@
previous releases in the Qt 4 series. This document covers the
most important features in this release, separated by category.
+\omit
A comprehensive list of changes between Qt 4.5 and Qt 4.6 is
included in the \c changes-4.6.0 file
\l{http://qt.nokia.com/developer/changes/changes-4.6.0}{available
@@ -473,6 +474,7 @@
Changes between this release and the previous release are provided
in the \c{changes-%VERSION%} file (also
\l{http://qt.nokia.com/developer/changes/changes-%VERSION%}{available online}).
+\endomit
A list of other Qt 4 features can be found on the \bold{\l{What's
New in Qt 4}} page.
@@ -481,6 +483,14 @@
\tableofcontents
+ \section1 Support for Symbian
+
+ Qt 4.6 is the first release to include support for the Symbian
+ platform, with integration into the S60 framework. The port to
+ Symbian and S60 provides all functionality required to develop
+ rich end-user applications for devices running S60 3.1 and
+ later.
+
\section1 Animation Framework
The animation framework helps build highly animated,
@@ -491,8 +501,9 @@
The framework makes it easy to animate \l{QObject}s, including
QWidgets, by allowing Qt properties to be animated. It also allows
creating custom animations and interpolation functions. Graphics
- views are not left out--one can animate \l{QGraphicsWidget}s,
- which inherits from QObject (and thereby enables properties).
+ views are not left out; one can animate \l{QGraphicsWidget}s and
+ new \l{QGraphicsObject}s which inherit from QGraphicsItem
+ (and thereby enable properties).
Animations are controlled using easing curves and can be grouped
together. This enables animations of arbitrary complexity.
@@ -508,6 +519,8 @@
The state machine framework is introduced in 4.6 and is described
below.
+ See \l{The Animation Framework} documentation for more information.
+
\section1 State Machine Framework
The state machine framework provides a robust state chart
@@ -534,24 +547,32 @@
the state machine, it is also easier to use the framework for
animating GUIs, for instance.
- \section1 Multi-touch & Gestures
+ See \l{The State Machine Framework} documentation for more infromation.
- The new multi-touch and gestures support enables user interaction
- with more than one finger, and combines sequential touch inputs to
- a 'gesture'.
+ \section1 Multi-Touch and Gestures
+
+ Support for multi-touch input enables users to interact with many
+ parts of a user interface at the same time, and provides the basis
+ for gestures. Additional infrastructure for gesture recognition
+ allows a sequence of touch inputs to be combined to create gestures
+ that can be used to activate features and trigger actions in an
+ application.
\image gestures.png
- The main benefits of this new functionality are:
+ This new functionality brings a number of benefits:
\list
- \o Allow users to interact with applications in better ways.
- \o Simplify finger-based interaction with UI components.
- \o Allowing common basic gestures and multi-touch
- gestures.
- \o Enable extensibility.
+ \o Allows users to interact with applications in more natural ways.
+ \o Simplifies finger-based interaction with UI components.
+ \o Combines support for common basic gestures and multi-touch gestures
+ in a single general framework.
+ \o Enables extensibility by design.
\endlist
+ See the QTouchEvent class documentation for more information on multi-touch
+ input and QGestureEvent for gestures.
+
\section1 DOM access API
Web pages and XML both have very complex document object models.
@@ -566,20 +587,7 @@
QList<QWebElement> introSpans = document.findAll("p.intro span");
\endcode
- \section1 Qt3D enablers
-
- As more of Qt, and more of the applications built on Qt go 3D,
- API's should be provided to simplify this. Mainly, the new API
- aims to make it more easy to create 3D applications with OpenGL.
- It will also unify the Qt OpenGL codebase, and enable
- cross-platform 3D codebase.
-
- The main features of the Qt3D enablers are currently: Math
- primitives for matrix multiplication, vectors, quaternions
- (client-side), and API for vertex and fragment shaders, GLSL/ES.
- Future research will, among other things include stencils,
- scissors, vertex buffers and arrays, texture manipulation, and
- geometry shaders.
+ See the QWebElement class documentation for more information.
\section1 Performance Optimizations
@@ -592,10 +600,59 @@
\o Reduced overhead in QNetworkAccessManager.
\o Added the QContiguousCache class, which provides efficient caching of
contiguous data.
+ \o Added support for hardware-accelerated rendering through
+ \l{OpenVG Rendering in Qt}{OpenVG}
\o Removed Win9x support.
\endlist
- \section1 Multimedia Audio Services
+ \section1 Graphics Effects
+
+ Effects can be used to alter the appearance of UI elements such as
+ \l{QGraphicsItem}s and \l{QWidget}s. A range of standard effects such
+ as blurring, colorizing or blooming is provided, and it is possible to
+ implement custom effects.
+
+ \table
+ \row
+ \o
+ \o \img graphicseffect-plain.png
+ \o
+ \row
+ \o \img graphicseffect-blur.png
+ \o \img graphicseffect-colorize.png
+ \o \img graphicseffect-bloom.png
+ \endtable
+
+ See the QGraphicsEffect class documentation for more information.
+
+ \section1 XML Schema Validation
+
+ The QtXmlPatterns module can now be used to validate schemas, either
+ through C++ APIs in the Qt application, or using the xmlpatternsvalidator
+ command line utility. The implementation of XML Schema Validation supports
+ the specification version 1.0 in large parts.
+
+ \img xml-schema.png
+
+ See the \l{XML Processing} and QXmlSchema class documentation for more
+ information.
+
+ \section1 Qt3D enablers
+
+ As more of Qt, and more of the applications built on Qt go 3D,
+ API's should be provided to simplify this. Mainly, the new API
+ aims to make it more easy to create 3D applications with OpenGL.
+ It will also unify the Qt OpenGL codebase, and enable
+ cross-platform 3D codebase.
+
+ The main features of the Qt3D enablers are currently: Math
+ primitives for matrix multiplication, vectors, quaternions
+ (client-side), and API for vertex and fragment shaders, GLSL/ES.
+ Future research will, among other things include stencils,
+ scissors, vertex buffers and arrays, texture manipulation, and
+ geometry shaders.
+
+ \section1 Multimedia Services
Qt 4.6 comes with new classes for handling audio. These classes
provide low-level access to the system's audio system. By
@@ -605,21 +662,14 @@
functions to query audio devices for which audio formats they
support.
- \section1 Classes and Functions Introduced in 4.6
-
- Links to class, function, and macro documentation.
-
- \section2 Classes
-
- Classes introduced in Qt 4.6.
-
- \sincelist classes
+ See the \l{QtMultimedia Module} documentation for more information.
- \section2 Functions & Macros
+ \section1 New Classes, Functions, Macros, etc
- Fuctions and macros introduced in Qt 4.6.
+ Links to new classes, functions, macros, and other items
+ introduced in Qt 4.6.
- \sincelist functions
+ \sincelist 4.6
*/
diff --git a/doc/src/snippets/colors/colors.pro b/doc/src/snippets/colors/colors.pro
new file mode 100644
index 0000000..b2cc87d
--- /dev/null
+++ b/doc/src/snippets/colors/colors.pro
@@ -0,0 +1,2 @@
+HEADERS = window.h
+SOURCES = main.cpp window.cpp
diff --git a/doc/src/snippets/colors/main.cpp b/doc/src/snippets/colors/main.cpp
new file mode 100644
index 0000000..4e09036
--- /dev/null
+++ b/doc/src/snippets/colors/main.cpp
@@ -0,0 +1,52 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** 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 Technology Preview License Agreement accompanying
+** this package.
+**
+** 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.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+#include <QtGui>
+#include "window.h"
+
+int main(int argc, char *argv[])
+{
+ QApplication app(argc, argv);
+ Window window;
+ window.setFixedSize(640, 215);
+ window.show();
+ return app.exec();
+}
diff --git a/doc/src/snippets/colors/window.cpp b/doc/src/snippets/colors/window.cpp
new file mode 100644
index 0000000..0cec5f5
--- /dev/null
+++ b/doc/src/snippets/colors/window.cpp
@@ -0,0 +1,131 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** 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 Technology Preview License Agreement accompanying
+** this package.
+**
+** 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.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+#include <QtGui>
+#include "window.h"
+
+Window::Window(QWidget *parent)
+ : QWidget(parent)
+{
+ QFont font;
+ font.setPixelSize(12);
+ setFont(font);
+}
+
+void Window::closeEvent(QCloseEvent *event)
+{
+ QPixmap pixmap(size());
+ render(&pixmap);
+ pixmap.save("qt-colors.png");
+
+ event->accept();
+}
+
+void Window::paintEvent(QPaintEvent *)
+{
+ QPainter painter;
+ painter.begin(this);
+
+ int h = 216 / 5;
+ QRect r = QRect(0, 0, 160, h);
+ painter.fillRect(r, Qt::white);
+ painter.setPen(Qt::black);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("white"));
+ r = QRect(0, h, 160, h);
+ painter.fillRect(r, Qt::red);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("red"));
+ r = QRect(0, h*2, 160, h);
+ painter.fillRect(r, Qt::green);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("green"));
+ r = QRect(0, h*3, 160, h);
+ painter.fillRect(r, Qt::blue);
+ painter.setPen(Qt::white);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("blue"));
+
+ r = QRect(160, 0, 160, h);
+ painter.fillRect(r, Qt::black);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("black"));
+ r = QRect(160, h, 160, h);
+ painter.fillRect(r, Qt::darkRed);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("darkRed"));
+ r = QRect(160, h*2, 160, h);
+ painter.fillRect(r, Qt::darkGreen);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("darkGreen"));
+ r = QRect(160, h*3, 160, h);
+ painter.fillRect(r, Qt::darkBlue);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("darkBlue"));
+
+ r = QRect(320, 0, 160, h);
+ painter.fillRect(r, Qt::cyan);
+ painter.setPen(Qt::black);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("cyan"));
+ r = QRect(320, h, 160, h);
+ painter.fillRect(r, Qt::magenta);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("magenta"));
+ r = QRect(320, h*2, 160, h);
+ painter.fillRect(r, Qt::yellow);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("yellow"));
+ r = QRect(320, h*3, 160, h);
+ painter.fillRect(r, Qt::gray);
+ painter.setPen(Qt::white);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("gray"));
+
+ r = QRect(480, 0, 160, h);
+ painter.fillRect(r, Qt::darkCyan);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("darkCyan"));
+ r = QRect(480, h, 160, h);
+ painter.fillRect(r, Qt::darkMagenta);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("darkMagenta"));
+ r = QRect(480, h*2, 160, h);
+ painter.fillRect(r, Qt::darkYellow);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("darkYellow"));
+ r = QRect(480, h*3, 160, h);
+ painter.fillRect(r, Qt::darkGray);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("darkGray"));
+
+ r = QRect(0, h*4, 640, h);
+ painter.fillRect(r, Qt::lightGray);
+ painter.setPen(Qt::black);
+ painter.drawText(r, Qt::AlignCenter, QLatin1String("lightGray"));
+
+ painter.end();
+}
+
diff --git a/doc/src/snippets/colors/window.h b/doc/src/snippets/colors/window.h
new file mode 100644
index 0000000..3b08b90
--- /dev/null
+++ b/doc/src/snippets/colors/window.h
@@ -0,0 +1,53 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** 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 Technology Preview License Agreement accompanying
+** this package.
+**
+** 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.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+#include <QWidget>
+
+class Window : public QWidget
+{
+public:
+ Window(QWidget *parent = 0);
+
+protected:
+ void closeEvent(QCloseEvent *event);
+ void paintEvent(QPaintEvent *event);
+};
+
diff --git a/doc/src/snippets/gestures/qgesture.cpp b/doc/src/snippets/gestures/qgesture.cpp
index 65f8b24..77f5cc2 100644
--- a/doc/src/snippets/gestures/qgesture.cpp
+++ b/doc/src/snippets/gestures/qgesture.cpp
@@ -64,7 +64,7 @@ private:
QGesture *gesture;
};
-/*!
+/*
\class QGesture
\since 4.6
@@ -100,7 +100,7 @@ private:
\sa QPanGesture
*/
-/*! \fn bool QGesture::filterEvent(QEvent *event)
+/* \fn bool QGesture::filterEvent(QEvent *event)
Parses input \a event and emits a signal when detects a gesture.
@@ -111,7 +111,7 @@ private:
This is a pure virtual function that needs to be implemented in subclasses.
*/
-/*! \fn void QGesture::started()
+/* \fn void QGesture::started()
The signal is emitted when the gesture is started. Extended information
about the gesture is contained in the signal sender object.
@@ -119,19 +119,19 @@ private:
In addition to started(), a triggered() signal should also be emitted.
*/
-/*! \fn void QGesture::triggered()
+/* \fn void QGesture::triggered()
The signal is emitted when the gesture is detected. Extended information
about the gesture is contained in the signal sender object.
*/
-/*! \fn void QGesture::finished()
+/* \fn void QGesture::finished()
The signal is emitted when the gesture is finished. Extended information
about the gesture is contained in the signal sender object.
*/
-/*! \fn void QGesture::cancelled()
+/* \fn void QGesture::cancelled()
The signal is emitted when the gesture is cancelled, for example the reset()
function is called while the gesture was in the process of emitting a
@@ -140,7 +140,7 @@ private:
*/
-/*!
+/*
Creates a new gesture handler object and marks it as a child of \a parent.
The \a parent object is also the default event source for the gesture,
@@ -156,7 +156,7 @@ QGesture::QGesture(QObject *parent)
parent->installEventFilter(this);
}
-/*! \internal
+/* \internal
*/
QGesture::QGesture(QGesturePrivate &dd, QObject *parent)
: QObject(dd, parent)
@@ -165,14 +165,14 @@ QGesture::QGesture(QGesturePrivate &dd, QObject *parent)
parent->installEventFilter(this);
}
-/*!
+/*
Destroys the gesture object.
*/
QGesture::~QGesture()
{
}
-/*! \internal
+/* \internal
*/
bool QGesture::eventFilter(QObject *receiver, QEvent *event)
{
@@ -182,13 +182,13 @@ bool QGesture::eventFilter(QObject *receiver, QEvent *event)
return filterEvent(event);
}
-/*!
+/*
\property QGesture::state
\brief The current state of the gesture.
*/
-/*!
+/*
Returns the gesture recognition state.
*/
Qt::GestureState QGesture::state() const
@@ -196,7 +196,7 @@ Qt::GestureState QGesture::state() const
return d_func()->state;
}
-/*!
+/*
Sets this gesture's recognition state to \a state and emits appropriate
signals.
@@ -237,7 +237,7 @@ void QGesture::updateState(Qt::GestureState state)
}
}
-/*!
+/*
Sets the \a graphicsItem the gesture is filtering events for.
The gesture will install an event filter to the \a graphicsItem and
@@ -257,7 +257,7 @@ void QGesture::setGraphicsItem(QGraphicsItem *graphicsItem)
graphicsItem->installSceneEventFilter(d->eventFilterProxyGraphicsItem);
}
-/*!
+/*
Returns the graphics item the gesture is filtering events for.
\sa setGraphicsItem()
@@ -267,7 +267,7 @@ QGraphicsItem* QGesture::graphicsItem() const
return d_func()->graphicsItem;
}
-/*! \fn void QGesture::reset()
+/* \fn void QGesture::reset()
Resets the internal state of the gesture. This function might be called by
the filterEvent() implementation in a derived class, or by the user to
diff --git a/doc/src/snippets/shareddirmodel/main.cpp b/doc/src/snippets/shareddirmodel/main.cpp
index 82034b5..3cb63c9 100644
--- a/doc/src/snippets/shareddirmodel/main.cpp
+++ b/doc/src/snippets/shareddirmodel/main.cpp
@@ -55,7 +55,8 @@ int main(int argc, char *argv[])
QSplitter *splitter = new QSplitter;
//! [2] //! [3]
- QDirModel *model = new QDirModel;
+ QFileSystemModel *model = new QFileSystemModel;
+ model->setRootPath(QDir::currentPath());
//! [0] //! [2] //! [4] //! [5]
QTreeView *tree = new QTreeView(splitter);
//! [3] //! [6]
@@ -74,7 +75,7 @@ int main(int argc, char *argv[])
list->setSelectionModel(selection);
//! [8]
- splitter->setWindowTitle("Two views onto the same directory model");
+ splitter->setWindowTitle("Two views onto the same file system model");
splitter->show();
return app.exec();
}
diff --git a/doc/src/snippets/simplemodel-use/main.cpp b/doc/src/snippets/simplemodel-use/main.cpp
index a3bb0e7..d7fc755 100644
--- a/doc/src/snippets/simplemodel-use/main.cpp
+++ b/doc/src/snippets/simplemodel-use/main.cpp
@@ -69,7 +69,7 @@ int main(int argc, char *argv[])
layout->addWidget(title);
//! [0]
- QDirModel *model = new QDirModel;
+ QFileSystemModel *model = new QFileSystemModel;
QModelIndex parentIndex = model->index(QDir::currentPath());
int numRows = model->rowCount(parentIndex);
//! [0]
diff --git a/doc/src/snippets/statemachine/main2.cpp b/doc/src/snippets/statemachine/main2.cpp
index d882400..2419dc2 100644
--- a/doc/src/snippets/statemachine/main2.cpp
+++ b/doc/src/snippets/statemachine/main2.cpp
@@ -57,7 +57,7 @@ int main(int argv, char **args)
//![0]
//![2]
- s12>addTransition(quitButton, SIGNAL(clicked()), s12);
+ s12->addTransition(quitButton, SIGNAL(clicked()), s12);
//![2]
//![1]
@@ -71,7 +71,7 @@ int main(int argv, char **args)
QButton *interruptButton = new QPushButton("Interrupt Button");
//![3]
- QHistoryState *s1h = s1->addHistoryState();
+ QHistoryState *s1h = new QHistoryState(s1);
QState *s3 = new QState();
s3->assignProperty(label, "text", "In s3");