Merge branch 'master' of git@scm.dev.nokia.troll.no:qt/qt into windows-7-multitouch

4 files changed, 224 insertions, 75 deletions

diff --git a/doc/src/deployment.qdoc b/doc/src/deployment.qdoc
index d2c7a9e..7e02f1a 100644
--- a/doc/src/deployment.qdoc
+++ b/doc/src/deployment.qdoc
@@ -89,8 +89,9 @@
     of Qt, you get Qt as a shared library.
 
     The disadvantage with the shared library approach is that you
-    will get more files to deploy.
-
+    will get more files to deploy. For more information, see
+    \l{sharedlibrary.html}{Creating Shared Libraries}.
+    
     \section1 Deploying Qt's Libraries
 
     \table
diff --git a/doc/src/designer-manual.qdoc b/doc/src/designer-manual.qdoc
index 083d782..97713b1 100644
--- a/doc/src/designer-manual.qdoc
+++ b/doc/src/designer-manual.qdoc
@@ -2537,6 +2537,10 @@ pixmap property in the property editor.
     \target BuildingandInstallingthePlugin
     \section1 Building and Installing the Plugin
 
+    \section2 A Simple Plugin
+
+    The \l{Custom Widget Plugin Example} demonstrates a simple \QD plugin.
+
     The \c{.pro} file for a plugin must specify the headers and sources for
     both the custom widget and the plugin interface. Typically, this file only
     has to specify that the plugin's project is to be built as a library, but
@@ -2571,65 +2575,42 @@ pixmap property in the property editor.
     See QCoreApplication::libraryPaths() for more information about customizing
     paths for libraries and plugins with Qt applications.
 
-\omit
-    \section1 Using Qt Script to Aid in Building Forms
-
-    Starting with Qt 4.3, \c .ui files may contain
-    \l{QtScript}{Qt Script} snippets that are executed by \l uic or QUiLoader
-    when building forms.
+    \section2 Splitting up the Plugin
 
-    The snippets are executed per widget. The snippet may modify properties
-    or invoke slots on the widget.
+    In a real world scenario, you do not want to have dependencies of the
+    application making use of the custom widgets to the \QD headers and
+    libraries as introduced by the simple approach explained above.
 
-    Special variables are used to access the widget:
+    There are two ways to resolve this:
 
-    \table
-    \header
-    \o Name
-    \o Value
-    \row \o \c  widget
-         \o The widget being built.
-    \row \o \c  childWidgets
-         \o An array containing the child widgets. This is useful
-         for QDesignerContainerExtension subclasses.
-    \endtable
+    \list
+        \i Create a \c{.pri} file that contains the headers sources and sources
+           of the custom widget:
 
-    If scripts are present in an \c {uic}-generated form, the application
-    must be configured with Qt Script support.
+           \code
+           INCLUDEPATH += $$PWD
+           HEADERS += $$PWD/analogclock.h
+           SOURCES += $$PWD/analogclock.cpp
+           \endcode
 
-    \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 5
+           This file would then be included by the \c{.pro} file of the plugin and
+           the application:
 
-    For security reasons, the execution of scripts is disabled
-    by default in QUiLoader. You can enable it by
-    calling the QUiLoader::setScriptingEnabled() method.
+           \code
+           include(customwidget.pri)
+           \endcode
 
-    The resulting script snippet is concatenated from snippets occurring in
-    several places:
+           Running \c{qmake -Wall} on the \c{.pro} files causes a warning to be
+           printed if an included \c{.pri} file cannot be found.
 
-    \table
-    \header
-    \o Source
-    \o Usage
-    \row \o The \c codeTemplate() function of QDesignerCustomWidgetInterface
-         \o Allows snippets to be run on a per-class basis; for example, to set up a
-            container using the QDesignerContainerExtension.
-    \row \o The \c script() method of QDesignerScriptExtension
-         \o Allows snippets to be run on a per-widget basis; for example,
-            to set up the internal state of a custom widget.
-
-            Such an internal state might be, for example, the contents of
-            a custom item view container widget, for which an editor
-            is provided by an QDesignerTaskMenuExtension object.
-
-    \row \o Snippets entered at run-time using the \gui{Change script...}
-            option of the form's context menu
-         \o Fast prototyping. To get an idea,
-            drag a QLineEdit onto the form, enter the script
-            \snippet doc/src/snippets/code/doc_src_designer-manual.qdoc 6
-            and preview the form.
-    \endtable
-\endomit
+        \i Create a standalone shared library containing the custom widgets only
+           as described in
+           \l{sharedlibrary.html}{Creating Shared Libraries}.
 
+           This library would then be used by the application as well as by the
+           \QD plugin. Care must be taken to ensure that the plugin can locate
+          the library at run-time.
+    \endlist
 
     \section1 Related Examples
 
diff --git a/doc/src/sharedlibrary.qdoc b/doc/src/sharedlibrary.qdoc
new file mode 100644
index 0000000..3febb8f
--- /dev/null
+++ b/doc/src/sharedlibrary.qdoc
@@ -0,0 +1,186 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Qt Software Information (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at qt-sales@nokia.com.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Qt Software Information (qt-info@nokia.com)
+**
+** This file is part of the Qt GUI Toolkit.
+** EDITIONS: FREE, PROFESSIONAL, ENTERPRISE
+**
+****************************************************************************/
+
+/*!
+    \group deployment
+    \page sharedlibrary.html
+    \ingroup buildsystem
+
+    \title Creating Shared Libraries
+    The following sections list certain things that should be taken into
+    account when creating shared libraries.
+
+    \section1 Using Symbols from Shared Libraries
+
+    Symbols - functions, variables or classes - contained in shared libraries
+    intended to be used by \e{clients}, such as applications or other
+    libraries, must be marked in a special way. These symbols are called
+    \e{public symbols} that are \e{exported} or made publicly visible.
+
+    The remaining symbols should not be visible from the outside. On most
+    platforms, compilers will hide them by default. On some platforms, a
+    special compiler option is required to hide these symbols.
+
+    When compiling a shared library, it must be marked for \e{export}. To use
+    the shared library from a client, some platforms may require a special
+    \e{import} declaration as well.
+
+    Depending on your target platform, Qt provides special macros that contain
+    the necessary definitions:
+    \list
+        \o  \c{Q_DECL_EXPORT} must be added to the declarations of symbols used
+            when compiling a shared library.
+        \o  \c{Q_DECL_IMPORT} must be added to the declarations of symbols used
+            when compiling a client that uses the shared library.
+    \endlist
+
+    Now, we need to ensure that the right macro is invoked -- whether we
+    compile a share library itself, or just the client using the shared
+    library.
+    Typically, this can be solved by adding a special header.
+
+    Let us assume we want to create a shared library called \e{mysharedlib}.
+    A special header for this library, \c{mysharedlib_global.h}, looks like
+    this:
+
+    \code
+        #include <QtCore/QtGlobal>
+
+        #if defined(MYSHAREDLIB_LIBRARY)
+        #  define MYSHAREDLIB_EXPORT Q_DECL_EXPORT
+        #else
+        #  define MYSHAREDLIB_EXPORT Q_DECL_IMPORT
+        #endif
+    \endcode
+
+    In the \c{.pro} file of the shared library, we add:
+
+    \code
+        DEFINES += MYSHAREDLIB_LIBRARY
+    \endcode
+
+    In each header of the library, we specify the following:
+
+    \code
+        #include "mysharedlib_global.h"
+
+        MYSHAREDLIB_EXPORT void foo();
+        class MYSHAREDLIB_EXPORT MyClass...
+    \endcode
+    This ensures that the right macro is seen by both library and clients. We
+    also use this technique in Qt's sources.
+
+
+    \section1 Header File Considerations
+
+    Typically, clients will include only the public header files of shared
+    libraries. These libraries might be installed in a different location, when
+    deployed. Therefore, it is important to exclude other internal header files
+    that were used when building the shared library.
+
+    For example, the library might provide a class that wraps a hardware device
+    and contains a handle to that device, provided by some 3rd-party library:
+
+    \code
+        #include <footronics/device.h>
+
+        class MyDevice {
+        private:
+	    FOOTRONICS_DEVICE_HANDLE handle;
+        };
+    \endcode  
+
+    A similar situation arises with forms created by Qt Designer when using
+    aggregation or multiple inheritance:
+
+    \code
+        #include "ui_widget.h"
+
+        class MyWidget : public QWidget {
+        private:
+	    Ui::MyWidget m_ui;
+        };
+    \endcode  
+
+    When deploying the library, there should be no dependency to the internal
+    headers \c{footronics/device.h} or \c{ui_widget.h}.
+
+    This can be avoided by making use of the \e{Pointer to implementation}
+    idiom described in various C++ programming books. For classes with
+    \e{value semantics}, consider using QSharedDataPointer.
+
+
+    \section1  Binary compatibility
+
+    For clients loading a shared library, to work correctly, the memory
+    layout of the classes being used must match exactly the memory layout of
+    the library version that was used to compile the client. In other words,
+    the library found by the client at runtime must be \e{binary compatible}
+    with the version used at compile time.
+
+    This is usually not a problem if the client is a self-contained software
+    package that ships all the libraries it needs.
+
+    However, if the client application relies on a shared library that belongs
+    to a different installation package or to the operating system, then we
+    need to think of a versioning scheme for shared libraries and decide at
+    which level \e{Binary compatibility} is to be maintained. For example, Qt
+    libraries of the same \e{major version number} are guaranteed to be binary
+    compatible.
+
+    Maintaining \e{Binary compatibility} places some restrictions on the changes
+    you can make to the classes. A good explanation can be found at
+    \l{http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++}
+    {KDE - Policies/Binary Compatibility Issues With C++}. These issues should
+    be considered right from the start of library design.
+    We recommend that the principle of \e{Information hiding} and the
+    \e{Pointer to implementation} technique be used wherever possible.
+*/
diff --git a/doc/src/tutorials/widgets-tutorial.qdoc b/doc/src/tutorials/widgets-tutorial.qdoc
index ce977f3..ead44af 100644
--- a/doc/src/tutorials/widgets-tutorial.qdoc
+++ b/doc/src/tutorials/widgets-tutorial.qdoc
@@ -80,7 +80,7 @@
 
     \raw HTML
     <table align="left" width="100%">
-    <tr><td>
+    <tr class="qt-code"><td>
     \endraw
     \snippet snippets/widgets-tutorial/toplevel/main.cpp create, resize and show
     \raw HTML
@@ -98,7 +98,7 @@
 
     \raw HTML
     <table align="left" width="100%">
-    <tr><td>
+    <tr class="qt-code"><td>
     \endraw
     \snippet snippets/widgets-tutorial/childwidget/main.cpp create, position and show
     \raw HTML
@@ -123,7 +123,7 @@
 
     \raw HTML
     <table align="left" width="100%">
-    <tr><td>
+    <tr class="qt-code"><td>
     \endraw
     \snippet snippets/widgets-tutorial/windowlayout/main.cpp create, lay out widgets and show
     \raw HTML
@@ -157,7 +157,7 @@
 
     \raw HTML
     <table align="left" width="100%">
-    <tr><td>
+    <tr class="qt-code"><td>
     \endraw
     \snippet snippets/widgets-tutorial/nestedlayouts/main.cpp create, lay out widgets and show
     \raw HTML
@@ -171,23 +171,4 @@
 
     As well as QHBoxLayout and QVBoxLayout, Qt also provides QGridLayout
     and QFormLayout classes to help with more complex user interfaces.
-
-    
-
-    \omit
-    In the simple example below, the widget is created on the stack and will
-    automatically be deleted when the \c{main()} function exits.
-
-    {{{#include <QtGui>
-
-    int main(int argc, char *argv[])
-    {
-        QApplication app(argc, argv);
-        QWidget window;
-        window.resize(480, 360);
-        window.show();
-        return app.exec();
-    }
-    }}}
-    \endomit
 */