diff options
author | Thiago Macieira <thiago.macieira@nokia.com> | 2009-11-10 18:15:09 (GMT) |
---|---|---|
committer | Thiago Macieira <thiago.macieira@nokia.com> | 2009-11-10 18:15:09 (GMT) |
commit | cd4cab01810b817cdf8eb80ab9fc3174a798dd10 (patch) | |
tree | a849171a850e91851e871544d1e49a56484d37c7 /doc | |
parent | d895af5713a7b7ee011b2b29cb5844fbf964df5e (diff) | |
parent | 7005ca9f0f6b1e535ad2b26d3fcf46dffacc3f13 (diff) | |
download | Qt-cd4cab01810b817cdf8eb80ab9fc3174a798dd10.zip Qt-cd4cab01810b817cdf8eb80ab9fc3174a798dd10.tar.gz Qt-cd4cab01810b817cdf8eb80ab9fc3174a798dd10.tar.bz2 |
Merge branch '4.6'
Conflicts:
src/gui/styles/qcommonstyle.cpp
tools/assistant/lib/lib.pro
tools/assistant/lib/qhelp_global.cpp
tools/assistant/tools/assistant/assistant.qch
tools/assistant/tools/assistant/mainwindow.cpp
Diffstat (limited to 'doc')
47 files changed, 2067 insertions, 641 deletions
diff --git a/doc/src/development/qmake-manual.qdoc b/doc/src/development/qmake-manual.qdoc index 6c53242..9548848 100644 --- a/doc/src/development/qmake-manual.qdoc +++ b/doc/src/development/qmake-manual.qdoc @@ -2252,6 +2252,18 @@ For example: If the OpenGL implementation uses EGL (most OpenGL/ES systems), then QMAKE_INCDIR_EGL may also need to be set. + \section1 QMAKE_INCDIR_OPENGL_ES1, QMAKE_INCDIR_OPENGL_ES1CL, QMAKE_INCDIR_OPENGL_ES2 + + These variables contain the location of OpenGL headers files to be added + to INCLUDEPATH when building an application with OpenGL ES 1, OpenGL ES 1 Common + Lite or OpenGL ES 2 support respectively. + + The value of this variable is typically handled by \c qmake or + \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified. + + If the OpenGL implementation uses EGL (most OpenGL/ES systems), + then QMAKE_INCDIR_EGL may also need to be set. + \target QMAKE_INCDIR_OPENVG \section1 QMAKE_INCDIR_OPENVG @@ -2342,6 +2354,8 @@ For example: \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified. \section1 QMAKE_LFLAGS_RPATH + + \e {This is used on Unix platforms only.} Library paths in this definition are added to the executable at link time so that the added paths will be preferentially searched at runtime. @@ -2496,6 +2510,17 @@ For example: variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified. + \section1 QMAKE_LIBS_OPENGL_ES1, QMAKE_LIBS_OPENGL_ES1CL, QMAKE_LIBS_OPENGL_ES2 + + These variables contain all the OpenGL libraries for OpenGL ES 1, + OpenGL ES 1 Common Lite profile and OpenGL ES 2. + + The value of these variables is typically handled by \c qmake or + \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified. + + If the OpenGL implementation uses EGL (most OpenGL/ES systems), + then QMAKE_LIBS_EGL may also need to be set. + \section1 QMAKE_LIBS_OPENVG This variable contains all OpenVG libraries. The value of this @@ -2673,11 +2698,15 @@ For example: \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 45 \section1 QMAKE_RPATH + + \e {This is used on Unix platforms only.} Is equivalent to \l QMAKE_LFLAGS_RPATH. \section1 QMAKE_RPATHDIR + \e {This is used on Unix platforms only.} + A list of library directory paths, these paths are added to the executable at link time so that the paths will be preferentially searched at runtime. 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/googlesuggest.qdoc b/doc/src/examples/googlesuggest.qdoc index bec242d..ab8ab57 100644 --- a/doc/src/examples/googlesuggest.qdoc +++ b/doc/src/examples/googlesuggest.qdoc @@ -43,10 +43,152 @@ \example network/googlesuggest \title Google Suggest Example - The Google Suggest example shows how to use the network access manager - to get the list of suggested search terms from Google. + The Google Suggest example demonstrates how to use the QNetworkAccessManager + class to obtain a list of suggestions from the Google search engine as the + user types into a QLineEdit. \image googlesuggest-example.png - \note The Google Suggest suggestion service is a registered trademark of Google Inc. + The application makes use of the \c get function in + QNetworkAccessManager to post a request and obtain the result of the search + query sent to the Google search engine. The results returned are listed as + clickable links appearing below the search box as a drop-down menu. + + The widget is built up by a QLineEdit as the search box, and a QTreeView + used as a popup menu below the search box. + + \section1 GSuggestCompletion Class Declaration + + This class implements an event filter and a number of functions to display + the search results and to determent when and how to perform the search. + + \snippet examples/network/googlesuggest/googlesuggest.h 1 + + The class connects to a QLineEdit and uses a QTreeWidget to display the + results. A QTimer controls the start of the network requests that are + executed using a QNetworkAccessManager. + + \section1 GSuggestCompletion Class Implementation + + We start by defining a constant containing the URL to be used in the Google + queries. This is the basis for the query. The letters typed into the search + box will be added to the query to perform the search itself. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 1 + + In the constructor, we set the parent of this GSuggestCompletion instance + to be the QLineEdit passed in. For simplicity, the QLineEdit is also stored + in the explicit \c editor member variable. + + We then create a QTreeWidget as a toplevel widget and configure the various + properties to give it the look of a popup widget. + + The popup will be populated by the results returned from Google. We set + the number of columns to be two, since we want to display both the + suggested search term and the number of hits it will trigger in the search + engine. + + Furthermore, we install the GSuggestCompletion instance as an event filter + on the QTreeWidget, and connect the \c itemClicked() signal with the \c + doneCompletion() slot. + + A single-shot QTimer is used to start the request when the user has stopped + typing for 500 ms. + + Finally, we connect the networkManagers \c finished() signal with the \c + handleNetworkData() slot to handle the incoming data. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 2 + + Since the QTreeWidget popup has been instantiated as a toplevel widget, the + destructor has to delete it explicitly from memory to avoid a memory leak. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 3 + + The event filter handles mouse press and key press events that are + delivered to the popup. For mouse press events we just hide the popup and + return focus to the editor widget, and then return true to prevent further + event processing. + + Key event handling is implemented so that Enter and Return execute the + selected link, while the Escape key hides the popup. Sine we want to be + able to navigate the list of suggestions using the different navigation + keys on the keyboard we let Qt continue regular event processing for those + by returning false from the eventFilter reimplementation. + + For all other keys, the event will be passed on to the editor widget and the + popup is hidden. This way the user's typing will not be interrupted by the + popping up of the completion list. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 4 + + The \c showCompletion() function populates the QTreeWidget with the results + returned from the query. It takes two QStringLists, one with the suggested + search terms and the other with the corresponding number of hits. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 5 + + A QTreeWidgetItem is created for each index in the list and inserted into + the QTreeWidget. Finally, we adjust position and size of the popup to make + sure that it pops up in the correct position below the editor, and show it. + + The \c doneCompletion() function, which is called by the event filter when + either Enter or Return keys are pressed, stops the timer to prevent further + requests and passes the text of the selected item to the editor. We then + make the \c editor QLineEdit emit the returnPressed() signal, to which the + application can connect to open the respective web page. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 6 + + The \c autoSuggest() slot is called when the timer times out, and uses the + text in the editor to build the complete search query. The query is then + passed to the QNetworkAccessManager's \c get() function to start the + request. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 7 + + The function \c preventSuggest() stops the timer to prevent further + requests from being started. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 8 + + When the network request is finished, the QNetworkAccessManager delivers the + data received from the server through the networkReply object. + + \snippet examples/network/googlesuggest/googlesuggest.cpp 9 + + To extract the data from the reply we use the \c readAll() function, which + is inherited from QIODevice and returns a QByteArray. Since this data is + encoded in XML we can use a QXmlStreamReader to traverse the data and + extract the search result as QStrings, which we can stream into two + QStringLists used to populate the popup. + + Finally, we schedule the QNetworkReply object for deletion using the \c + deleteLater function. + + \section1 SearchBox Class Declaration + + The SearchBox class inherits QLineEdit and adds the protected slot \c + doSearch(). + + A \c GSuggestCompletion member provides the SearchBox with the request + functionality and the suggestions returned from the Google search engine. + + \snippet examples/network/googlesuggest/searchbox.h 1 + + \section1 SearchBox Class Implementation + + The search box constructor instantiates the GSuggestCompletion object and + connects the returnPressed() signal to the doSearch() slot. + + \snippet examples/network/googlesuggest/searchbox.cpp 1 + + The function \c doSearch() stops the completer from sending any further + queries to the search engine. + + Further, the function extracts the selected search phrase and opens it + in the default web browser using QDesktopServices. + + \snippet examples/network/googlesuggest/searchbox.cpp 2 + */ 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..c8e225c 100644 --- a/doc/src/getting-started/installation.qdoc +++ b/doc/src/getting-started/installation.qdoc @@ -39,10 +39,6 @@ ** ****************************************************************************/ -/**************************************************************************** -** Please remember to update the corresponding INSTALL files. -****************************************************************************/ - /*! \group installation \title Installation @@ -484,6 +480,7 @@ in the \l{Qt for Windows CE Requirements} document. \o \l{Windows CE - Introduction to using Qt} \o \l{Windows CE - Working with Custom SDKs} \o \l{Windows CE - Using shadow builds} + \o \l{Windows CE - Signing} \endlist Information on feature and performance tuning for embedded builds can @@ -498,10 +495,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 +524,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 +534,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 +542,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 +603,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 +612,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 +624,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 +951,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/googlesuggest-example.png b/doc/src/images/googlesuggest-example.png Binary files differindex 4ef072a..477d444 100644 --- a/doc/src/images/googlesuggest-example.png +++ b/doc/src/images/googlesuggest-example.png diff --git a/doc/src/images/graphicseffect-bloom.png b/doc/src/images/graphicseffect-bloom.png Binary files differdeleted file mode 100644 index dace7eb..0000000 --- a/doc/src/images/graphicseffect-bloom.png +++ /dev/null diff --git a/doc/src/images/graphicseffect-effects.png b/doc/src/images/graphicseffect-effects.png Binary files differdeleted file mode 100644 index 609bef9..0000000 --- a/doc/src/images/graphicseffect-effects.png +++ /dev/null diff --git a/doc/src/images/graphicseffect-grayscale.png b/doc/src/images/graphicseffect-grayscale.png Binary files differdeleted file mode 100644 index 8b6e5c6..0000000 --- a/doc/src/images/graphicseffect-grayscale.png +++ /dev/null diff --git a/doc/src/images/graphicseffect-pixelize.png b/doc/src/images/graphicseffect-pixelize.png Binary files differdeleted file mode 100644 index 57a0057..0000000 --- a/doc/src/images/graphicseffect-pixelize.png +++ /dev/null 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 e873f4e..ecc25fe 100644 --- a/doc/src/internationalization/i18n.qdoc +++ b/doc/src/internationalization/i18n.qdoc @@ -51,6 +51,7 @@ \page internationalization.html \title Internationalization with Qt \brief Information about Qt's support for internationalization and multiple languages. + \nextpage Writing Source Code for Translation \keyword internationalization \keyword i18n @@ -59,11 +60,11 @@ the application usable by people in countries other than one's own. \tableofcontents - + \section1 Relevant Qt Classes and APIs These classes support internationalizing of Qt applications. - + \annotatedlist i18n \section1 Languages and Writing Systems @@ -92,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) @@ -111,6 +112,7 @@ \o Tamil \o Telugu \o Tibetan + \o N'Ko \endlist Many of these writing systems exhibit special features: @@ -180,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, @@ -438,9 +440,13 @@ application language. The default event handler for QWidget subclasses responds to the - QEvent::LanguageChange event, and will call this function when necessary; - other application components can also force widgets to update themselves - by posting the \l{QEvent::LanguageChange}{LanguageChange} event to them. + QEvent::LanguageChange event, and will call this function when necessary. + + \l{QEvent::LanguageChange}{LanguageChange} events are posted when a new + translation is installed using the QCoreApplication::installTranslator() + function. Additionally, other application components can also force + widgets to update themselves by posting LanguageChange events to them. + \section1 Translating Non-Qt Classes @@ -516,3 +522,265 @@ For details on Mac-specific translation, refer to the Qt/Mac Specific Issues document \l{Qt for Mac OS X - Specific Issues#Translating the Application Menu and Native Dialogs}{here}. */ + +/*! + \page i18n-source-translation.html + \title Writing Source Code for Translation + \ingroup i18n + \previouspage Internationalization with Qt + \contentspage Internationalization with Qt + \nextpage Translation Rules for Plurals + \brief How to write source code in a way that makes it possible for user-visible text to be translated. + + \tableofcontents + + \section1 The Basics + + Developers use the \l{QObject::}{tr()} function to obtain translated text + for their classes, typically for display purposes. This function is also + used to indicate which text strings in an application are translatable. + + Qt indexes each translatable string by the \e{translation context} it is + associated with; this is generally the name of the QObject subclass it is + used in. + + Translation contexts are defined for new QObject-based classes by the use + of the Q_OBJECT macro in each new class definition. + + When tr() is called, it looks up the translatable string using a QTranslator + object. For translation to work, one or more of these must have been + installed on the application object in the way described in the + \l{#Enabling Translation}{Enabling Translation} section below. + + \section1 Defining a Translation Context + + The translation context for QObject and each QObject subclass is the + class name itself. Developers subclassing QObject must use the + Q_OBJECT macro in their class definition to override the translation + context. This macro sets the context to the name of the subclass. + + For example, the following class definition includes the Q_OBJECT macro, + implementing a new tr() that uses the \c MainWindow context: + + \snippet mainwindows/sdi/mainwindow.h class definition with macro + \dots + + If Q_OBJECT is not used in a class definition, the context will be + inherited from the base class. For example, since all QObject-based + classes in Qt provide a context, a new QWidget subclass defined without + a Q_OBJECT macro will use the \c QWidget context if its tr() function + is invoked. + + \section1 Using tr() to Obtain a Translation + + The following example shows how a translation is obtained for the + class shown in the previous section: + + \snippet mainwindows/sdi/mainwindow.cpp implicit tr context + \dots + + Here, the translation context is \c MainWindow because it is the + \c MainWindow::tr() function that is invoked. The text returned + by the tr() function is a translation of "&File" obtained from + the \c MainWindow context. + + When Qt's translation tool, \l lupdate, is used to process a set of source + files, the text wrapped in tr() calls is stored in a section of the translation + file that corresponds to its translation context. + + In some situations, it is useful to give a translation context explicitly + by fully qualifying the call to tr(); for example: + + \snippet doc/src/snippets/code/src_corelib_kernel_qobject.cpp explicit tr context + + This call obtains the translated text for "Page up" from the \c QScrollBar + context. Developers can also use the QCoreApplication::translate() function + to obtain a translation for a particular translation context. + + \section1 Translator Comments + + Developers can include information about each translatable string to + help translators with the translation process. These are extracted + when \l lupdate is used to process the source files. The recommended + way to add comments is to annotate the tr() calls in your code with + comments of the form: + + \tt{//: ...} + + or + + \tt{\begincomment: ... \endcomment} + + Examples: + + \snippet doc/src/snippets/code/src_corelib_kernel_qobject.cpp 40 + + In these examples, the comments will be associated with the strings + passed to tr() in the context of each call. + + \section1 Adding Meta-Data to Strings + + Additional data can be attached to each translatable message. These are + extracted when \l lupdate is used to process the source files. The + recommended way to add meta-data is to annotate the tr() calls in your code + with comments of the form: + + \tt{//= <id>} + + This can be used to give the message a unique identifier to support tools + which need it. + + An alternative way to attach meta-data is to use the following syntax: + + \tt{//~ <field name> <field contents>} + + This can be used to attach meta-data to the message. The field name should + consist of a domain prefix (possibly the conventional file extension of the + file format the field is inspired by), a hyphen and the actual field name + in underscore-delimited notation. For storage in TS files, the field name + together with the prefix "extra-" will form an XML element name. The field + contents will be XML-escaped, but otherwise appear verbatim as the + element's contents. Any number of unique fields can be added to each + message. + + Example: + + \snippet doc/src/snippets/code/src_corelib_kernel_qobject.cpp meta data + + Meta-data appearing right in front of a magic TRANSLATOR comment applies to + the whole TS file. + + \section1 Disambiguation + + If the same translatable string is used in different roles within the same + translation context, an additional identifying string may be passed in + the call to \l{QObject::}{tr()}. This optional disambiguation argument + is used to distinguish between otherwise identical strings. + + Example: + + \snippet doc/src/snippets/code/src_corelib_kernel_qobject.cpp 17 + \dots + + In Qt 4.4 and earlier, this disambiguation parameter was the preferred + way to specify comments to translators. + + \section1 Character Encodings + + You can set the encoding for the source text by calling QTextCodec::setCodecForTr(). + By default, the source text is assumed to be in Latin-1 encoding. + + \section1 Handling Plurals + + Some translatable strings contain placeholders for integer values and need + to be translated differently depending on the values in use. + + To help with this problem, developers pass an additional integer argument + to the \l{QObject::}{tr()} function, and typically use a special notation + for plurals in each translatable string. + + If this argument is equal or greater than zero, all occurrences of + \c %n in the resulting string are replaced with a decimal representation + of the value supplied. In addition, the translation used will adapt to the + value according to the rules for each language. + + Example: + + \snippet doc/src/snippets/code/src_corelib_kernel_qobject.cpp 18 + + The table below shows what string is returned depending on the + active translation: + + \table + \header \o \o{3,1} Active Translation + \header \o \a n \o No Translation \o French \o English + \row \o 0 \o "0 message(s) saved" \o "0 message sauvegard\unicode{0xE9}" \o "0 message\bold{s} saved" + \row \o 1 \o "1 message(s) saved" \o "1 message sauvegard\unicode{0xE9}" \o "1 message saved" + \row \o 2 \o "2 message(s) saved" \o "2 message\bold{s} sauvegard\unicode{0xE9}\bold{s}" \o "2 message\bold{s} saved" + \row \o 37 \o "37 message(s) saved" \o "37 message\bold{s} sauvegard\unicode{0xE9}\bold{s}" \o "37 message\bold{s} saved" + \endtable + + This idiom is more flexible than the traditional approach; e.g., + + \snippet doc/src/snippets/code/src_corelib_kernel_qobject.cpp 19 + + because it also works with target languages that have several + plural forms (e.g., Irish has a special "dual" form that should + be used when \c n is 2), and it handles the \e n == 0 case + correctly for languages such as French that require the singular. + See the \l{Qt Linguist Manual} for details. + + Instead of \c %n, you can use \c %Ln to produce a localized + representation of \a n. The conversion uses the default locale, + set using QLocale::setDefault(). (If no default locale was + specified, the "C" locale is used.) + + A summary of the rules used to translate strings containing plurals can be + found in the \l{Translation Rules for Plurals} document. + + \section1 Enabling Translation + + Typically, your application's \c main() function will look like + this: + + \snippet doc/src/snippets/code/doc_src_i18n.qdoc 8 + + Note the use of QLibraryInfo::location() to locate the Qt translations. + Developers should request the path to the translations at run-time by + passing QLibraryInfo::TranslationsPath to this function instead of + using the \c QTDIR environment variable in their applications. + + \section1 Further Reading + + \l{Qt Linguist Manual}, \l{Hello tr Example}, \l{Translation Rules for Plurals} +*/ + +/*! + \page i18n-plural-rules.html + \title Translation Rules for Plurals + \ingroup i18n + \previouspage Writing Source Code for Translation + \contentspage Internationalization with Qt + \brief A summary of the translation rules for plurals produced by Qt's i18n tools. + + The table below shows the specific rules that are produced by Qt Linguist + and \c lrelease for a selection of languages. Cells marked \e otherwise + indicate the form used when none of the other rules are appropriate for a + specific language. + + \table 80% + \header \o Language \o Rule 1 \o Rule 2 \o Rule 3 + \row \o English \o \c{n == 1} + \o \e{otherwise} \o N/A + \row \o French \o \c{n < 2} + \o \e{otherwise} \o N/A + \row \o Czech \o \c{n % 100 == 1} + \o \c{n % 100 >= 2 && n % 100 <= 4} + \o \e{otherwise} + \row \o Irish \o \c{n == 1} + \o \c{n == 2} \o \e{otherwise} + \row \o Latvian \o \c{n % 10 == 1&& n % 100 != 11} + \o \c{n != 0} \o \e{otherwise} + \row \o Lithuanian \o \c{n % 10 == 1&& n % 100 != 11} + \o \c{n % 100 != 12 && n % 10 == 2} + \o \e{otherwise} + \row \o Macedonian \o \c{n % 10 == 1} + \o \c{n % 10 == 2} \o \e{otherwise} + \row \o Polish \o \c{n == 1} + \o \c{n % 10 >= 2 && n % 10 <= 4 + && (n % 100 < 10 || n % 100 > 20)} + \o \e{otherwise} + \row \o Romanian \o \c{n == 1} + \o \c{n == 0|| (n % 100 >= 1 && n % 100 <= 20)} + \o \e{otherwise} + \row \o Russian \o \c{n % 10 == 1&& n % 100 != 11} + \o \c{n % 10 >= 2 && n % 10 <= 4 + && (n % 100 < 10 || n % 100 > 20)} + \o \e{otherwise} + \row \o Slovak \o \c{n == 1} \o \c{n >= 2 && n <= 4} + \o \e{otherwise} + \row \o Japanese \o \e{otherwise} \o N/A \o N/A + \endtable + + The rules themselves are not documented and are internal to Qt Linguist and \c lrelease. +*/ diff --git a/doc/src/internationalization/linguist-manual.qdoc b/doc/src/internationalization/linguist-manual.qdoc index 5d388f1..3e06a2f 100644 --- a/doc/src/internationalization/linguist-manual.qdoc +++ b/doc/src/internationalization/linguist-manual.qdoc @@ -62,7 +62,7 @@ software engineers and the translator. The chapter describes the use of two tools. The \l{lupdate} tool is used to synchronize source code and translations. The \l{lrelease} tool is used to - create runtime translation files for use by the released + create run-time translation files for use by the released application. The \l{linguist-translators.html}{Translators} chapter is for @@ -119,7 +119,7 @@ \o Phrases that contain variables, for example, "The 25 files selected will take 63 seconds to process", where the two numbers - are inserted programmatically at runtime may need to be reworded + are inserted programmatically at run-time may need to be reworded because in a different language the word order and therefore the placement of the variables may have to change. @@ -147,7 +147,7 @@ \row \o{1,2} \inlineimage wVista-Cert-border-small.png \o \e{Qt Linguist 4.3 is Certified for Windows Vista} - + \row \o Windows Vista and the Windows Vista Start button are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. @@ -508,7 +508,7 @@ translation. The state is reset to \inlineimage linguist-danger.png , and the number of accepted translations in the \e{Items} column of the \l{Context Window} {context list} is decremented by 1. - + \row \o Not Accepted \o \inlineimage linguist-check-off.png @@ -781,7 +781,7 @@ changed. Whichever character (alpha or digit) is chosen, the translation must be in the form "Ctrl+" followed by the upper case character. \e{Qt} will automatically display the correct name at - runtime. As with Alt key accelerators, if the translator changes + run-time. As with Alt key accelerators, if the translator changes the character, the new character must not conflict with any other Ctrl key accelerator. @@ -790,14 +790,14 @@ supported languages, \e {Qt} automatically translates these strings. - \section2 Handling Numbered Arguments + \section2 Handling Numbered Arguments and Plurals Some phrases contain numbered arguments. A numbered argument is a - placeholder that will be replaced with text at runtime. A numbered + placeholder that will be replaced with text at run-time. A numbered argument appears in a source string as a percent sign followed by a digit. Consider an example: \c{After processing file %1, file %2 is next in line}. In this string to be translated, \c{%1} and - \c{%2} are numbered arguments. At runtime, \c{%1} and \c{%2} will + \c{%2} are numbered arguments. At run-time, \c{%1} and \c{%2} will be replaced with the first and next file names respectively. The same numbered arguments must appear in the translation, but not necessarily in the same order. A German translation of the string @@ -808,336 +808,14 @@ of where argument \e{i} appears in the argument sequence in the source string. - \section2 Plurals - - The problem of plurals in output is resolved by using an overload of - the \c tr() function with the signature - \code - QString tr(const char *text, const char *comment, int n); - \endcode - Using built in comparisons for the value of \c n the tr() function will - translate the phrase to the plural form for the target language. - - Different languages have various forms for plurals beyond simply - \e singular and \e plural. The rules for determining which form of the - plural to use are encoded as conditional tests. Below is a table - representing the numbers associated with the forms rather than the - conditional tests themselves. - - - - \table 90% - \header - \o Language - \o Form 1 - \o Form 2 - \o Form 3 - \o Form 4 - \row - \o Arabic - \o 0, 1, 11-102, 111-202... - \o 2 - \o 3-10, 103-110, 203-210... - \o - \row - \o Basque - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Bulgarian - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Catalan - \o 1 - \o 11, 11 000-11 999, 11 000 000-11 999 999... - \o 0, 2-10, 12-10 999, 12-10 999 999... - \o - \row - \o Chinese-CN - \o 0- - \o - \o - \o - \row - \o Chinese-HK - \o 0- - \o - \o - \o - \row - \o Chinese-TW - \o 0- - \o - \o - \o - \row - \o Croation - \o 1, 21, 31, 41, 51, 61, 71, 81, 91, 101... - \o 2-4, 22-24, 32-34, 42-44... - \o 0, 5-20, 25-30, 35-40... - \o - \row - \o Czech - \o 1 - \o 2-4 - \o 0, 5- - \o - \row - \o Danish - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Dutch - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o English - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o English-US - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Estonian - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Finnish - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o French-CA - \o 0, 1 - \o 2-100, 101- - \o - \o - \row - \o French-FR - \o 0, 1 - \o 2-100, 101- - \o - \o - \row - \o Galician - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o German - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Greek - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Hebrew - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Hungarian - \o 0- - \o - \o - \o - \row - \o Icelandic - \o 1, 21, 31, 41, 51....101, 121, 131... - \o 0, 2-20, 22-30, 32-40...102-120... - \o - \o - \row - \o Indonesian - \o 0- - \o - \o - \o - \row - \o Italian - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Japanese - \o 0- - \o - \o - \o - \row - \o Korean - \o 0- - \o - \o - \o - \row - \o Latvian - \o 0 - \o 1, 21, 31, 41, 51, 61, 71, 81, 91, 101, 131, 141... - \o 2-20, 22-30, 32-40, 42-50...202-220, 222-230... - \o - \row - \o Lithuanian - \o 1, 21, 31, 41, 51...101, 121, 131... - \o 2-9, 22-29, 32-39...102-109, 122-129, 132-139... - \o 0, 10-20, 30, 40, 50...110-120, 130, 140... - \o - \row - \o Malay - \o 0- - \o - \o - \o - \row - \o Norwegian - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Persian - \o 0- - \o - \o - \o - \row - \o Polish - \o 1 - \o 2-4, 22-24, 32-34... - \o 5-21, 25-31, 35-41... - \o - \row - \o Portugese-BR - \o 0, 1 - \o 2-100, 101- - \o - \o - \row - \o Portugese-PT - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Romanian - \o 1 - \o 0, 2-19, 101-119, 201-219... - \o 20-100, 120-200, 220-300... - \o - \row - \o Russian - \o 1, 21, 31, 41, 51, 61, 71, 81, 91, 101... - \o 2-4, 22-24, 32-34... - \o 0, 5-20, 25-30, 35-40... - \o - \row - \o Serbian - \o 1, 21, 31, 41, 51, 61, 71, 81, 91, 101... - \o 2-4, 22-24, 32-34... - \o 0, 5-20, 25-30, 35-40... - \o - \row - \o Slovak - \o 1 - \o 2-4 - \o 0, 5-20, 25-30, 35-40... - \o - \row - \o Slovene - \o 1, 101, 201, 301... - \o 2, 102, 202, 302... - \o 3, 4, 103, 104, 203, 204, 303, 304... - \o 0, 5-100, 105-200, 205-300... - \row - \o Spanish-US - \o 1 - \o 0, 2- - \o - \o - \row - \o Spanish-ES - \o 1 - \o 0, 2- - \o - \o - \row - \o Swedish - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Tagalog - \o 0, 1 - \o 2, 3, 5, 7-8, 10-13, 15, 17-18, 20-23...101...1001 - \o 4, 6, 9, 14, 16, 19, 24, 26, 29...104, 106, 109... - \o - \row - \o Thai - \o 0- - \o - \o - \o - \row - \o Turkish - \o 0- - \o - \o - \o - \row - \o Ukrainian - \o 1, 21, 31, 41, 51, 61, 71, 81, 91, 101... - \o 2-4, 22-24, 32-34... - \o 0, 5-20, 25-30, 35-40... - \o - \row - \o Urdu - \o 1 - \o 0, 2-100, 101- - \o - \o - \row - \o Vietnamese - \o 0- - \o - \o - \o - \endtable - - These rules are embedded within the Qt libraries, there is no need for - the developer to know them. Merely to use the correct \c tr() call. - + The use of numbered arguments is often accompanied by the use of + plurals in the source text. In many languages, the form of the + text will depend on the value shown, and more than one translation + is required. If the developers have marked up the source text in + correct way, fields for each of the possible plural forms will be + available in the translation area. (The + \l{Writing Source Code for Translation#Handling Plurals}{Writing Source Code for Translation} + document contains details about this feature for developers.) \section2 Reusing Translations @@ -1157,7 +835,7 @@ {translation area}, and adapts the number of input fields for plural forms accordingly. If not explicitly set, \QL guesses the target language and country by evaluating the translation source - file name: E.g. \c app_de.ts sets the target language to German, + file name. For example, \c app_de.ts sets the target language to German, and \c app_de_ch.ts sets the target language to German and the target country to Switzerland (this also helps loading translations for the current locale automatically; see @@ -1287,7 +965,7 @@ can be used to edit XLIFF files generated by other programs. For standard Qt projects, however, only the TS file format is used. \o QM \e {Qt message files} \BR are binary files that contain - translations used by an application at runtime. These files are + translations used by an application at run-time. These files are generated by \l lrelease, but can also be generated by \QL. \o \c .qph \e {Qt phrase book files} \BR are human-readable XML files containing standard phrases and their translations. These files @@ -1416,7 +1094,7 @@ \endlist - \o \gui {Tools} + \o \gui {Tools} \list \o \gui {Batch Translation...} \BR Opens a \l{Batch @@ -1427,7 +1105,7 @@ Preview}. This window let you instantly see translations for forms created with \QD. \endlist - \o \gui {View} + \o \gui {View} \list \o \gui {Revert Sorting} \BR puts the items in the \l{Context @@ -1449,7 +1127,7 @@ \endlist - \o \gui {Help} + \o \gui {Help} \list \o \gui {Manual F1} \BR opens this manual. \o \gui {About Qt Linguist} \BR Shows information about \QL. @@ -1621,7 +1299,7 @@ \code CODECFORTR = UTF-8 \endcode - + See the \l lupdate and \l lrelease sections. \section2 Loading Translations @@ -1683,7 +1361,7 @@ \snippet doc/src/snippets/code/doc_src_linguist-manual.qdoc 9 - \section2 Distinguishing Identical Strings That Require Different Translations + \section2 Distinguishing Between Identical Translatable Strings The \l lupdate program automatically provides a \e context for every source text. This context is the class name of the class that contains diff --git a/doc/src/modules.qdoc b/doc/src/modules.qdoc index d28c2bc..457d8da 100644 --- a/doc/src/modules.qdoc +++ b/doc/src/modules.qdoc @@ -226,10 +226,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. + */ /*! @@ -367,6 +368,9 @@ The QtSql module is part of the \l{Qt Full Framework Edition} and the \l{Open Source Versions of Qt}. + + See the \l{SQL Programming} guide for information about using this + module in your applications. */ /*! @@ -576,7 +580,7 @@ the module under the appropriate version of the GNU LGPL; version 2.1 for applications and libraries licensed under the GNU GPL version 2, or version 3 for applications and libraries licensed under the GNU - GPL version 2. + GPL version 3. \legalese This file is part of the KDE project 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/supported-platforms.qdoc b/doc/src/platforms/supported-platforms.qdoc index 302ecb4..232eca6 100644 --- a/doc/src/platforms/supported-platforms.qdoc +++ b/doc/src/platforms/supported-platforms.qdoc @@ -86,7 +86,7 @@ \row \o Apple Mac OS X 10.5 "Leopard" x86_64 (Carbon, Cocoa 32 and 64bit) \o As provided by Apple \row \o Embedded Linux QWS (ARM) - \o gcc (\l{http:\\www.codesourcery.com}{Codesourcery version)} + \o gcc (\l{http://www.codesourcery.com}{Codesourcery version)} \row \o Windows CE 5.0 (ARMv4i, x86, MIPS) \o MSVC 2005 WinCE 5.0 Standard (x86, pocket, smart, mipsii) \row \o Symbian (S60 3.1, 3.2 and 5.0) 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/wince-signing.qdoc b/doc/src/platforms/wince-signing.qdoc new file mode 100644 index 0000000..fa383b3 --- /dev/null +++ b/doc/src/platforms/wince-signing.qdoc @@ -0,0 +1,96 @@ +/**************************************************************************** +** +** 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-signing.html + \ingroup qtce + \title Windows CE - Signing + \brief How to sign Qt projects for use with Windows CE. + + \section1 Signing on Windows CE + +Windows CE provides a security mechanism to ask the user to confirm +that they want to use an application/library that is unknown to the +system. This process gets repeated for each dependency of an +application, meaning each library the application links to, which is +not recognized yet. + +To simplify this process you can use signatures and certificates. A +certificate gets installed on the device and each file which is +signed with the according certificate can be launched without the +security warning. + +If you want to use signatures for your project written in Qt, +configure provides the \c -signature option. You need to specify the +location of the .pfx file and qmake adds the signing step to the +build rules. + +If you need to select a separate signature for a specific project, +or you only want to sign a single project, you can use the +"SIGNATURE_FILE = foo.pfx" rule inside the project file. + +The above described rules apply for command line makefiles as well as +Visual Studio projects generated by qmake. + +Microsoft usually ships development signatures inside the SDK packages. +You can find them in the Tools subdirectory of the SDK root folder. + +Example: + +\list +\o Calling configure with signing enabled: +\code +configure.exe -platform win32-msvc2005 -xplatform wincewm50pocket-msvc2005 -signature C:\some\path\SDKSamplePrivDeveloper.pfx +\endcode + +\o Using pro file to specify signature +\code +... +TARGET = foo + +wince*: { + SIGNATURE_FILE = somepath\customSignature.pfx +} +... +\endcode +\endlist + +*/ 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..2f74451 100644 --- a/doc/src/qt4-intro.qdoc +++ b/doc/src/qt4-intro.qdoc @@ -608,19 +608,19 @@ \section1 Graphics Effects Effects can be used to alter the appearance of UI elements such as - \l{QGraphicsItem}s and \l{QWidget}s. A range of standard effects such - as blurring, colorizing or blooming is provided, and it is possible to - implement custom effects. + \l{QGraphicsItem}s and \l{QWidget}s. A couple of standard effects such + as blurring, colorizing and drop shadow are provided, and it is + possible to implement custom effects. \table \row - \o - \o \img graphicseffect-plain.png - \o + \o{2,1} \img graphicseffect-plain.png \row \o \img graphicseffect-blur.png \o \img graphicseffect-colorize.png - \o \img graphicseffect-bloom.png + \row + \o \img graphicseffect-opacity.png + \o \img graphicseffect-drop-shadow.png \endtable See the QGraphicsEffect class documentation for more information. @@ -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/doc_src_i18n.qdoc b/doc/src/snippets/code/doc_src_i18n.qdoc index eca2868..80faabc 100644 --- a/doc/src/snippets/code/doc_src_i18n.qdoc +++ b/doc/src/snippets/code/doc_src_i18n.qdoc @@ -184,7 +184,7 @@ void Clock::setTime(const QTime &time) //! [12] -void QWidget::changeEvent(QEvent *event) +void MyWidget::changeEvent(QEvent *event) { if (e->type() == QEvent::LanguageChange) { titleLabel->setText(tr("Document Title")); diff --git a/doc/src/snippets/code/src_corelib_kernel_qobject.cpp b/doc/src/snippets/code/src_corelib_kernel_qobject.cpp index 4c64374..88d8025 100644 --- a/doc/src/snippets/code/src_corelib_kernel_qobject.cpp +++ b/doc/src/snippets/code/src_corelib_kernel_qobject.cpp @@ -235,9 +235,8 @@ MyWindow::MyWindow() { QLabel *senderLabel = new QLabel(tr("Name:")); QLabel *recipientLabel = new QLabel(tr("Name:", "recipient")); - ... -} //! [17] +} //! [18] 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_gui_effects_qgraphicseffect.cpp b/doc/src/snippets/code/src_gui_effects_qgraphicseffect.cpp index 35689f4..5ef6609 100644 --- a/doc/src/snippets/code/src_gui_effects_qgraphicseffect.cpp +++ b/doc/src/snippets/code/src_gui_effects_qgraphicseffect.cpp @@ -40,11 +40,11 @@ ****************************************************************************/ //! [0] -MyGraphicsOpacityEffect::draw(QPainter *painter, QGraphicsEffectSource *source) +MyGraphicsOpacityEffect::draw(QPainter *painter) { // Fully opaque; draw directly without going through a pixmap. if (qFuzzyCompare(m_opacity, 1)) { - source->draw(painter); + drawSource(painter); return; } ... @@ -52,18 +52,18 @@ MyGraphicsOpacityEffect::draw(QPainter *painter, QGraphicsEffectSource *source) //! [0] //! [1] -MyGraphicsEffect::draw(QPainter *painter, QGraphicsEffectSource *source) +MyGraphicsEffect::draw(QPainter *painter) { ... QPoint offset; - if (source->isPixmap()) { + if (sourceIsPixmap()) { // No point in drawing in device coordinates (pixmap will be scaled anyways). - const QPixmap pixmap = source->pixmap(Qt::LogicalCoordinates, &offset); + const QPixmap pixmap = sourcePixmap(Qt::LogicalCoordinates, &offset); ... painter->drawPixmap(offset, pixmap); } else { // Draw pixmap in device coordinates to avoid pixmap scaling; - const QPixmap pixmap = source->pixmap(Qt::DeviceCoordinates, &offset); + const QPixmap pixmap = sourcePixmap(Qt::DeviceCoordinates, &offset); painter->setWorldTransform(QTransform()); ... painter->drawPixmap(offset, pixmap); 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(); } diff --git a/doc/src/sql-programming/sql-programming.qdoc b/doc/src/sql-programming/sql-programming.qdoc index d0b6776..3aceb17 100644 --- a/doc/src/sql-programming/sql-programming.qdoc +++ b/doc/src/sql-programming/sql-programming.qdoc @@ -49,6 +49,7 @@ /*! \page sql-programming.html \title SQL Programming + \nextpage Connecting to Databases \brief Database integration for Qt applications. @@ -95,7 +96,7 @@ and the SQL API layer. See \l{SQL Database Drivers} for more information. \section2 SQL API Layer - + These classes provide access to databases. Connections are made using the QSqlDatabase class. Database interaction is achieved by using the QSqlQuery class. @@ -119,6 +120,7 @@ \title Connecting to Databases \contentspage SQL Programming + \previouspage SQL Programming \nextpage Executing SQL Statements To access a database with QSqlQuery or QSqlQueryModel, create and |