diff options
Diffstat (limited to 'doc/src')
33 files changed, 1478 insertions, 265 deletions
diff --git a/doc/src/examples/ftp.qdoc b/doc/src/examples/ftp.qdoc index 8fded88..68fb0d7 100644 --- a/doc/src/examples/ftp.qdoc +++ b/doc/src/examples/ftp.qdoc @@ -40,7 +40,7 @@ ****************************************************************************/ /*! - \example network/ftp + \example network/qftp \title FTP Example The FTP example demonstrates a simple FTP client that can be used @@ -90,12 +90,12 @@ the FTP server, and registers whether an entry represents a directory or a file. We use the QFile object to download files from the FTP server. - + \section1 FtpWindow Class Implementation We skip the \c FtpWindow constructor as it only contains code for setting up the GUI, which is explained in other examples. - + We move on to the slots, starting with \c connectOrDisconnect(). \snippet examples/network/qftp/ftpwindow.cpp 0 @@ -137,7 +137,7 @@ \snippet examples/network/qftp/ftpwindow.cpp 3 \dots \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 @@ -153,7 +153,7 @@ 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/qftp/ftpwindow.cpp 7 After login, the QFtp::list() function will list the top-level @@ -165,7 +165,7 @@ When a \l{QFtp::}{Get} command is finished, a file has finished downloading (or an error occurred during the download). - + \snippet examples/network/qftp/ftpwindow.cpp 9 After a \l{QFtp::}{List} command is performed, we have to check if diff --git a/doc/src/examples/imagegestures.qdoc b/doc/src/examples/imagegestures.qdoc new file mode 100644 index 0000000..33c1ace --- /dev/null +++ b/doc/src/examples/imagegestures.qdoc @@ -0,0 +1,116 @@ +/**************************************************************************** +** +** 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 gestures/imagegestures + \title Image Gestures Example + + This example shows how to enable gestures for a widget and use gesture input + to perform actions. + + \image imagegestures-example.png Screenshot of the Image Gestures example. + + We use two classes to create the user interface for the application: \c MainWidget + and \c ImageWidget. The \c MainWidget class is simply used as a container for the + \c ImageWidget class, which we will configure to accept gesture input. Since we + are interested in the way gestures are used, we will concentrate on the + implementation of the \c ImageWidget class. + + \section1 ImageWidget Class Definition + + The \c ImageWidget class is a simple QWidget subclass that reimplements the general + QWidget::event() handler function in addition to several more specific event handlers: + + \snippet examples/gestures/imagegestures/imagewidget.h class definition begin + \dots + \snippet examples/gestures/imagegestures/imagewidget.h class definition end + + We also implement a private helper function, \c gestureEvent(), to help manage + gesture events delivered to the widget, and three functions to perform actions + based on gestures: \c panTriggered(), \c pinchTriggered() and \c swipeTriggered(). + + \section1 ImageWidget Class Implementation + + In the widget's constructor, we begin by setting up various parameters that will + be used to control the way images are displayed. + + \snippet examples/gestures/imagegestures/imagewidget.cpp constructor + + We enable three of the standard gestures for the widget by calling QWidget::grabGesture() + with the types of gesture we need. These will be recognized by the application's + default gesture recognizer, and events will be delivered to our widget. + + Since QWidget does not define a specific event handler for gestures, the widget + needs to reimplement the general QWidget::event() to receive gesture events. + + \snippet examples/gestures/imagegestures/imagewidget.cpp event handler + + We implement the event handler to delegate gesture events to a private function + specifically written for the task, and pass all other events to QWidget's + implementation. + + The \c gestureHandler() function examines the gestures supplied by the + newly-delivered QGestureEvent. Since only one gesture of a given type can be + used on a widget at any particular time, we can check for each gesture type + using the QGestureEvent::gesture() function: + + \snippet examples/gestures/imagegestures/imagewidget.cpp gesture event handler + + If a QGesture object is supplied for a certain type of gesture, we call a special + purpose function to deal with it, casting the gesture object to the appropriate + QGesture subclass. + + To illustrate how a standard gesture can be interpreted by an application, we + show the implementation of the \c swipeTriggered() function, which handles the + gesture associated with a brushing or swiping motion on the user's display or + input device: + + \snippet examples/gestures/imagegestures/imagewidget.cpp swipe function + + The QSwipeGesture class provides specialized functions and defines a enum + to make it more convenient for developers to discover which direction, if + any, the user swiped the display. Here, we simply navigate to the previous + image in the collection if the user swiped upwards or to the left; otherwise + we navigate to the next image in the collection. + + The other gestures are also handled by special purpose functions, but use + the values of properties held by the QGesture object passed to them. +*/ diff --git a/doc/src/examples/stickman.qdoc b/doc/src/examples/stickman.qdoc index e70c39b..c9e98d0 100644 --- a/doc/src/examples/stickman.qdoc +++ b/doc/src/examples/stickman.qdoc @@ -55,9 +55,9 @@ Animations are implemented as composite states. Each child state of the animation state represents a frame in the animation by setting the position of each joint in the stickman's skeleton to the positions defined for the particular frame. The frames are then bound together - with animated transitions that trigger on the source state's polished() signal. Thus, the - machine will enter the state representing the next frame in the animation immediately after it - has finished animating into the previous frame. + with animated transitions that trigger on the source state's propertiesAssigned() signal. Thus, + the machine will enter the state representing the next frame in the animation immediately after + it has finished animating into the previous frame. \image stickman-example1.png @@ -67,7 +67,8 @@ \snippet examples/animation/stickman/lifecycle.cpp 1 - The states are then bound together with signal transitions that listen to the polished() signal. + The states are then bound together with signal transitions that listen to the + propertiesAssigned() signal. \snippet examples/animation/stickman/lifecycle.cpp 2 diff --git a/doc/src/external-resources.qdoc b/doc/src/external-resources.qdoc index ad6731b..4e1f3b7 100644 --- a/doc/src/external-resources.qdoc +++ b/doc/src/external-resources.qdoc @@ -367,3 +367,48 @@ \externalpage http://www.kde.org \title KDE */ + +/*! + \externalpage http://www.directfb.org/index.php?path=Main%2FDownloads&page=1 + \title DirectFB - df_window example +*/ + +/*! + \externalpage http://www.directfb.org/docs/DirectFB_Reference_1_4/IDirectFBPalette.html + \title DirectFB - IDirectFBPalette +*/ + +/*! + \externalpage http://www.cplusplus.com/reference/clibrary/cstring/memcpy/ + \title C++ Reference - memcpy +*/ + +/*! + \externalpage http://www.directfb.org/docs/DirectFB_Reference_1_4/IDirectFB_CreateInputEventBuffer.html + \title DirectFB - CreateInputEventBuffer +*/ + +/*! + \externalpage http://www.directfb.org/docs/DirectFB_Reference_1_4/types.html#DFBSurfaceBlittingFlags + \title DirectFB - DFBSurfaceBlittingFlags +*/ + +/*! + \externalpage http://directfb.org/docs/DirectFB_Reference_1_4/IDirectFBImageProvider.html + \title DirectFB - IDirectFBImageProvider +*/ + +/*! + \externalpage http://www.directfb.org/docs/DirectFB_Reference_1_4/IDirectFBSurface.html + \title DirectFB - IDirectFBSurface +*/ + +/*! + \externalpage http://www.directfb.org/docs/DirectFB_Reference_1_4/IDirectFBWindow + \title DirectFB - IDirectFBWindow +*/ + +/*! + \externalpage http://www.directfb.org/docs/DirectFB_Reference_1_4/types.html#DFBSurfaceDescription + \title DirectFB - DFBSurfaceDescription +*/ diff --git a/doc/src/frameworks-technologies/gestures.qdoc b/doc/src/frameworks-technologies/gestures.qdoc index a619fe8..2fa8dab 100644 --- a/doc/src/frameworks-technologies/gestures.qdoc +++ b/doc/src/frameworks-technologies/gestures.qdoc @@ -122,7 +122,7 @@ \section2 Filtering Input Events - The \l{QGestureRecognizer::}{filterEvent()} function must be reimplemented. + The \l{QGestureRecognizer::}{recognize()} function must be reimplemented. This function handles and filters the incoming input events for the target objects and determines whether or not they correspond to the gesture the recognizer is looking for. @@ -132,15 +132,15 @@ persistent information about the state of the recognition process in the QGesture object supplied. - Your \l{QGestureRecognizer::}{filterEvent()} function must return a value of - Qt::GestureState that indicates the state of recognition for a given gesture and + Your \l{QGestureRecognizer::}{recognize()} function must return a value of + QGestureRecognizer::Result that indicates the state of recognition for a given gesture and target object. This determines whether or not a gesture event will be delivered to a target object. \section2 Custom Gestures If you choose to represent a gesture by a custom QGesture subclass, you will need to - reimplement the \l{QGestureRecognizer::}{createGesture()} function to construct + reimplement the \l{QGestureRecognizer::}{create()} function to construct instances of your gesture class instead of standard QGesture instances. Alternatively, you may want to use standard QGesture instances, but add additional dynamic properties to them to express specific details of the gesture you want to handle. @@ -152,7 +152,7 @@ \l{QGestureRecognizer::}{reset()} function to perform these special tasks. Note that QGesture objects are only created once for each combination of target object - and gesture type, and they are reused every time the user attempts to perform the + and gesture type, and they might be reused every time the user attempts to perform the same gesture type on the target object. As a result, it can be useful to reimplement the \l{QGestureRecognizer::}{reset()} function to clean up after each previous attempt at recognizing a gesture. @@ -162,12 +162,12 @@ To use a gesture recognizer, construct an instance of your QGestureRecognizer subclass, and register it with the application with - QApplication::registerGestureRecognizer(). A recognizer for a given type of - gesture can be removed with QApplication::unregisterGestureRecognizer(). + QGestureRecognizer::registerRecognizer(). A recognizer for a given type of + gesture can be removed with QGestureRecognizer::unregisterRecognizer(). \section1 Further Reading - The \l{Image Gestures Example} shows how to enable gestures for a widget in - a simple image viewer application. + The \l{gestures/imagegestures}{Image Gestures Example} shows how to enable + gestures for a widget in a simple image viewer application. */ diff --git a/doc/src/frameworks-technologies/statemachine.qdoc b/doc/src/frameworks-technologies/statemachine.qdoc index ed8bc85..b0b13a7 100644 --- a/doc/src/frameworks-technologies/statemachine.qdoc +++ b/doc/src/frameworks-technologies/statemachine.qdoc @@ -75,6 +75,11 @@ states can be configured to set properties and invoke methods on QObjects. Qt's event system is used to drive the state machines. + The state graph in the State Machine framework is hierarchical. States can be nested inside of + other states, and the current configuration of the state machine consists of the set of states + which are currently active. All the states in a valid configuration of the state machine will + have a common ancestor. + \section1 Classes in the State Machine Framework These classes are provided by qt for creating event-driven state machines. @@ -269,9 +274,17 @@ When a parallel state group is entered, all its child states will be simultaneously entered. Transitions within the individual child states - operate normally. However, any of the child states may take a transition - outside the parent state. When this happens, the parent state and all of its - child states are exited. + operate normally. However, any of the child states may take a transition which exits the parent + state. When this happens, the parent state and all of its child states are exited. + + The parallelism in the State Machine framework follows an interleaved semantics. All parallel + operations will be executed in a single, atomic step of the event processing, so no event can + interrupt the parallel operations. However, events will still be processed sequentially, since + the machine itself is single threaded. As an example: Consider the situation where there are two + transitions that exit the same parallel state group, and their conditions become true + simultaneously. In this case, the event that is processed last of the two will not have any + effect, since the first event will already have caused the machine to exit from the parallel + state. \section1 Detecting that a Composite State has Finished @@ -413,18 +426,8 @@ value of the property before any property assignments in states were executed.) Take the following code: - \code - QStateMachine machine; - machine.setGlobalRestorePolicy(QStateMachine::RestoreProperties); - - QState *s1 = new QState(); - s1->assignProperty(object, "fooBar", 1.0); - machine.addState(s1); - machine.setInitialState(s1); - QState *s2 = new QState(); - machine.addState(s2); - \endcode + \snippet doc/src/snippets/statemachine/main5.cpp 0 Lets say the property \c fooBar is 0.0 when the machine starts. When the machine is in state \c s1, the property will be 1.0, since the state explicitly assigns this value to it. When the @@ -433,21 +436,8 @@ If we are using nested states, the parent defines a value for the property which is inherited by all descendants that do not explicitly assign a value to the property. - \code - QStateMachine machine; - machine.setGlobalRestorePolicy(QStateMachine::RestoreProperties); - QState *s1 = new QState(); - s1->assignProperty(object, "fooBar", 1.0); - machine.addState(s1); - machine.setInitialState(s1); - - QState *s2 = new QState(s1); - s2->assignProperty(object, "fooBar", 2.0); - s1->setInitialState(s2); - - QState *s3 = new QState(s1); - \endcode + \snippet doc/src/snippets/statemachine/main5.cpp 2 Here \c s1 has two children: \c s2 and \c s3. When \c s2 is entered, the property \c fooBar will have the value 2.0, since this is explicitly defined for the state. When the machine is in @@ -460,15 +450,8 @@ properties as they are assigned in states. Say we have the following code: - \code - QState *s1 = new QState(); - QState *s2 = new QState(); - s1->assignProperty(button, "geometry", QRectF(0, 0, 50, 50)); - s2->assignProperty(button, "geometry", QRectF(0, 0, 100, 100)); - - s1->addTransition(button, SIGNAL(clicked()), s2); - \endcode + \snippet doc/src/snippets/statemachine/main5.cpp 3 Here we define two states of a user interface. In \c s1 the \c button is small, and in \c s2 it is bigger. If we click the button to transition from \c s1 to \c s2, the geometry of the button @@ -476,16 +459,7 @@ smooth, however, all we need to do is make a QPropertyAnimation and add this to the transition object. - \code - QState *s1 = new QState(); - QState *s2 = new QState(); - - s1->assignProperty(button, "geometry", QRectF(0, 0, 50, 50)); - s2->assignProperty(button, "geometry", QRectF(0, 0, 100, 100)); - - QSignalTransition *transition = s1->addTransition(button, SIGNAL(clicked()), s2); - transition->addAnimation(new QPropertyAnimation(button, "geometry")); - \endcode + \snippet doc/src/snippets/statemachine/main5.cpp 4 Adding an animation for the property in question means that the property assignment will no longer take immediate effect when the state has been entered. Instead, the animation will start @@ -504,33 +478,48 @@ property can potentially have any value, depending on the animation. In some cases, it can be useful to be able to detect when the property has actually been assigned - the value defined by a state. For this, we can use the state's polished() signal. - \code - QState *s1 = new QState(); - s1->assignProperty(button, "geometry", QRectF(0, 0, 50, 50)); + the value defined by a state. - QState *s2 = new QState(); + Say we have the following code: - s1->addTransition(s1, SIGNAL(polished()), s2); - \endcode + \snippet doc/src/snippets/statemachine/main5.cpp 5 + + When \c button is clicked, the machine will transition into state \c s2, which will set the + geometry of the button, and then pop up a message box to alert the user that the geometry has + been changed. + + In the normal case, where animations are not used, this will operate as expected. However, if + an animation for the \c geometry of \c button is set on the transition between \c s1 and \c s2, + the animation will be started when \c s2 is entered, but the \c geometry property will not + actually reach its defined value before the animation is finished running. In this case, the + message box will pop up before the geometry of the button has actually been set. + + To ensure that the message box does not pop up until the geometry actually reaches its final + value, we can use the state's propertiesAssigned() signal. The propertiesAssigned() signal will be + emitted when the property is assigned its final value, whether this is done immediately or + after the animation has finished playing. + + \snippet doc/src/snippets/statemachine/main5.cpp 6 - The machine will be in state \c s1 until the \c geometry property has been set. Then it will - immediately transition into \c s2. If the transition into \c s1 has an animation for the \c - geometry property, then the machine will stay in \c s1 until the animation has finished. If there - is no animation, it will simply set the property and immediately enter state \c s2. + In this example, when \c button is clicked, the machine will enter \c s2. It will remain in state + \c s2 until the \c geometry property has been set to \c QRect(0, 0, 50, 50). Then it will + transition into \c s3. When \c s3 is entered, the message box will pop up. If the transition into + \c s2 has an animation for the \c geometry property, then the machine will stay in \c s2 until the + animation has finished playing. If there is no such animation, it will simply set the property and + immediately enter state \c s3. - Either way, when the machine is in state \c s2, the property \c geometry has been assigned the - defined value. + Either way, when the machine is in state \c s3, you are guaranteed that the property \c geometry + has been assigned the defined value. If the global restore policy is set to QStateMachine::RestoreProperties, the state will not emit - the polished() signal until these have been executed as well. + the propertiesAssigned() signal until these have been executed as well. - \section1 What happens if a state is exited before the animation has finished + \section1 What Happens If A State Is Exited Before The Animation Has Finished If a state has property assignments, and the transition into the state has animations for the properties, the state can potentially be exited before the properties have been assigned to the values defines by the state. This is true in particular when there are transitions out from the - state that do not depend on the state being polished, as described in the previous section. + state that do not depend on the propertiesAssigned signal, as described in the previous section. The State Machine API guarantees that a property assigned by the state machine either: \list @@ -545,7 +534,7 @@ If the target state does not assign any value to the property, there are two options: By default, the property will be assigned the value defined by the state it is leaving - (the value it would have been assigned if the animation had been permitted to finish playing.) If + (the value it would have been assigned if the animation had been permitted to finish playing). If a global restore policy is set, however, this will take precedence, and the property will be restored as usual. diff --git a/doc/src/getting-started/examples.qdoc b/doc/src/getting-started/examples.qdoc index 05940e4..79cbe89 100644 --- a/doc/src/getting-started/examples.qdoc +++ b/doc/src/getting-started/examples.qdoc @@ -729,7 +729,7 @@ \o \l{network/network-chat}{Network Chat} \o \l{network/fortuneclient}{Fortune Client}\raisedaster \o \l{network/fortuneserver}{Fortune Server}\raisedaster - \o \l{network/ftp}{FTP}\raisedaster + \o \l{network/qftp}{FTP}\raisedaster \o \l{network/http}{HTTP} \o \l{network/loopback}{Loopback} \o \l{network/threadedfortuneserver}{Threaded Fortune Server}\raisedaster diff --git a/doc/src/getting-started/installation.qdoc b/doc/src/getting-started/installation.qdoc index e127429..1eefed3 100644 --- a/doc/src/getting-started/installation.qdoc +++ b/doc/src/getting-started/installation.qdoc @@ -498,10 +498,9 @@ in the \l{Qt for Windows CE Requirements} document. */ /*! \page install-Symbian-installer.html - -\title Installing Qt on the Symbian platform using binary package +\title Installing Qt on the Symbian Platform from a Binary Package \ingroup qts60 -\brief How to install Qt on the Symbian platform using the binary package. +\brief How to install Qt on the Symbian platform from a binary package. \note Qt for Symbian platform has some requirements that are given in more detail in the \l{Qt for Symbian platform Requirements} document. @@ -528,9 +527,9 @@ in the \l{Qt for Symbian platform Requirements} document. To run the demos and examples on the emulator, you need to build them first. Open the "Qt for Symbian platform Command Prompt" from the Start menu and type: - + \snippet doc/src/snippets/code/doc_src_installation.qdoc 25 - + To run the demos on the emulator simply navigate to the directory of the demo you want to see and run: @@ -538,7 +537,7 @@ in the \l{Qt for Symbian platform Requirements} document. For more information about building and running Qt programs on the Symbian platform, - see \l{Symbian platform - Introduction to using Qt}. + see \l{Symbian platform - Introduction to Qt}. We hope you will enjoy using Qt. @@ -546,19 +545,18 @@ Symbian platform, */ /*! \page install-Symbian.html - -\title Installing Qt on the Symbian platform +\title Installing Qt on the Symbian Platform \ingroup installation \ingroup qts60 -\brief How to install Qt for the Symbian platform +\brief How to install Qt on the Symbian platform. \note Qt for the Symbian platform has some requirements that are given in more detail -in the \l{Qt for Symbian platform Requirements} document. +in the \l{Qt for Symbian Platform Requirements} document. \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 the Symbian platform using binary package}{here}.} +If you are using pre-built binaries, follow the instructions given in the +\l{Installing Qt on the Symbian Platform from a Binary Package} document.} \list 1 @@ -608,7 +606,7 @@ If you are using pre-built binaries, follow the instructions To build Qt for the device, type: \snippet doc/src/snippets/code/doc_src_installation.qdoc 28 - + Congratulations, Qt is now ready to use. \o Running Qt demos @@ -617,7 +615,7 @@ If you are using pre-built binaries, follow the instructions to try out. An excellent starting point is the "fluidlauncher" demo. To run the demo on a real device, you first have to install the Qt libraries on the device: - + \snippet doc/src/snippets/code/doc_src_installation.qdoc 29 \note You will need to supply certificate that allows installation @@ -629,14 +627,14 @@ If you are using pre-built binaries, follow the instructions This will create a self-signed \c fluidlauncher_armv5_urel.sis and install it to your device. - + To run the demos on the emulator simply navigate to the directory of the demo you want to see and run: \snippet doc/src/snippets/code/doc_src_installation.qdoc 27 For more information about building and running Qt programs on the -Symbian platform, see \l{Symbian platform - Introduction to using Qt}. +Symbian platform, see \l{Symbian platform - Introduction to Qt}. We hope you will enjoy using Qt. @@ -956,7 +954,7 @@ Symbian platform, see \l{Symbian platform - Introduction to using Qt}. /*! \page requirements-symbian.html - \title Qt for Symbian platform Requirements + \title Qt for Symbian Platform Requirements \ingroup installation \brief Setting up the Symbian platform environment for Qt. \previouspage General Qt Requirements diff --git a/doc/src/howtos/guibooks.qdoc b/doc/src/howtos/guibooks.qdoc index c41d8fa..6e64c09 100644 --- a/doc/src/howtos/guibooks.qdoc +++ b/doc/src/howtos/guibooks.qdoc @@ -52,8 +52,10 @@ GUI Programming with Qt 4, Second Edition}} by Jasmin Blanchette and Mark Summerfield, ISBN 0-13-235416-0. This is the official Qt book written - by two veteran Trolls. The first edition, which is based on Qt 4.1, is available - \l{http://www.qtrac.eu/C++-GUI-Programming-with-Qt-4-1st-ed.zip}{online}. + by two veteran Trolls. The first edition, which is based on Qt 4.1, is + \l{http://www.qtrac.eu/C++-GUI-Programming-with-Qt-4-1st-ed.zip}{available online}. + The second edition, based on Qt 4.3, is + \l{http://www.informit.com/store/product.aspx?isbn=0132354160}{also available online}. \bold{\l{http://www.amazon.com/exec/obidos/ASIN/0385267746/trolltech/t}{The Design of Everyday Things}} by Donald Norman, ISBN 0-38526774-6, is one of the classics of human diff --git a/doc/src/images/platformHWAcc.png b/doc/src/images/platformHWAcc.png Binary files differnew file mode 100644 index 0000000..76a5a48 --- /dev/null +++ b/doc/src/images/platformHWAcc.png diff --git a/doc/src/internationalization/i18n.qdoc b/doc/src/internationalization/i18n.qdoc index 2d1b8cc..ecc25fe 100644 --- a/doc/src/internationalization/i18n.qdoc +++ b/doc/src/internationalization/i18n.qdoc @@ -93,7 +93,7 @@ \o Greek \o Hebrew \o Thai and Lao - \o All scripts in Unicode 4.0 that do not require special processing + \o All scripts in Unicode 5.1 that do not require special processing \endlist On Windows, Unix/X11 with FontConfig (client side font support) @@ -112,6 +112,7 @@ \o Tamil \o Telugu \o Tibetan + \o N'Ko \endlist Many of these writing systems exhibit special features: @@ -181,7 +182,7 @@ \section2 Use QString for All User-Visible Text - Since QString uses the Unicode 4.0 encoding internally, every + Since QString uses the Unicode 5.1 encoding internally, every language in the world can be processed transparently using familiar text processing operations. Also, since all Qt functions that present text to the user take a QString as a parameter, diff --git a/doc/src/modules.qdoc b/doc/src/modules.qdoc index 6f6e7bd..e57b271 100644 --- a/doc/src/modules.qdoc +++ b/doc/src/modules.qdoc @@ -227,10 +227,11 @@ The QtOpenGL module is part of the \l{Qt Full Framework Edition} and the \l{Open Source Versions of Qt}. It is available on Windows, X11, and Mac OS X. - \l{Qt for Embedded Linux} supports OpenGL ES (OpenGL for Embedded Systems). - To be able to use the OpenGL API in \l{Qt for Embedded Linux}, it must be + \l{Qt for Embedded Linux and OpenGL} supports OpenGL ES (OpenGL for Embedded Systems). + \note To be able to use the OpenGL API in \l{Qt for Embedded Linux}, it must be integrated with the Q Window System (QWS). See the \l{Qt for Embedded Linux and OpenGL} documentation for details. + */ /*! diff --git a/doc/src/network-programming/qtnetwork.qdoc b/doc/src/network-programming/qtnetwork.qdoc index d9377fb..c20adaf 100644 --- a/doc/src/network-programming/qtnetwork.qdoc +++ b/doc/src/network-programming/qtnetwork.qdoc @@ -101,7 +101,7 @@ Each application or library can create one or more instances of QNetworkAccessManager to handle network communication. - + \section1 Writing FTP Clients with QFtp FTP (File Transfer Protocol) is a protocol used almost exclusively @@ -155,7 +155,7 @@ commands based on the result of a previous command. It also enables you to provide detailed feedback to the user. - The \l{network/ftp}{FTP} example + The \l{network/qftp}{FTP} example illustrates how to write an FTP client. Writing your own FTP (or HTTP) server is possible using the lower-level classes QTcpSocket and QTcpServer. diff --git a/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc b/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc new file mode 100644 index 0000000..9c18d87 --- /dev/null +++ b/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc @@ -0,0 +1,71 @@ +/**************************************************************************** +** +** 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$ +** +****************************************************************************/ + +/*! + + \page qt-embeddedLinux-accel.html + + \target Hardware Acceleration with Qt for Embedded Linux + + \title Qt for Embedded Linux Hardware Accelerated Graphics + \ingroup qt-embedded-linux + + + \input platforms/emb-hardwareacceleration.qdocinc + +\section1 Supported Hardware Accelerated Graphics APIs + +This list shows which Hardware Accelerated Graphics APIs currently +supported by Qt. + + \table + \header + \o Supported Hardware Accelerated Graphics APIs + \row + \o \l {Qt for Embedded Linux and OpenGL}{OpenGL ES} + \row + \o \l {Qt for Embedded Linux and OpenVG}{OpenVG} + \row + \o \l {Qt for Embedded Linux and DirectFB}{DirectFB} + \endtable + + +*/ diff --git a/doc/src/platforms/emb-HwAcc-WinCE.qdoc b/doc/src/platforms/emb-HwAcc-WinCE.qdoc new file mode 100644 index 0000000..66b6948 --- /dev/null +++ b/doc/src/platforms/emb-HwAcc-WinCE.qdoc @@ -0,0 +1,69 @@ +/**************************************************************************** +** +** 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$ +** +****************************************************************************/ + +/*! + \page qt-embeddedWinCE-accel.html + + \target Hardware Acceleration with Qt for Windows CE + + \title Qt for Windows CE Hardware Accelerated Graphics + \ingroup qtce + + + \input platforms/emb-hardwareacceleration.qdocinc + + \section1 Supported Hardware Accelerated Graphics APIs + + This list shows which Hardware Accelerated Graphics APIs currently +supported by Qt. + + \table + \header + \o Supported Hardware Accelerated Graphics APIs + \row + \o \l {Qt for Windows CE and OpenGL ES}{OpenGL ES} + \row + \o \l {Qt for Windows CE and OpenVG}{OpenVG} + \endtable + + + +*/ diff --git a/doc/src/platforms/emb-directfb-EmbLinux.qdoc b/doc/src/platforms/emb-directfb-EmbLinux.qdoc new file mode 100644 index 0000000..38782be --- /dev/null +++ b/doc/src/platforms/emb-directfb-EmbLinux.qdoc @@ -0,0 +1,330 @@ +/**************************************************************************** +** +** 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$ +** +****************************************************************************/ + +/*! +\page qt-embeddedLinux-directfb.html + +\title Qt for Embedded Linux and DirectFB + +\ingroup qt-embedded-linux + +\section1 Introduction + +DirectFB is an open source LGPL licensed project founded by Denis Oliver Kropp +and generally chip vendors start out with the official version and +implement their own plugins to optimize the operations their hardware +supports. + +We recommend using Qt 4.6 with DirectFB. DirectFB support was introduced +already into Qt for Embedded Linux as a labs project for Qt 4.3 and folded +into Qt as a screen driver for Qt 4.4, but not supported fully. In Qt 4.5, +major changes were made to make it work with the optimized raster paint +engine. And in Qt 4.6 these have been further improved. + +\tableofcontents + +\section1 Using DirectFB with Qt +DirectFB is centered around \l{DirectFB - IDirectFBSurface}{Surfaces} +which is the equivalent of a QPaintDevice. In the Qt/DirectFB plugin, +DirectFB maps onto either a QPixmap or a QWindowSurface which essentially +means that drawing onto QPixmap or a QWidget can be accelerated and drawing +onto any other paint device (e.g. QImage) cannot. + +\section2 Configure + +When configuring Qt there are two options, from which you can choose: + +\code + ./configure -plugin-gfx-directfb + ./configure -qt-gfx-directfb + +\endcode + +With either mode, Qt will try the following to look for the DirectFB +includes/libs. + +\list + \o Use pkg-config + \o Use directfb-config + \o Check in your qmake.conf +\endlist + +Often the values returned from pkg-config/directfb-config indicates the +locations of the libs/headers on the target rootfs, rather than their +location on your host. The safest option is usually to explicitly populate +these variables in your qmake.conf like this: + +\code +QT_CFLAGS_DIRECTFB = +/opt/toolchain/gcc4.3_mipsel_linux/usr/include/directfb -D_REENTRANT +QT_LIBS_DIRECTFB = -L/opt/toolchain/gcc4.3_mipsel_linux/usr/lib/-ldirect +-ldirectfb -lfusion +\endcode + +\note While DirectFB supports a multi-process setup through a +kernel-extension called Fusion this setup is not well tested with Qt. + +\section2 Supported graphics operations + +IDirectFBSurface supports blitting, filling, drawing lines rects etc, but +it does not support everything Qt allows you to do. E.g. painter paths, +polygons, complex transformations, antialiasing, gradients. Some of these +things are handled in newer versions of DirectFB and could be supported by +Qt. They are seemingly optional at the driver level, so you need to have +fall back code paths for older drivers and drivers on which this is not +implemented. + +The QDirectFBPaintEngine is a subclass of the QRasterPaintEngine, thus +essentially supporting everything QRasterPaintEngine supports. This means +that it supports all graphical operations that Qt supports, but certain +operations will have to fall back to software rendering and that should be +avoided due to performance issues. Instead, these operations should be +rendered into a QPixmap once, and then reuse the pixmap. + +Note: Fallbacks to software rendering should be avoided. If unsupported +operations are used, the paint engine must fallback to the +QRasterPaintEngine engine. A good debugging tip is to make Qt warn you when +such fall backs occur, and to disable the fall back and only return. +Debugging options are listed below. + +\section2 DirectFB driver +DirectFB also provides an abstraction for keyboard and mouse drivers. This +simplifies the process of getting the target hardware up and running. It +also brings us to a feature fragmentation issue between different versions +of DirectFB. + +The Qt DirectFB driver currently supports DirectFB versions >= 0.9. Still, +there are large differences in what each actual implementation handles +correctly. It is relatively common not to properly support +\l{DirectFB - IDirectFBWindow}{DirectFB windows}, so Qt needs to handle +this case with a different code path. In addition, certain drivers do not +properly support DirectFB's cursor handling. This means Qt has to have a +code path for rendering the cursor itself when this is the case. +Some drivers do not let us create +\l{DirectFB - DFBSurfaceDescription}{preallocated surfaces} which means we +have to have a conditional code path for that case. + +\section2 Optimize performance using define options + +Qt/DirectFB comes with a number of defines that can be either +uncommented in directfb.pri or added to the QT_DEFINES_DIRECTFB variable in +your qmake.conf. + +\note The defines have been moved from +\e{src/plugins/gfxdrivers/directfb/directfb.pro} to +\e{src/gui/embedded/directfb.pri} + +\code +#DIRECTFB_DRAWINGOPERATIONS=DRAW_RECTS|DRAW_LINES|DRAW_IMAGE|DRAW_PIXMAP| + DRAW_TILED_PIXMAP|STROKE_PATH|DRAW_PATH|DRAW_POINTS|DRAW_ELLIPSE|DRAW_POLYGON| + DRAW_TEXT|FILL_PATH|FILL_RECT|DRAW_COLORSPANS|DRAW_ROUNDED_RECT + + #DEFINES += \"QT_DIRECTFB_WARN_ON_RASTERFALLBACKS=$$DIRECTFB_DRAWINGOPERATIONS\" + #DEFINES += \"QT_DIRECTFB_DISABLE_RASTERFALLBACKS=$$DIRECTFB_DRAWINGOPERATIONS\" +\endcode + +As demonstrated above, you need to Qt which drawing operations you want to +warn/disable. Since there are varying implementations of DirectFB from +manufacturer to manufacture, different operations will be optimized. This +require you to define the operations you want to warn about or disable. +These are listed above in the DIRECTFB_DRAWINGOPERATIONS variable. + +Following is a table showing which options you have. + +\table + \header + \o Define option + \o Description + \row + \o QT_DIRECTFB_IMAGECACHE + \o Defining this means that Qt will cache an IDirectFBSurface per +QImage you draw based on its \l{QImage::}{cacheKey()}. +Use this define if your application draws many QImages that +remain the same. Note that if you in this situation draw an image and then +change it, by calling bits() or opening a QPainter on it, the cache will +not benefit you. You can control the cache size with the imageCacheSize +connect option. + + \row + \o QT_NO_DIRECTFB_WM + \o If your DirectFB implementation does not support windows, you +have to define this to make Qt work properly. You can test this by checking +if the \l{DirectFB - df_window example}{df_window example} runs well. +This means that all drawing operations onto a QWidget involves +an extra blitting step since Qt essentially first has to draw into an +off-screen buffer and then blit this buffer to the back buffer of the +primary surface. Finally, Qt must flip the back buffer to the front buffer, +which usually involves another blit. Still, blits are usually very fast +with DirectFB. + +To work around this you can make your widget paint on screen, \l +Qt::WA_PaintOnScreen but this comes with other limitations. This should be +avoided if you want more than one full-screen window in your application. +In addition, it will not work without proper DirectFB mouse support from the +layer. Also, see QT_NO_DIRECTFB_LAYER for more. + + \row + \o QT_NO_DIRECTFB_LAYER + \o If your DirectFB display layer cannot be used for e.g. drawing +mouse cursor, creating windows you have to define this. Defining this also +requires defining QT_NO_DIRECTFB_WM and involves making Qt render the +cursor rather than letting DirectFB do it. + + \row + \o QT_NO_DIRECTFB_PALETTE + \o Define this if your DirectFB driver does not support surfaces +with \l{DirectFB - IDirectFBPalette}{color tables}. +The effect of defining this is that Qt will have to convert +images with \l QImage::Format_Indexed8 format to another format before +rendering them. + + \row + \o QT_NO_DIRECTFB_PREALLOCATED + \o Define this if your DirectFB driver does not support creating a +surface with preallocated data. This will make a more frequent use of +\l{C++ Reference - memcpy}{memcpy()} +when drawing images. If you define this, you might want to consider +defining QT_DIRECTFB_IMAGECACHE for better image rendering performance. + + \row + \o QT_NO_DIRECTFB_MOUSE and QT_NO_DIRECTFB_KEYBOARD + \o Define this if your driver does not provide keyboard/mouse +events through \l{DirectFB - CreateInputEventBuffer}{CreateInputEventBuffer}. +This means that Qt cannot use DirectFB to receive keyboard/mouse events and +if you want such events in your application, you will have to provide +another driver. For more info see \l {Qt for Embedded Linux Pointer +Handling}{Qt for Embedded Linux Pointer Handling} and \l{Qt for Embedded +Linux Character Input}{Qt for Embedded Linux Character Input} + + \row + \o QT_DIRECTFB_TIMING + \o Define this when debugging to get output on stderr about the +frames per second. + + \row + \o QT_NO_DIRECTFB_OPAQUE_DETECTION + \o When blitting a surface Qt has to decide whether to set the +\l{DirectFB - DFBSurfaceBlittingFlags}{DSBLIT_BLEND_ALPHACHANNEL} +flag. If you load an image from file or network data that has a format that +includes an alpha channel, the image might still be completely opaque. +Normally Qt runs through every pixel to check if there really is an alpha +channel there. This involves some overhead but usually pays off in the end +because blitting is cheaper than blending. If you define this Qt will +assume that an image with a format that has alpha channel contains at least +one pixel with an alpha value != 255. + + \row + \o QT_DIRECTFB_SUBSURFACE + \o Defining this enables a mode that tries to minimize overhead from +locking/unlocking surfaces. Note that this currently is experimental. + + \row + \o QT_DIRECTFB_WINDOW_AS_CURSOR + \o Define this if your DirectFB implementation supports windows but +can not render the cursor properly. This involves creating a small top level +window and moving it around when the cursor moves. It does not always +perform well. + + \row + \o QT_NO_DIRECTFB_IMAGEPROVIDER + \o By default Qt will use DirectFB to load QPixmaps from disk/memory. If +your DirectFB implementation does not support this it might make sense to +define this. + + \row + \o QT_DIRECTFB_IMAGEPROVIDER_KEEPALIVE + \o Define this to make sure Qt always keeps at least one +\l{DirectFB - IDirectFBImageProvider}{IDirectFBImageProvider} +object alive. This is to avoid considerable overhead when the first +IDirectFBImageProvider is created, the last IDirectFBImageProvider is +removed. + +\endtable + +\section2 Unsupported graphics operations + +There are a number of unsupported operations causing fallbacks. DirectFB +does not support the following functions. + + + +\table + \header + \o Functions + \row + \o QPainter::strokePath(const QPainterPath & path, const QPen & pen) + \row + \o QPainter::drawPath(const QPainterPath & path) + \row + \o QPainter::fillPath(const QPainterPath & path, const QBrush & brush) + \row + \o QPainter::drawPoints(const QPointF * points, int pointCount) + \row + \o QPainter::drawEllipse(const QRectF & rectangle) + \row + \o QPainter::drawPolygon(const QPointF * points, int pointCount, + Qt::FillRule fillRule = Qt::OddEvenFill) + \row + \o QPainter::drawText(const QPointF & position, const QString & text) + \row + \o QGradient + \endtable + +\section2 Avoiding fallbacks +To avoid fallbacks make sure that the following points are true: + +\list + \o QPen::isSolid() returns true and uses a color with a one pixel +width. (QPen::width() returns 1. + \o QTransform::TransformationType() <= QTransform::TxScale are not +supported. + \o Clipping must be a simple rectangle or a QRegion. +\endlist + +\section2 When painting images +\note You should use QPixmap instead of QImage. QImages are drawn by +the QRasterPaintEngine. To get a warning for every fallback to the +QRasterPaintEngine, use QT_DIRECTFB_WARN_ON_RASTERFALLBACKS. If +QT_DIRECTFB_DISABLE_RASTERFALLBACKS is defined, DirectFB will only return +instead of falling back to QRasterPaintEngine. Please note that these +defines should only be used when optimizing the application. + +*/ diff --git a/doc/src/platforms/emb-hardwareacceleration.qdocinc b/doc/src/platforms/emb-hardwareacceleration.qdocinc new file mode 100644 index 0000000..3851628 --- /dev/null +++ b/doc/src/platforms/emb-hardwareacceleration.qdocinc @@ -0,0 +1,129 @@ + +\section1 Hardware Acceleration + +When designing applications for embedded devices the choice often stands +between graphics effects and performance. On most devices, you cannot have +both simply because the hardware needed for such operations just is not +there. Still a growing number of devices use hardware dedicated to graphics +operations to improve performance. + +Using graphics acceleration hardware is more power efficient than using the +CPU. The reason for this is that the CPU might require a clock speed that +is up to 20 times higher than the GPU, achieving the same results. E.g. a +typical hardware accelerated mobile graphics unit can rasterize one or two +bilinear texture fetches in one cycle, while a software implementation +takes easily more than 20 cycles. Graphics hardware generally have a much +lower clock speed and memory bandwidth and different level of acceleration +than desktop GPUs. One example is that many GPUs leave out transformation +and lighting from the graphics pipeline and only implements rasterization. + +So the key to write good applications for devices is therefore to limit the +wow factor down to what the target hardware can handle, and to take +advantage of any graphics dedicated hardware. Qt provides several ways to +both render advanced effects on the screen and speed up your application +using hardware accelerated graphics. + +\tableofcontents + +\section2 Qt for Embedded Graphics pipeline + +Qt uses QPainter for all graphics operations. By using the same API +regardless of platform, the code can be reused on different devices. +QPainter use different paint engines implemented in the QPaintEngine API to +do the actual painting. + +The QPaintEngine API provides paint engines for each window system and +painting framework supported by Qt. In regards to Qt for Embedded, this +also includes implementations for OpenGL ES versions 1.1 and 2.0, as well +as OpenVG and DirectFB(Embedded Linux only). + +By using one of these paint engines, you will be able to improve the +graphics performance of your Qt application. However, if the graphics +operations used are not supported, this might as well be a trap, slowing +down your application significantly. This all depends on what kind of +graphics operations that are supported by the target devices hardware +configuration. + +\image platformHWAcc.png + +The paint engine will direct all graphics operations supported by the +devices hardware to the GPU, and from there they are sent to the +framebuffer. Unsupported graphics operations falls back to the +QRasterPaintEngine and are handled by the CPU before sent to the +framebuffer. In the end, the operating system sends the paint updates off +to the screen/display. The fallback operation is quite expensive in regards +to memory consumption, and should be avoided. + +\section2 Hardware configuration requirements + +Before implementing any application using hardware acceleration, it is wise +to get an overview of what kind of hardware accelerated graphics operations +that are available for the target device. + +\note On devices with no hardware acceleration, Qt will use +QRasterPaintEngine, which handles the acceleration using software. On +devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows +CE), Qt will use the +respective paint engines to accelerate painting. However, hardware +configurations that only support a limited set of hardware acceleration +features, might slow the application graphics down rather than speeding it +up when using unsupported operations that must fall back to the raster +engine. + +\section3 Different architectures + +Based on the architecture used in a device we can make a recommendation on +which hardware acceleration techniques to use. There are mainly two +different architectures on embedded devices. These are devices with a +Unified Memory Architecture (UMA), and devices with dedicated graphics +memory. Generally, high-end devices will have dedicated graphics memory. +Low-end devices will just use system memory, sometimes reserving a memory +region and sometimes not. + +In addition to this, we can categorize the devices into five types based on +the different graphics operations supported by their hardware. + +\list 1 + \o No support for graphics acceleration. + \o Support for blitter and alpha blending. + \o Support for path based 2D vector graphics. + \o Support for fixed function 3D graphics. + \o Support for programmable 3D graphics. +\endlist + +Based on these characteristics the table below recommends which paint +engines to use with the different types of hardware configurations. + +\section3 Recommended use of hardware acceleration based on hardware + + \table + \header + \o Type + \o UMA + \o Non-UMA + \row + \o \bold {None} + \o Qt Raster Engine + \o Qt Raster Engine + \row + \o \bold {Blitter} + \o DirectFB + \o DirectFB + \row + \o \bold {2D Vector} + \o OpenVG + \o OpenVG + \row + \o \bold {Fixed 3D} + \o OpenGL (ES) 1.x + \o OpenGL (ES) 1.x + \row + \o \bold {Programmable 3D} + \o OpenGL (ES) 2.x + \o OpenGL (ES) 2.x + + \endtable + +\note Since the DirectFB API is quite primitive, the raster paint engine +handles most of the operations. +\note Blitter and Alpha blending is currently not supported on Windows CE. diff --git a/doc/src/platforms/emb-opengl.qdoc b/doc/src/platforms/emb-opengl-EmbLinux.qdoc index 2ed5d04..bede2ca 100644 --- a/doc/src/platforms/emb-opengl.qdoc +++ b/doc/src/platforms/emb-opengl-EmbLinux.qdoc @@ -40,31 +40,24 @@ ****************************************************************************/ /*! -\page qt-embedded-opengl.html +\page qt-embeddedLinux-opengl.html \title Qt for Embedded Linux and OpenGL -\ingroup qt-embedded-linux -\section1 Introduction +\ingroup qt-embedded-linux -\l {http://www.opengl.org}{OpenGL} is an industry standard API for -2D/3D graphics. It provides a powerful, low-level interface between -software and acceleration hardware, and it is operating system and -window system independent. +\input platforms/emb-opengl.qdocinc -\l {http://www.khronos.org/opengles}{OpenGL ES} is a subset -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. +\section1 Using OpenGL with Qt for Embedded Linux +Qt for Embedded Linux provides support for integrating OpenGL ES for +drawing into a QGLWidget. 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. -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. +\note OpenGL rendering only works with QGLWidget under QWS. Regular +widgets cannot currently support it. -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. +\section2 Configure 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 @@ -72,58 +65,11 @@ 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 - -The \l {QtOpenGL module} offers classes that make it easy to draw 3D -graphics in GUI applications. The module API is cross-platform, so it -is also available on Windows, X11, and Mac OS X. - -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 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 -Compositing effects can be simulated by adjusting the opacity and -other parameters of the items within a QGraphicsView canvas on a -QGLWidget viewport. +Compositing effects can be simulated by adjusting the opacity and other +parameters of the items within a QGraphicsView canvas on a QGLWidget +viewport. While Qt for Embedded Linux does include a complete windowing system, using OpenGL to composite regular window surfaces can be quite difficult. @@ -135,23 +81,20 @@ which is why we do not recommend implementing that form of compositing. We intend to address this problem in future versions of Qt. \section1 Integrating OpenGL/ES into Qt for Embedded Linux - \section2 Reference Integration - -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. +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. \section2 Integrating Other Chipsets - -In this section we discuss the essential features of the reference +In this section, we discuss the essential features of the reference integration that need to be provided for any other chipset integration. The QtOpenGL module assumes that a QGLWidget can be represented -by a \c EGLNativeWindowType value in some underlying window system +by an \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. @@ -159,7 +102,7 @@ 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 +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. @@ -218,13 +161,4 @@ 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. -\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/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/emb-opengl.qdocinc b/doc/src/platforms/emb-opengl.qdocinc new file mode 100644 index 0000000..dac5379 --- /dev/null +++ b/doc/src/platforms/emb-opengl.qdocinc @@ -0,0 +1,85 @@ +\section1 Introduction + +\l {http://www.opengl.org}{OpenGL} is an industry standard API for +2D/3D graphics. It provides a powerful, low-level interface between +software and acceleration hardware, and it is operating system and +window system independent. \l {http://www.khronos.org/opengles}{OpenGL ES} +is a subset of the \l {http://www.opengl.org}{OpenGL} standard. Because it +is designed for use with embedded systems, it has a smaller, more +constrained API. + +\l {http://www.khronos.org/opengles/1_X}{OpenGL ES version 1.x} is designed for +fixed function hardware, while its successor \l +{http://www.khronos.org/opengles/2_X}{OpenGL ES version 2.x} is designed for +programmable hardware. It is worth noting that there is a significant +difference between the two, and that they are not compatible with each +other. OpenGL ES 1.x limits processing to a pre-defined set of fixed +options for drawing and lighting objects. OpenGL 2.x has a significantly +shorter graphics pipeline than 1.x. Instead of using function +transformation and a fragment pipeline, 2.x uses the \l +{http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf}{OpenGL +ES Shading Language (GLSL ES)}. Instead of using the pre-defined functions, +the programmer writes small shader programs telling the hardware in detail +how to render each object. + +The \l {QtOpenGL module} offers classes that make it easy to draw 3D +graphics in GUI applications using OpenGL ES. Qt provides a plugin that +integrates both OpenGL ES versions \l +{http://www.khronos.org/opengles/1_X}{1.x} and \l +{http://www.khronos.org/opengles/2_X}{2.x} with Qt for Embedded. However, +Qt for Embedded can be adapted to a wide range of OpenGL versions. + +To translate QPainter operations into OpenGL ES calls (there are actually +two subclasses, one for OpenGL/ES 1.1 and another for OpenGL/ES 2.0), Qt +uses a subclass of QPaintEngine. 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. + +\tableofcontents + +\section1 Using OpenGL ES with Qt +To use OpenGL-enabled widgets in a Qt for Embedded application, all that is +required is to subclass QGLWidget and draw into instances of the subclass +with standard OpenGL functions. The current implementation only +supports OpenGL ES and 2D painting within a QGLWidget. Using OpenGL ES to +accelerate regular widgets as well as compositing top-level windows with +OpenGL ES are not currently supported. These issues will be addressed in +future versions of Qt. + +\note 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.setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff); + view.setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff); + view.setViewportUpdateMode(QGraphicsView::FullViewportUpdate); + view.setFrameStyle(0); + 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. + +\note OpenGL ES 2.X does not support PBuffers, so QGLPixelBuffer will not +work. In this case, QGLFramebufferObject should be used instead. However, +OpenGL ES 1.X does not support Framebuffer objects, with the exception of +some OpenGL ES 1.X extensions. In this case, please use QGLPixelBuffer. + +\note 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. + diff --git a/doc/src/platforms/emb-openvg-EmbLinux.qdoc b/doc/src/platforms/emb-openvg-EmbLinux.qdoc new file mode 100644 index 0000000..abdb617 --- /dev/null +++ b/doc/src/platforms/emb-openvg-EmbLinux.qdoc @@ -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$ +** +****************************************************************************/ + +/*! +\page qt-embeddedLinux-openvg.html + +\title Qt for Embedded Linux and OpenVG + +\ingroup qt-embedded-linux + +\input platforms/emb-openvg.qdocinc + + + +*/ diff --git a/doc/src/platforms/emb-openvg.qdocinc b/doc/src/platforms/emb-openvg.qdocinc new file mode 100644 index 0000000..37ccb9c --- /dev/null +++ b/doc/src/platforms/emb-openvg.qdocinc @@ -0,0 +1,288 @@ +\section1 Introduction + +\l {http://www.khronos.org/openvg}{OpenVG} is a standard API from the +\l{http://www.khronos.org/openvg}{Khronos Group} for accelerated 2D vector +graphics and raster graphics. It 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/ES. + +\tableofcontents + +\section1 Using OpenVG with Qt +The QtOpenVG plugin provides support for OpenVG painting. OpenVG is +optimized for 2D vector operations, and closely matches the functionality +in QPainter. To translate QPainter operations into OpenVG calls, Qt uses a +subclass of QPaintEngine. Unlike with OpenGL ES, OpenVG can be used for +acceleration of regular widgets. It can therefore be an excellent substitute +for the default raster-based QPaintEngine on hardware that supports the +OpenVG API. + +\section2 Configure +OpenVG support can be enabled by passing the \c{-openvg} option to +configure. It is assumed that the following qmake variables are set to +appropriate values in the qmake.conf file for your platform: + + \list + \o QMAKE_INCDIR_OPENVG + \o QMAKE_LIBDIR_OPENVG + \o QMAKE_LIBS_OPENVG + \endlist + +Most OpenVG implementations are based on EGL, so the following variables +may also need to be set: + + \list + \o QMAKE_INCDIR_EGL + \o QMAKE_LIBDIR_EGL + \o QMAKE_LIBS_EGL + \endlist + +See \l{qmake Variable Reference} for more information on these variables. + +\section2 Supported OpenVG Engines + +Two kinds of OpenVG engines are currently supported: EGL based, and engines +built on top of OpenGL such as +\l{http://sourceforge.net/projects/shivavg}{ShivaVG}. EGL based engines are +preferred. + +It is assumed that the EGL implementation has some way to turn a +QWidget::winId() into an EGL rendering surface with +\c{eglCreateWindowSurface()}. If this is not the case, then modifications +may be needed to the code under \c{src/gui/egl} and +\c{src/plugins/graphicssystems/openvg} to accomodate the EGL +implementation. + +The ShivaVG graphics system under \c{src/plugins/graphicssystems/shivavg} +is an example of how to integrate a non-EGL implementation of OpenVG into +Qt. It is currently only supported with Qt/X11 and being an example only, +the resulting screen output may not be as good as with other OpenVG +engines. + +\section1 Using the OpenVG graphics system + +Once the graphics system plugin has been built and installed, applications +can be run as follows to use the plugin: + + \code + app -graphicssystem OpenVG + \endcode + +If ShivaVG is being used, then substitute \c ShivaVG instead of \c OpenVG +in the line above. + +If the plugin fails to load, try setting the \c QT_DEBUG_PLUGINS +environment variable to 1 and try again. Usually the plugin cannot be +loaded because Qt cannot locate it in the directory +\c{plugins/graphicssystems} within the Qt installation, or the dynamic +library path does not include the directory containing the system's \c +libOpenVG.so library. + +\section2 Supported features + +\table + \header + \o Feature + \o Description + + \row + \o Context modes + \o The default configuration is "single-context" mode, where a single +EGLContext object is used for all drawing, regardless of the surface. +Multiple EGLSurfaces are created, one for each window surface or pixmap. +eglMakeCurrent() is called with the same EGLContext every time, but a +different EGLSurface. + +Single-context mode is necessary for QPixmapData to be implemented in terms +of a VGImage. If single-context mode is not enabled, then QPixmapData will +use the fallback QRasterPixmapData implementation, which is less efficient +performance-wise. + +Single-context mode can be disabled with the QVG_NO_SINGLE_CONTEXT +define if the OpenVG engine does not support one context with multiple +surfaces. + + \row + \o Transformation matrices + \o All affine and projective transformation matrices are supported. + +QVGPaintEngine will use the engine to accelerate affine transformation +matrices only. When a projective transformation matrix is used, +QVGPaintEngine will transform the coordinates before passing them to the +engine. This will probably incur a performance penalty. + +Pixmaps and images are always transformed by the engine, because OpenVG +specifies that projective transformations must work for images. + +It is recommended that client applications should avoid using projective +transformations for non-image elements in performance critical code. + + \row + \o Composition modes + \o The following composition modes are supported: + +\list +\o QPainter::CompositionMode_SourceOver +\o QPainter::CompositionMode_DestinationOver +\o QPainter::CompositionMode_Source +\o QPainter::CompositionMode_SourceIn +\o QPainter::CompositionMode_DestinationIn +\o QPainter::CompositionMode_Plus +\o QPainter::CompositionMode_Multiply +\o QPainter::CompositionMode_Screen +\o QPainter::CompositionMode_Darken +\o QPainter::CompositionMode_Lighten +\endlist + +The other members of QPainter::CompositionMode are not supported +because OpenVG 1.1 does not have an equivalent in its \c VGBlendMode +enumeration. Any attempt to set an unsupported mode will result in +the actual mode being set to QPainter::CompositionMode_SourceOver. +Client applications should avoid using unsupported modes. + + \row + \o Pens and brushes + \o All pen styles are supported, including cosmetic pens. + +All brush styles are supported except for conical gradients, which are not +supported by OpenVG 1.1. Conical gradients will be converted into a solid +color brush corresponding to the first color in the gradient's color ramp. + +Affine matrices are supported for brush transforms, but not projective +matrices. + + + \row + \o Rectangles, lines, and points + \o Rectangles, lines, and rounded rectangles use cached VGPath +objects to try to accelerate drawing operations. vgModifyPathCoords() is +used to modify the co-ordinates in the cached VGPath object each time +fillRect(), drawRects(), drawLines(), or drawRoundedRect() is called. + +If the engine does not implement vgModifyPathCoords() properly, then the +QVG_NO_MODIFY_PATH define can be set to disable path caching. This will +incur a performance penalty. + +Points are implemented as lines from the point to itself. The cached line +drawing VGPath object is used when drawing points. + + \row + \o Polygons and Ellipses + \o Polygon and ellipse drawing creates a new VGPath object every +time drawPolygon() or drawEllipse() is called. If the client application +is making heavy use of these functions, the constant creation and +destruction of VGPath objects could have an impact on performance. + +If a projective transformation is active, ellipses are converted into cubic +curves prior to transformation, which may further impact performance. + +Client applications should avoid polygon and ellipse drawing in performance +critical code if possible. + + \row + \o Other Objects + \o Most other objects (arcs, pies, etc) use drawPath(), which takes +a QPainterPath argument. The default implementation in QPainterEngineEx +converts the QPainterPath into a QVectorPath and then calls draw(), which +in turn converts the QVectorPath into a VGPath for drawing. + +To reduce the overhead, we have overridden drawPath() in QVGPaintEngine to +convert QPainterPath's directly into VGPath's. This should help improve +performance compared to the default implementation. + +Client applications should try to avoid these types of objects in +performance critical code because of the QPainterPath to VGPath conversion +cost. + + \row + \o Clipping + \o Clipping with QRect, QRectF, and QRegion objects is supported on +all OpenVG engines with vgMask() if the transformation matrix is the +identity or a simple origin translation. + +Clipping with an arbitrary QPainterPath, or setting the clip region when +the transformation matrix is simple, is supported only if the OpenVG engine +has the vgRenderToMask() function (OpenVG 1.1 and higher). + +The QVG_NO_RENDER_TO_MASK define will disable the use of vgRenderToMask(). + +The QVG_SCISSOR_CLIP define will disable clipping with vgMask() or +vgRenderToMask() and instead use the scissor rectangle list to perform +clipping. Clipping with an arbitrary QPainterPath will not be supported. + +The QVG_SCISSOR_CLIP define should only be used if the OpenVG engine does +not support vgMask() or vgRenderToMask(). + + \row + \o Opacity + \o Opacity is supported for all drawing operations. Solid color +pens, solid color brushes, gradient brushes, and image drawing with +drawPixmap() and drawImage() will probably have the best performance +compared to other kinds of pens and brushes. + + \row + \o Text Drawing + \o If OpenVG 1.1 is used, the paint engine will use VG fonts to +cache glyphs while drawing. If the engine does not support VG fonts +correctly, QVG_NO_DRAW_GLYPHS can be defined to disable this mode. Text +drawing performance will suffer if VG fonts are not used. + +By default, image-based glyphs are used. If QVG_NO_IMAGE_GLYPHS is defined, +then path-based glyphs will be used instead. QVG_NO_IMAGE_GLYPHS is ignored +if QVG_NO_DRAW_GLYPHS is defined. + +If path-based glyphs are used, then the OpenVG engine will need to support +hinting to render text with good results. Image-based glyphs avoids the +need for hinting and will usually give better results than path-based +glyphs. + + \row + \o Pixmaps + \o In single-context mode, pixmaps will be implemented using +VGImage unless QVG_NO_PIXMAP_DATA is defined. + +QVGPixmapData will convert QImage's into VGImage's when the application +calls drawPixmap(), and the pixmap will be kept in VGImage form for the +lifetime of the QVGPixmapData object. When the application tries to paint +into a QPixmap with QPainter, the data will be converted back into a QImage +and the raster paint engine will be used to render into the QImage. + +This arrangement optimizes for the case of drawing the same static pixmap +over and over (e.g. for icons), but does not optimize the case of drawing +into pixmaps. + +Bitmaps must use QRasterPixmapData. They are not accelerated with VGImage +at present. + + \row + \o Pixmap filters + \o Convolution, colorize, drop shadow, and blur filters are +accelerated using OpenVG operations. + +\endtable + +\section2 Known issues + +Performance of copying the contents of an OpenVG-rendered window to the +screen needs platform-specific work in the QVGWindowSurface class. + +Clipping with arbitrary non-rectangular paths only works on engines that +support vgRenderToMask(). Simple rectangular paths are supported on all +engines that correctly implement vgMask(). + +The paint engine is not yet thread-safe, so it is not recommended for use +in threaded Qt applications that draw from multiple threads. Drawing should +be limited to the main GUI thread. + +Performance of projective matrices for non-image drawing is not as good +as for affine matrices. + +QPixmap's are implemented as VGImage objects so that they can be quickly +rendered with drawPixmap(). Rendering into a QPixmap using QPainter will +use the default Qt raster paint engine on a QImage copy of the QPixmap, and +will not be accelerated. This issue may be addressed in a future version +of the engine. + +ShivaVG support is highly experimental and limited to Qt/X11. It is +provided as an example of how to integrate a non-EGL engine. + diff --git a/doc/src/platforms/qt-embedded-linux.qdoc b/doc/src/platforms/qt-embedded-linux.qdoc index 21cbf3b..a6524d7 100644 --- a/doc/src/platforms/qt-embedded-linux.qdoc +++ b/doc/src/platforms/qt-embedded-linux.qdoc @@ -96,7 +96,7 @@ \o \l {Qt for Embedded Linux Pointer Handling}{Pointer Handling} \o \l {Qt for Embedded Linux Character Input}{Character Input} \o \l {Qt for Embedded Linux Display Management}{Display Management} - \o \l {Qt for Embedded Linux and OpenGL}{OpenGL} + \o \l {Qt for Embedded Linux Hardware Accelerated Graphics}{Hardware Accelerated Graphics} \o \l {Qt for Embedded Linux Fonts}{Fonts} \endlist diff --git a/doc/src/platforms/qt-embedded.qdoc b/doc/src/platforms/qt-embedded.qdoc index e0c35cc..b38c94f 100644 --- a/doc/src/platforms/qt-embedded.qdoc +++ b/doc/src/platforms/qt-embedded.qdoc @@ -67,7 +67,7 @@ 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{Symbian platform - Introduction to using Qt}{Qt for the Symbian + \o \l{Symbian Platform - Introduction to 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 diff --git a/doc/src/platforms/s60-introduction.qdoc b/doc/src/platforms/s60-introduction.qdoc index 5fd0cbe..0581982 100644 --- a/doc/src/platforms/s60-introduction.qdoc +++ b/doc/src/platforms/s60-introduction.qdoc @@ -42,7 +42,7 @@ /*! \page symbian-with-qt-introduction.html - \title Symbian platform - Introduction to using Qt + \title Symbian Platform - Introduction to Qt \brief An introduction to Qt for Symbian platform developers. \ingroup howto \ingroup qts60 @@ -51,15 +51,15 @@ \section1 Required tools - See \l{Qt for Symbian platform Requirements} to see what tools are + 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 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 the Symbian platform from a Binary Package} + to learn how to install Qt using a binary package and how to build and run Qt demos. - Follow the instructions found in \l{Installing Qt on the Symbian platform} 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 diff --git a/doc/src/platforms/wince-introduction.qdoc b/doc/src/platforms/wince-introduction.qdoc index 46ecbf6..886b084 100644 --- a/doc/src/platforms/wince-introduction.qdoc +++ b/doc/src/platforms/wince-introduction.qdoc @@ -65,7 +65,7 @@ \endlist \o \list - \o \l {Windows CE OpenGL ES}{OpenGL ES} + \o \l {Qt for Windows CE Hardware Accelerated Graphics}{Hardware Accelerated Graphics} \o \l {Qt Performance Tuning} \o \l {Fine-Tuning Features in Qt} \endlist diff --git a/doc/src/platforms/wince-opengl.qdoc b/doc/src/platforms/wince-opengl.qdoc index 4fc4d7b..0ea2ec6 100644 --- a/doc/src/platforms/wince-opengl.qdoc +++ b/doc/src/platforms/wince-opengl.qdoc @@ -41,58 +41,48 @@ /*! \page windowsce-opengl.html - \title Windows CE OpenGL ES + \title Qt for Windows CE and OpenGL ES \ingroup qtce \brief Information about support for OpenGL ES with Qt for Windows CE. - \section1 Introduction + \input platforms/emb-opengl.qdocinc - \l {http://www.opengl.org}{OpenGL} is an industry standard API for 2D/3D - graphics. It provides a powerful, low-level interface between software - and acceleration hardware, and it is operating system and window system - independent. +\section1 Using OpenGL with Qt for Windows CE +Qt for Windows CE uses EGL 1.1 to embed OpenGL ES windows within the +Windows CE window manager. - \l {http://www.khronos.org/opengles}{OpenGL ES} is a subset of the - \l {http://www.opengl.org}{OpenGL} standard. It is meant for use in - embedded systems. Hence, it has a smaller, more constrained API. +\section2 Configure - Qt for Windows CE uses EGL 1.1 to embed OpenGL ES windows within the - Windows CE window manager. +To configure Qt for Windows Mobile 5.0 and OpenGL ES Common Lite support +you can run \c{configure} like this: - To use OpenGL ES enabled widgets in a Qt for Windows CE application, you - only need to subclass QGLWidget and draw on instances of the subclass with - OpenGL ES functions. - - OpenGL ES includes profiles for floating-point and fixed-point arithmetic. - The floating point profile is called OpenGL ES CM (Common) and the - fixed-point profile is called OpenGL ES CL (Common Lite). - - You can run \c{configure} with the \c{-opengl-es-cm} option for the Common - profile or \c{-opengl-es-cl} for the Common Lite profile. In both cases, - ensure that the \c{lib} and \c{includes} paths include the OpenGL ES - headers and libararies from your SDK. The OpenGL ES lib should be called - either \c{libGLES_CM.lib} for the Common profile or \c{libGLES_CL.lib} - for the Common Lite profile. + \snippet doc/src/snippets/code/doc_src_wince-opengl.qdoc 0 - To configure Qt for Windows Mobile 5.0 and OpenGL ES Common Lite support - you can run \c{configure} like this: +OpenGL ES includes profiles for floating-point and fixed-point arithmetic. +The floating point profile is called OpenGL ES CM (Common) and the +fixed-point profile is called OpenGL ES CL (Common Lite). - \snippet doc/src/snippets/code/doc_src_wince-opengl.qdoc 0 +You can run \c{configure} with the \c{-opengl-es-cm} option for the Common +profile or \c{-opengl-es-cl} for the Common Lite profile. In both cases, +ensure that the \c{lib} and \c{includes} paths include the OpenGL ES +headers and libararies from your SDK. The OpenGL ES lib should be called +either \c{libGLES_CM.lib} for the Common profile or \c{libGLES_CL.lib} for +the Common Lite profile. - The distinction between the Common and Common Lite profiles is important, - because the Common Lite profile has less functionality and only supports a - fixed-point vertex format. +The distinction between the Common and Common Lite profiles is important, +because the Common Lite profile has less functionality and only supports a +fixed-point vertex format. - To start programming with Qt and OpenGL ES on Windows CE, you can start - with the \l{Hello GL ES Example}. This example shows how to use QGLWidget - and QGLPainter with OpenGL ES. It also provides some hints on how to port - OpenGL code to OpenGL ES. +To start programming with Qt and OpenGL ES on Windows CE, you can start +with the \l{Hello GL ES Example}. This example shows how to use QGLWidget +and QGLPainter with OpenGL ES. It also provides some hints on how to port +OpenGL code to OpenGL ES. - \section2 Using OpenGL to Accelerate Normal 2D Painting +\section2 Using OpenGL to Accelerate Normal 2D Painting - Qt provides QOpenGLPaintEngine, a subclass of QPaintEngine that translates - QPainter operations into OpenGL calls. This is especially convenient for - drawing text or QImage objects in an OpenGL ES context. For further - details, refer to the \l{Hello GL ES Example}. +Qt provides QOpenGLPaintEngine, a subclass of QPaintEngine that translates +QPainter operations into OpenGL calls. This is especially convenient for +drawing text or QImage objects in an OpenGL ES context. For further +details, refer to the \l{Hello GL ES Example}. */ diff --git a/doc/src/platforms/wince-openvg.qdoc b/doc/src/platforms/wince-openvg.qdoc new file mode 100644 index 0000000..047c655 --- /dev/null +++ b/doc/src/platforms/wince-openvg.qdoc @@ -0,0 +1,65 @@ +/**************************************************************************** +** +** 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$ +** +****************************************************************************/ + +/*! + \page windowsce-openvg.html + \title Qt for Windows CE and OpenVG + \ingroup qtce + \brief Information about support for OpenVG with Qt for Windows CE. + + \input platforms/emb-openvg.qdocinc + +\section1 Using OpenVG with Qt for Windows CE +Qt for Windows CE uses EGL 1.1 to embed OpenVG windows within the Windows +CE window manager. + +\note Make sure that your Windows CE SDK have a working EGL implementation. +If not, OpenVG will not work. + +\note There is currently no support for Blitting and Alpha blending in Qt +for Windows CE. + +\note To configure Qt for Windows Mobile 5.0 and OpenVG support you can run +\c{configure} like this: + + \snippet doc/src/snippets/code/doc_src_wince-opengl.qdoc 0 + +*/ diff --git a/doc/src/platforms/winsystem.qdoc b/doc/src/platforms/winsystem.qdoc index f427d6e..72e7da6 100644 --- a/doc/src/platforms/winsystem.qdoc +++ b/doc/src/platforms/winsystem.qdoc @@ -43,6 +43,7 @@ \page winsystem.html \title Window System Specific Notes \ingroup platform-specific + \brief Collections of notes about Qt implementations on different window systems. Qt is a cross-platform GUI toolkit, so almost the entire API is the same on all platforms and window systems. If you wish to use @@ -95,4 +96,15 @@ When compiling for this platform, the macro \c{Q_WS_QWS} is defined (the window system is literally the Qt Window System). See the \l{Qt for Embedded Linux} documentation for more information. + + \section1 Qt for Windows CE + + When compiling for this platform, the macro \c{Q_WS_WINCE} is defined. + See the \l{Qt for Windows CE} documentation for more information. + + \section1 Qt for Symbian Platform + + When compiling for this platform, the macro \c{Q_WS_S60} is defined. + See the \l{Symbian Platform - Introduction to Qt} documentation for + more information. */ diff --git a/doc/src/qt4-intro.qdoc b/doc/src/qt4-intro.qdoc index 4943984..4911426 100644 --- a/doc/src/qt4-intro.qdoc +++ b/doc/src/qt4-intro.qdoc @@ -664,7 +664,7 @@ See the \l{QtMultimedia Module} documentation for more information. - \section1 New Classes, Functions, Macros, etc + \section1 New Classes, Functions, Macros, etc. Links to new classes, functions, macros, and other items introduced in Qt 4.6. diff --git a/doc/src/snippets/code/src_corelib_tools_qbytearray.cpp b/doc/src/snippets/code/src_corelib_tools_qbytearray.cpp index e87408a..52fbd1a 100644 --- a/doc/src/snippets/code/src_corelib_tools_qbytearray.cpp +++ b/doc/src/snippets/code/src_corelib_tools_qbytearray.cpp @@ -234,7 +234,7 @@ ba.indexOf("X"); // returns -1 //! [23] QByteArray x("crazy azimuths"); -QByteArray y("azy"); +QByteArray y("az"); x.lastIndexOf(y); // returns 6 x.lastIndexOf(y, 6); // returns 6 x.lastIndexOf(y, 5); // returns 2 diff --git a/doc/src/snippets/code/src_opengl_qglshaderprogram.cpp b/doc/src/snippets/code/src_opengl_qglshaderprogram.cpp index 2997297..9a15f19 100644 --- a/doc/src/snippets/code/src_opengl_qglshaderprogram.cpp +++ b/doc/src/snippets/code/src_opengl_qglshaderprogram.cpp @@ -40,32 +40,32 @@ ****************************************************************************/ //! [0] -QGLShader shader(QGLShader::VertexShader); -shader.compile(code); +QGLShader shader(QGLShader::Vertex); +shader.compileSourceCode(code); QGLShaderProgram program(context); program.addShader(shader); program.link(); -program.enable(); +program.bind(); //! [0] //! [1] -program.addShader(QGLShader::VertexShader, +program.addShaderFromSourceCode(QGLShader::Vertex, "attribute highp vec4 vertex;\n" "attribute mediump mat4 matrix;\n" "void main(void)\n" "{\n" " gl_Position = matrix * vertex;\n" "}"); -program.addShader(QGLShader::FragmentShader, +program.addShaderFromSourceCode(QGLShader::Fragment, "uniform mediump vec4 color;\n" "void main(void)\n" "{\n" " gl_FragColor = color;\n" "}"); program.link(); -program.enable(); +program.bind(); int vertexLocation = program.attributeLocation("vertex"); int matrixLocation = program.attributeLocation("matrix"); @@ -84,9 +84,12 @@ QColor color(0, 255, 0, 255); QMatrix4x4 pmvMatrix; pmvMatrix.ortho(rect()); +program.enableAttributeArray(vertexLocation); program.setAttributeArray(vertexLocation, triangleVertices, 3); program.setUniformValue(matrixLocation, pmvMatrix); program.setUniformValue(colorLocation, color); glDrawArrays(GL_TRIANGLES, 0, 3); + +program.disableAttributeArray(vertexLocation); //! [2] diff --git a/doc/src/snippets/statemachine/main2.cpp b/doc/src/snippets/statemachine/main2.cpp index 2419dc2..9a2890f 100644 --- a/doc/src/snippets/statemachine/main2.cpp +++ b/doc/src/snippets/statemachine/main2.cpp @@ -69,17 +69,18 @@ int main(int argv, char **args) //![1] QButton *interruptButton = new QPushButton("Interrupt Button"); + QWidget *mainWindow = new QWidget(); //![3] QHistoryState *s1h = new QHistoryState(s1); QState *s3 = new QState(); s3->assignProperty(label, "text", "In s3"); - QMessageBox mbox; - mbox.addButton(QMessageBox::Ok); - mbox.setText("Interrupted!"); - mbox.setIcon(QMessageBox::Information); - QObject::connect(s3, SIGNAL(entered()), &mbox, SLOT(exec())); + QMessageBox *mbox = new QMessageBox(mainWindow); + mbox->addButton(QMessageBox::Ok); + mbox->setText("Interrupted!"); + mbox->setIcon(QMessageBox::Information); + QObject::connect(s3, SIGNAL(entered()), mbox, SLOT(exec())); s3->addTransition(s1h); machine.addState(s3); diff --git a/doc/src/snippets/statemachine/main5.cpp b/doc/src/snippets/statemachine/main5.cpp index a9d4091..ff25b7b 100644 --- a/doc/src/snippets/statemachine/main5.cpp +++ b/doc/src/snippets/statemachine/main5.cpp @@ -44,14 +44,13 @@ int main(int argv, char **args) { QApplication app(argv, args); + QWidget *button; { //![0] QStateMachine machine; machine.setGlobalRestorePolicy(QStateMachine::RestoreProperties); -//![0] -//![1] QState *s1 = new QState(); s1->assignProperty(object, "fooBar", 1.0); machine.addState(s1); @@ -59,7 +58,7 @@ int main(int argv, char **args) QState *s2 = new QState(); machine.addState(s2); -//![1] +//![0] } { @@ -110,21 +109,50 @@ int main(int argv, char **args) } { + QMainWindow *mainWindow = 0; //![5] + QMessageBox *messageBox = new QMessageBox(mainWindow); + messageBox->addButton(QMessageBox::Ok); + messageBox->setText("Button geometry has been set!"); + messageBox->setIcon(QMessageBox::Information); + QState *s1 = new QState(); - s1->assignProperty(button, "geometry", QRectF(0, 0, 50, 50)); QState *s2 = new QState(); + s2->assignProperty(button, "geometry", QRectF(0, 0, 50, 50)); + connect(s2, SIGNAL(entered()), messageBox, SLOT(exec())); - s1->addTransition(s1, SIGNAL(polished()), s2); + s1->addTransition(button, SIGNAL(clicked()), s2); //![5] - } { + QMainWindow *mainWindow = 0; + +//![6] + QMessageBox *messageBox = new QMessageBox(mainWindow); + messageBox->addButton(QMessageBox::Ok); + messageBox->setText("Button geometry has been set!"); + messageBox->setIcon(QMessageBox::Information); + + QState *s1 = new QState(); + + QState *s2 = new QState(); + s2->assignProperty(button, "geometry", QRectF(0, 0, 50, 50)); + + QState *s3 = new QState(); + connect(s3, SIGNAL(entered()), messageBox, SLOT(exec())); + s1->addTransition(button, SIGNAL(clicked()), s2); + s2->addTransition(s2, SIGNAL(propertiesAssigned()), s3); //![6] + + } + + { + +//![7] QState *s1 = new QState(); QState *s2 = new QState(); @@ -134,10 +162,12 @@ int main(int argv, char **args) QStateMachine machine; machine.setInitialState(s1); machine.addDefaultAnimation(new QPropertyAnimation(object, "fooBar")); -//![6] +//![7] } + + return app.exec(); } |
