Merge branch '4.6' of git@scm.dev.nokia.troll.no:qt/oslo-staging-1 into 4.6

13 files changed, 582 insertions, 194 deletions

diff --git a/doc/src/examples/fancybrowser.qdoc b/doc/src/examples/fancybrowser.qdoc
index bc63010..4a9eaec 100644
--- a/doc/src/examples/fancybrowser.qdoc
+++ b/doc/src/examples/fancybrowser.qdoc
@@ -119,6 +119,10 @@
     page is loaded. Once the jQuery library is loaded, we can start executing 
     the different jQuery functions in the browser.
 
+    The rotateImages() function is then called explicitely to make sure
+    that the images of the newly loaded page respect the state of the toggle
+    action.
+
     \snippet examples/webkit/fancybrowser/mainwindow.cpp 7
 
     The first jQuery-based function, \c highlightAllLinks(), is designed to  
diff --git a/doc/src/getting-started/examples.qdoc b/doc/src/getting-started/examples.qdoc
index eec0492..e951804 100644
--- a/doc/src/getting-started/examples.qdoc
+++ b/doc/src/getting-started/examples.qdoc
@@ -706,6 +706,7 @@
     \o \l{tools/customtypesending}{Custom Type Sending}\raisedaster
     \o \l{tools/echoplugin}{Echo Plugin}\raisedaster
     \o \l{tools/i18n}{I18N}
+    \o \l{tools/inputpanel}{Input Panel}\raisedaster
     \o \l{tools/plugandpaint}{Plug & Paint}\raisedaster
     \o Plug & Paint Plugins: \l{tools/plugandpaintplugins/basictools}{Basic Tools}\raisedaster
        and \l{tools/plugandpaintplugins/extrafilters}{Extra Filters}\raisedaster
@@ -793,6 +794,7 @@
     \o \l{opengl/framebufferobject2}{Framebuffer Object 2}
     \o \l{opengl/grabber}{Grabber}
     \o \l{opengl/hellogl}{Hello GL}\raisedaster
+    \o \l{opengl/hellogl_es}{Hello GL - ported to Windows CE}\raisedaster
     \o \l{opengl/overpainting}{Overpainting}\raisedaster
     \o \l{opengl/pbuffers}{Pixel Buffers}
     \o \l{opengl/pbuffers2}{Pixel Buffers 2}
diff --git a/doc/src/getting-started/known-issues.qdoc b/doc/src/getting-started/known-issues.qdoc
index 0b63423..5c8888d 100644
--- a/doc/src/getting-started/known-issues.qdoc
+++ b/doc/src/getting-started/known-issues.qdoc
@@ -59,34 +59,6 @@
 
     \section1 Installation Issues
 
-    \section2 Building the Source Package on Windows 7
-
-    \list
-    \o  When building Qt 4.5.0 with Windows 7, the build fails with an error
-        message regarding failing to embed manifest. This a known issue with
-        Windows 7, explained in the Windows 7 SDK Beta
-        \l{http://download.microsoft.com/download/8/8/0/8808A472-6450-4723-9C87-977069714B27/ReleaseNotes.Htm}
-        {release notes}. A workaround for this issue is to patch the
-        \bold{embed_manifest_exe.prf} file with the following:
-
-        \code
-        diff --git a/mkspecs/features/win32/embed_manifest_exe.prf b/mkspecs/features/win32/embed_manifest_exe.prf
-        index e1747f1..05f116e 100644
-        --- a/mkspecs/features/win32/embed_manifest_exe.prf
-        +++ b/mkspecs/features/win32/embed_manifest_exe.prf
-        @@ -8,4 +8,9 @@ if(win32-msvc2005|win32-msvc2008):!equals(TEMPLATE_PREFIX, "vc"):equals(TEMPLATE
-             QMAKE_POST_LINK = $$quote(mt.exe -nologo -manifest \"$$replace(OBJECTS_DIR,/,\\)\\$${NOPATH_TARGET}.intermediate.ma
-        nifest\" -outputresource:$(DESTDIR_TARGET);1$$escape_expand(\n\t))
-             QMAKE_POST_LINK += $$QMAKE_PREV_POST_LINK
-             QMAKE_CLEAN += \"$$replace(OBJECTS_DIR,/,\\)\\$${NOPATH_TARGET}.intermediate.manifest\"
-        +    isEmpty(RC_FILE) {
-        +        system("echo.>$$replace(OUT_PWD,/,\\)\\$$replace(OBJECTS_DIR,/,\\)\\Windows7WorkAround.rc")
-        +        RC_FILE = $$replace(OUT_PWD,/,\\)\\$$replace(OBJECTS_DIR,/,\\)\\Windows7WorkAround.rc
-        +       }
-        +
-         }
-        \endcode
-
     \section2 Installing the Source Package on Unix systems
 
     \o  If you download a Zip source package, you will need to convert
diff --git a/doc/src/howtos/HWacceleration.qdoc b/doc/src/howtos/HWacceleration.qdoc
new file mode 100644
index 0000000..80db740
--- /dev/null
+++ b/doc/src/howtos/HWacceleration.qdoc
@@ -0,0 +1,100 @@
+/****************************************************************************
+**
+** 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 HWAcc_rendering.html
+    \title Using hardware acceleration on embedded platforms.
+
+    \ingroup best-practices
+
+    \section1 Abstract
+    This document describes how to use hardware acceleration for fast
+    rendering on embedded platforms supported by Qt. In short, it explains
+    how the graphics pipeline works. Since there might be differences to 
+	how the APIs are being used on different embedded platforms, a table
+	links to documentation dedicated to platform specific documentation
+	for each supported hardware acceleration API.
+
+    \input platforms/emb-hardwareacceleration.qdocinc
+
+    \section1 Supported platforms
+	Since there might be differences to how the APIs are being used on
+	the different embedded platforms, this table provides you with links to
+	pages dedicated to platform specific documentation for each
+	supported hardware acceleration API. Click the API link for the
+	platform to go the correct documentation.
+
+    \table
+        \header
+            \o Operating System
+            \o {3,1} Hardware Acceleration Platform
+        \row
+            \o \bold {Windows CE}
+            \o \l {Qt for Windows CE and OpenGL ES}{OpenGL ES}
+            \o \l {Qt for Windows CE and OpenVG}{OpenVG} 
+            \o
+        \row
+            \o \bold {Embedded Linux}
+            \o \l {Qt for Embedded Linux and OpenGL}{OpenGL ES}
+            \o \l {Qt for Embedded Linux and OpenVG}{OpenVG} 
+            \o \l {Qt for Embedded Linux and DirectFB}{DirectFB}
+        \row
+            \o \bold {Symbian Platform}
+            \o {3,1} \e {There are currently no support for hardware
+            acceleration.}
+    \endtable
+\omit
+    \section1 Examples using hardware acceleration on embedded platforms.
+
+    \table
+        \header
+            \o Embedded Platform
+            \o Example
+        \row
+            \o Windows CE
+        \row
+            \o Embedded Linux
+    \endtable
+\endomit
+
+
+
+*/
diff --git a/doc/src/modules.qdoc b/doc/src/modules.qdoc
index 3abcf7c..94cab58 100644
--- a/doc/src/modules.qdoc
+++ b/doc/src/modules.qdoc
@@ -314,8 +314,43 @@
 
 	\snippet doc/src/snippets/code/doc_src_qtscript.qdoc 1
 
+        For detailed information on how to make your application
+        scriptable with QtScript, see \l{Making Applications
+        Scriptable}.
+
 	The QtScript module is part of the \l{Qt Full Framework Edition} and the
 	\l{Open Source Versions of Qt}.
+
+        \section1 License Information
+
+        Qt Commercial Edition licensees that wish to distribute applications that
+        use the QtScript module need to be aware of their obligations under the
+        GNU Library General Public License (LGPL).
+
+        Developers using the Open Source Edition can choose to redistribute
+        the module under the appropriate version of the GNU LGPL.
+
+        \legalese
+        QtScript is licensed under the GNU Library General Public License.
+        Individual contributor names and copyright dates can be found
+        inline in the code.
+
+        This library is free software; you can redistribute it and/or
+        modify it under the terms of the GNU Library General Public
+        License as published by the Free Software Foundation; either
+        version 2 of the License, or (at your option) any later version.
+
+        This library is distributed in the hope that it will be useful,
+        but WITHOUT ANY WARRANTY; without even the implied warranty of
+        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+        Library General Public License for more details.
+
+        You should have received a copy of the GNU Library General Public License
+        along with this library; see the file COPYING.LIB.  If not, write to
+        the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+        Boston, MA 02110-1301, USA.
+        \endlegalese
+
 */
 
 /*!
diff --git a/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc b/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc
index 9c18d87..a9bd167 100644
--- a/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc
+++ b/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc
@@ -49,23 +49,57 @@
     \ingroup qt-embedded-linux
 
 
-  \input platforms/emb-hardwareacceleration.qdocinc
+	\input platforms/emb-hardwareacceleration.qdocinc
 
-\section1 Supported Hardware Accelerated Graphics APIs
+    \section1 Windowing on Embedded Linux with Hardware Accelerated Graphics
 
-This list shows which Hardware Accelerated Graphics APIs currently
-supported by Qt.
+    Qt for Embedded Linux includes its own windowing system, QWS. QWS was
+    designed in 1999, well before graphics acceleration was available for
+    embedded devices. It does a great job providing a lightweight window
+    manager including all the expected functionality such as arbitrary
+    windows that can be moved, resized, minimized, etc. Getting QWS to work
+    with GPUs is very challenging, particularly with OpenGL and OpenVG
+    because there is no standard way in Linux to share textures across
+    processes. Some silicon vendors provide private APIs to allow texture
+    sharing, others do not. These limitations are documented under the
+    sections describing each type of accelerated hardware APIs. The simplest
+    most generic support for accelerated graphics is a full screen single
+    process single window.
 
- \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 
+    \section2 General options
+    \list
+        \o QWS, not accelerated, allows arbitrary windowing with multiple
+        processes drawing on the screen.
+        \o X11 with an accelerated X11 driver provided by the silicon
+        vendor. Like QWS, this allows arbitrary windows with multiple
+        processes drawing on the screen. Our experience is that there is
+        some overhead from X11 which will adversely affect framerates.
+        Additionally, our experience is that the drivers from silicon
+        vendors are still maturing.
+        \o Full screen single process single window. This will always work.
+        Some additional capabilities are available and are documented in
+        the acceleration specific API sections.
+    \endlist
+
+    \section1 Supported Hardware Accelerated Graphics APIs
+
+    This table shows which Hardware Accelerated Graphics APIs currently
+    supported by Qt.
+
+     \table 
+     \header
+        \o Supported APIs
+		\o API Version
+     \row
+        \o \l {Qt for Embedded Linux and OpenGL}{OpenGL ES}
+		\o 1.x and 2.x
+     \row
+        \o \l {Qt for Embedded Linux and OpenVG}{OpenVG } 
+		\o 1.1
+     \row
+        \o \l {Qt for Embedded Linux and DirectFB}{DirectFB}
+		\o 2.0
+     \endtable 
 
 
 */
diff --git a/doc/src/platforms/emb-HwAcc-WinCE.qdoc b/doc/src/platforms/emb-HwAcc-WinCE.qdoc
index 66b6948..b7789f1 100644
--- a/doc/src/platforms/emb-HwAcc-WinCE.qdoc
+++ b/doc/src/platforms/emb-HwAcc-WinCE.qdoc
@@ -47,7 +47,6 @@
     \title Qt for Windows CE Hardware Accelerated Graphics
     \ingroup qtce
 
-
     \input platforms/emb-hardwareacceleration.qdocinc
 
     \section1 Supported Hardware Accelerated Graphics APIs
diff --git a/doc/src/platforms/emb-hardwareacceleration.qdocinc b/doc/src/platforms/emb-hardwareacceleration.qdocinc
index 3851628..fb00e09 100644
--- a/doc/src/platforms/emb-hardwareacceleration.qdocinc
+++ b/doc/src/platforms/emb-hardwareacceleration.qdocinc
@@ -1,129 +1,140 @@
-
-\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.
+	\section1 Hardware Acceleration
+	
+	When designing applications for embedded devices there is often a
+	compromise between graphics effects and performance. On most
+	devices, you cannot have both simply because the hardware needed
+	for such operations just is not there. With a growing number of
+	devices that use hardware dedicated to graphics operations there is
+	less need to compromise.
+	
+	In addition to enabling dynamic graphics effects, there are two
+	other benefits to using graphics acceleration. One is that 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.
+	Typical \e {System-on-a-chip} (SoC) 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.
+	
+	Another reason to use a GPU is to offload the main CPU, either for
+	power saving or to perform other operations in parallel. Often
+	drawing speed with a GPU is not that much faster than a CPU but
+	the clear benefit of using the GPU is to free up the CPU to perform
+	other tasks which can be used to create a more responsive use
+	experience.
+	
+	The key to writing 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/platform-notes.qdoc b/doc/src/platforms/platform-notes.qdoc
index 9896b08..68015a6 100644
--- a/doc/src/platforms/platform-notes.qdoc
+++ b/doc/src/platforms/platform-notes.qdoc
@@ -406,17 +406,102 @@
     \page platform-notes-symbian.html
     \title Platform Notes - Symbian
     \contentspage Platform Notes
+    \ingroup platform-specific
+    \brief Information about the state of support for the Symbian platform.
 
-    This page contains information about the Symbian platforms Qt is currently known
-    to run on. More information about the combinations of platforms and compilers
-    supported by Qt can be found on the \l{Supported Platforms} page.
+    As with any port, the maturity for Qt for Symbian has not yet reached the
+    same level as other established Qt ports. This page documents the current
+    notes for the Symbian port.
+
+    \section1 Source Compatibility
+
+    Qt for Symbian provides the same level of source compatibility guarantee as
+    given for other platforms.  That is, a program which compiles against a given
+    version of Qt for Symbian will also compile against all future versions of the
+    same major release.
+
+    \section1 Binary Compatibility
+
+    As with every supported platform, we will strive to maintain
+    application behavior and binary compatibility throughout the lifetime of
+    the Qt 4.x series. However, due to the fact that Symbian support is newly
+    added in 4.6.0, there is a slight possibility that minor corrections to the
+    application binary interface (ABI) might be required in 4.6.1, in order to
+    ensure compatibility going forward. Any such change will be clearly
+    documented in the release notes for 4.6.1.
+
+    \section1 Supported Devices
+
+    Qt is designed to work on any device which runs one of the following
+    versions of Symbian:
+
+    \table
+    \header \o Symbian Version
+    \row \o S60 3.1
+    \row \o S60 3.2
+    \row \o S60 5.0 (Symbian ^1)
+    \endtable
+
+    Qt has received \l{Tier 1 Platforms}{Tier 1} testing on the following phone models:
+
+    \table
+    \header \o Phone
+    \row    \o Nokia 5800
+    \row    \o Nokia E71
+    \row    \o Nokia E72
+    \row    \o Nokia N78
+    \row    \o Nokia N95
+    \row    \o Nokia N97
+    \row    \o Samsung i8910
+    \endtable
+
+    \section1 Supported Functionality
+
+    The following technologies and classes are not currently supported:
+
+    \table
+    \header \o Technology
+            \o Note
+    \row    \o QtConcurrent
+            \o Planned for future release.
+    \row    \o QtDBus
+            \o No current plans to support this feature.
+    \row    \o QtOpenGL ES
+            \o Planned for future release.
+    \row    \o Printing support
+            \o No current plans to support this feature.
+    \row    \o Qt3Support
+            \o No current plans to support this feature.
+    \endtable
+
+    The following technologies have limited support:
+
+    \table
+    \header \o Technology
+            \o Note
+    \row    \o QtSql
+            \o The only driver supported is SQLite.
+    \row    \o QtMultimedia
+            \o Although the module itself is supported, no backend for Symbian
+               is currently available. However, there is a backend available
+               for Phonon.
+    \endtable
+
+    \section1 Known Issues
+
+    Known issues can be found by visiting the
+    \l{http://qt.gitorious.org/qt/pages/Qt460KnownIssues}{wiki page} with an
+    up-to-date list of known issues, and the list of bugs can be found by
+    \l{http://bugreports.qt.nokia.com/browse/QTBUG/component/19171}{browsing} the
+    S60 component in Qt's public task tracker, located at
+    \l{http://bugreports.qt.nokia.com/}{http://bugreports.qt.nokia.com/}.
 
-    For information about mixing exceptions with Symbian leaves,
-    see \l{Exception Safety with Symbian}
+    For information about mixing exceptions with Symbian leaves, see
+    \l{Exception Safety with Symbian}.
 
     \section1 Multimedia and Phonon Support
 
-    Qt provides a backend for Qt's multimedia module, Phonon, which supports
+    Qt provides a backend for Qt's Phonon module, which supports
     video and sound playback through Symbian's Multimedia Framework, MMF.
 
     In this release the support is experimental. Video playback may have
@@ -429,7 +514,11 @@
 
     In addition, there exists a backend for the Helix framework. However, due
     to it not shipping with Qt, its availability depends on the Symbian
-    platform in use. If available, it is loaded instead of the MMF plugin.
+    platform in use. If available, it is loaded in preference over the MMF
+    plugin. The Helix plugin requires Symbian signed capabilities. If the
+    application does not have those capabilities, the MMF plugin, if present on
+    the device, will be loaded instead. The capabilities the Helix backend
+    requires are AllFiles, DiskAdmin and MultimediaDD.
 
 */
 
diff --git a/doc/src/platforms/supported-platforms.qdoc b/doc/src/platforms/supported-platforms.qdoc
index 560ddfe..ca668bc 100644
--- a/doc/src/platforms/supported-platforms.qdoc
+++ b/doc/src/platforms/supported-platforms.qdoc
@@ -89,7 +89,7 @@
                                      \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)
+    \row    \o \l {Qt for Symbian} {Symbian (S60 3.1, 3.2 and 5.0)}
                                      \o RVCT, GCCE, WINSCW
     \endtable
 
@@ -155,4 +155,21 @@
     warranties and conditions, either express or implied, including, but not limited to,
     implied warranties of merchantability, fitness for a particular purpose, title and
     non-infringement with regard to the Licensed Software.
+    
+    \section1 Planned Changes for Qt 4.7
+
+    The following changes to the list of supported platforms are at time of publishing
+    planned for Qt 4.7:
+
+    \list
+    \o Upgrade Windows 7 to Tier 1
+    \o Upgrade Mac OS X 10.6 to Tier 1
+    \o Add support for Visual Studio 2010 (Tier 2)
+    \o Move support for Carbon implementation of Qt on Mac OS X from Tier 1 to Tier 2
+    \o Drop support for MinGW 3.4
+    \o Drop support for Visual Studio 2003
+    \o Drop support for HP-UX on PA-RISC
+    \o Drop support for Windows Mobile 5
+    \o Drop support for OpenGL ES Common Lite
+    \endlist
 */
diff --git a/doc/src/platforms/symbian-support.qdoc b/doc/src/platforms/symbian-support.qdoc
new file mode 100644
index 0000000..916eda5
--- /dev/null
+++ b/doc/src/platforms/symbian-support.qdoc
@@ -0,0 +1,135 @@
+/****************************************************************************
+**
+** 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 symbian-support.html
+    \title Qt for Symbian
+    \ingroup platform-specific
+    \brief Information about the state of support for the Symbian platform.
+
+    Qt for Symbian is not yet fully on a par with other platforms with respect
+    to stability and feature support. This page documents the current shortcomings
+    of the Symbian port.
+
+    \section1 Source Compatibility
+
+    Qt for Symbian provides the same level of source compatibility guarantee as
+    given for other platforms.  That is, a program which compiles against a given
+    version of Qt for Symbian will also compile against all future versions of the
+    same major release.
+
+    \section1 Binary Compatibility
+
+    As with every supported platform, we will strive to maintain
+    application behavior and binary compatibility throughout the lifetime of
+    the Qt 4.x series. However, due to the fact that Symbian support is
+    newly added in 4.6.0, it is possible that minor corrections to the
+    behavior and to the ABI in 4.6.1 will be required in order to ensure
+    compatibility going forward. If we break the binary compatiblity promise,
+    we will document such changes in the 4.6.1 release.
+
+    \section1 Supported Devices
+
+    Qt should generally work on any device which runs one of the following
+    versions of Symbian:
+
+    \table
+    \header \o Symbian Version
+    \row \o S60 3.1
+    \row \o S60 3.2
+    \row \o S60 5.0 (Symbian ^1)
+    \endtable
+
+    Qt has received Tier 1 testing on the following phone models:
+
+    \table
+    \header \o Phone
+    \row    \o Nokia 5800
+    \row    \o Nokia E71
+    \row    \o Nokia E72
+    \row    \o Nokia N78
+    \row    \o Nokia N95
+    \row    \o Nokia N97
+    \row    \o Samsung i8910
+    \endtable
+
+    \section1 Supported Functionality
+
+    The following technologies and classes are not currently supported:
+
+    \table
+    \header \o Technology
+            \o Note
+    \row    \o QtConcurrent
+            \o
+    \row    \o QtDBus
+            \o No current plans to support this feature.
+    \row    \o QtOpenGL
+            \o Support for OpenGL ES planned for a future release.
+    \row    \o Printing support
+            \o No current plans to support this feature.
+    \row    \o Qt3Support
+            \o No current plans to support this feature.
+    \endtable
+
+    The following technologies have limited support:
+
+    \table
+    \header \o Technology
+            \o Note
+    \row    \o QtSql
+            \o The only driver supported is SQLite.
+    \row    \o QtMultimedia
+            \o Although the module itself is supported, no backend for Symbian
+               is available. However, there is a backend available for Phonon.
+    \endtable
+
+    \section1 Known Issues
+
+    Known issues can be found by visiting the
+    \l{http://qt.gitorious.org/qt/pages/Qt460KnownIssues}{wiki page} with an
+    up-to-date list of known issues, and the list of bugs can be found by
+    \l{http://bugreports.qt.nokia.com/browse/QTBUG/component/19171}{browsing} the
+    S60 component in Qt's public task tracker, located at
+    \l{http://bugreports.qt.nokia.com/}{http://bugreports.qt.nokia.com/}.
+
+*/
+
diff --git a/doc/src/scripting/scripting.qdoc b/doc/src/scripting/scripting.qdoc
index e99be70..b2ce8d1 100644
--- a/doc/src/scripting/scripting.qdoc
+++ b/doc/src/scripting/scripting.qdoc
@@ -1805,15 +1805,9 @@
 
   \section1 ECMAScript Compatibility
 
-  QtScript implements all the built-in classes and functions defined
-  in ECMA-262.
-
-  The Date parsing and string conversion functions are implemented using
-  QDateTime::fromString() and QDateTime::toString(), respectively.
-
-  The RegExp class is a wrapper around QRegExp. The QRegExp semantics
-  do not precisely match the semantics for regular expressions defined
-  in ECMA-262.
+  QtScript implements all the built-in objects and properties defined
+  in the \l{ECMA-262} standard; see the
+  \l{ECMAScript Reference}{ECMAScript reference} for an overview.
 
   \section1 QtScript Extensions to ECMAScript
 
diff --git a/doc/src/snippets/code/src_gui_painting_qregion_unix.cpp b/doc/src/snippets/code/src_gui_painting_qregion_unix.cpp
index fb1f363..ea42e70 100644
--- a/doc/src/snippets/code/src_gui_painting_qregion_unix.cpp
+++ b/doc/src/snippets/code/src_gui_painting_qregion_unix.cpp
@@ -41,19 +41,15 @@
 
 //! [0]
 QRegion r1(10, 10, 20, 20);
-r1.isNull();                // false
 r1.isEmpty();               // false
 
-QRegion r2(40, 40, 20, 20);
 QRegion r3;
-r3.isNull();                // true
 r3.isEmpty();               // true
 
+QRegion r2(40, 40, 20, 20);
 r3 = r1.intersected(r2);    // r3: intersection of r1 and r2
-r3.isNull();                // false
 r3.isEmpty();               // true
 
 r3 = r1.united(r2);         // r3: union of r1 and r2
-r3.isNull();                // false
 r3.isEmpty();               // false
 //! [0]