Automated update from Qt3

1 files changed, 40 insertions, 40 deletions

diff --git a/doc/plugins-howto.doc b/doc/plugins-howto.doc
index 181498044..d5adcb5a2 100644
--- a/doc/plugins-howto.doc
+++ b/doc/plugins-howto.doc
@@ -4,7 +4,7 @@
 **
 ** Copyright (C) 1992-2008 Trolltech ASA.  All rights reserved.
 **
-** This file is part of the Qt GUI Toolkit.
+** This file is part of the TQt GUI Toolkit.
 **
 ** This file may be used under the terms of the GNU General
 ** Public License versions 2.0 or 3.0 as published by the Free
@@ -13,7 +13,7 @@
 ** Alternatively you may (at your option) use any later version
 ** of the GNU General Public License if such license has been
 ** publicly approved by Trolltech ASA (or its successors, if any)
-** and the KDE Free Qt Foundation.
+** and the KDE Free TQt Foundation.
 **
 ** Please review the following information to ensure GNU General
 ** Public Licensing requirements will be met:
@@ -39,15 +39,15 @@
 /*!
 \page plugins-howto.html
 
-\title Qt Plugins HOWTO
+\title TQt Plugins HOWTO
 
 Qt provides a simple plugin interface which makes it easy to create
 custom database drivers, image formats, text codecs, styles and
 widgets as stand-alone components.
-\footnote Qt 3.0.5 introduces changes into some aspects of plugins, in
+\footnote TQt 3.0.5 introduces changes into some aspects of plugins, in
 particular regarding loading, path handling and library versions. As
-a result of this change, <b>\e{no}</b> plugins compiled with Qt 3.0.4 and
-earlier will work with Qt 3.0.5 and later: they must be recompiled.
+a result of this change, <b>\e{no}</b> plugins compiled with TQt 3.0.4 and
+earlier will work with TQt 3.0.5 and later: they must be recompiled.
 \endfootnote
 
 Writing a plugin is achieved by subclassing the appropriate plugin
@@ -78,11 +78,11 @@ by default in the standard plugin directory.
 \endtable
 
 But where is the \c{pluginsbase} directory? When the application is
-run, Qt will first treat the application's executable directory as the
+run, TQt will first treat the application's executable directory as the
 \c{pluginsbase}. For example if the application is in \c{C:\Program
-Files\MyApp} and has a style plugin, Qt will look in \c{C:\Program
+Files\MyApp} and has a style plugin, TQt will look in \c{C:\Program
 Files\MyApp\styles}. (See \l{QApplication::applicationDirPath()} for
-how to find out where the application's executable is.) Qt will also
+how to find out where the application's executable is.) TQt will also
 look in the directory given by \c{tqInstallPathPlugins()}. If you want
 Qt to look in additional places you can add as many paths as you need
 with calls to \c{QApplication::addLibraryPath()}. And if you want to
@@ -130,7 +130,7 @@ single plugin, providing they are all derived from the same base
 class, e.g. QStylePlugin.
 
 For database drivers, image formats, custom widgets and text codecs,
-no explicit object creation is required. Qt will find and create them
+no explicit object creation is required. TQt will find and create them
 as required. Styles are an exception, since you might want to set a
 style explicitly in code. To apply a style, use code like this:
 \code
@@ -138,7 +138,7 @@ style explicitly in code. To apply a style, use code like this:
 \endcode
 
 Some plugin classes require additional functions to be implemented.
-See the \link designer-manual.book Qt Designer manual's\endlink,
+See the \link designer-manual.book TQt Designer manual's\endlink,
 'Creating Custom Widgets' section in the 'Creating Custom Widgets'
 chapter, for a complete example of a QWidgetPlugin, which implements
 extra functions to integrate the plugin into \e{Qt Designer}. The
@@ -151,7 +151,7 @@ must be reimplemented for each type of plugin.
 Qt applications automatically know which plugins are available,
 because plugins are stored in the standard plugin subdirectories.
 Because of this applications don't require any code to find and load
-plugins, since Qt handles them automatically.
+plugins, since TQt handles them automatically.
 
 The default directory for plugins is \c{QTDIR/plugins}<sup>*</sup>,
 with each type of plugin in a subdirectory for that type, e.g. \c
@@ -171,58 +171,58 @@ other library. If you want the plugin to be loadable then one approach
 is to create a subdirectory under the application, e.g. \c
 appdir/plugins/designer, and place the plugin in that directory.
 
-For \link designer-manual.book Qt Designer\endlink, you may need to
+For \link designer-manual.book TQt Designer\endlink, you may need to
 call QApplication::addLibraryPath("QTDIR/plugins/designer") to load
-your \link designer-manual.book Qt Designer\endlink plugins.
+your \link designer-manual.book TQt Designer\endlink plugins.
 
 <sup>*</sup><small> All references to \c{QTDIR} refer to the path
-where Qt was installed. </small>
+where TQt was installed. </small>
 
 \section1 Loading and Verifying Plugins
 
-When loading plugins, the Qt library does some sanity checking to
+When loading plugins, the TQt library does some sanity checking to
 determine whether or not the plugin can be loaded and used. This
 provides the ability to have multiple versions and configurations of
-the Qt library installed side by side.
+the TQt library installed side by side.
 \list
-\i Plugins linked with a Qt library that has a higher major and/or
+\i Plugins linked with a TQt library that has a higher major and/or
    minor version number will not be loaded by a library with a lower
    major and/or minor version number.
 
    \e Rationale:
 
-   A plugin linked against a newer Qt library may use new
+   A plugin linked against a newer TQt library may use new
    features that are not available in older versions. Trolltech
    has a policy of adding new features and APIs only between minor
    releases, which is why this test only looks at the major and minor
    version numbers, and not at the patchlevel version number.
 
-\i Plugins linked against a Qt library \e with thread support can only be
+\i Plugins linked against a TQt library \e with thread support can only be
    loaded by libraries that are built \e with thread support.
 
    \e Rationale:
 
-   The threaded and non-threaded Qt libraries have different names.
+   The threaded and non-threaded TQt libraries have different names.
    A library \e with thread support that loads a plugin linked against a
-   Qt library \e without thread support will cause two versions of the same
+   TQt library \e without thread support will cause two versions of the same
    library to be in memory at the same time. On UNIX systems, this
-   causes the non-threaded Qt library to be loaded. When this
-   happens, the constructors for all static objects in the Qt library
+   causes the non-threaded TQt library to be loaded. When this
+   happens, the constructors for all static objects in the TQt library
    will be called a second time, but they will operate on the objects
    already in memory. There is no way to work around this, as this is
    a feature of the object binary format: the static symbols already
-   defined by the threaded Qt library cannot be replaced or copied
-   when the non-threaded Qt library is loaded.
+   defined by the threaded TQt library cannot be replaced or copied
+   when the non-threaded TQt library is loaded.
 
-\i Plugins linked against a Qt library \e without thread support can only
+\i Plugins linked against a TQt library \e without thread support can only
    be loaded by libraries that are built \e without thread support.
 
    \e Rationale: 
 
    See the Rationale above.
 
-\i Starting with Qt 3.0.5, both the Qt library and all plugins are
-   built using a \e {build key}. The build key in the Qt library is
+\i Starting with TQt 3.0.5, both the TQt library and all plugins are
+   built using a \e {build key}. The build key in the TQt library is
    examined against the build key in the plugin, and if they match,
    the plugin is loaded. If the build keys do not match, then the Qt
    library refuses to load the plugin.
@@ -244,14 +244,14 @@ The build key contains the following information:
    produce binary compatible code, the version of the compiler is
    also present in the build key.
 
-\i Configuration of the Qt library. The configuration is a list
+\i Configuration of the TQt library. The configuration is a list
    of the missing features that affect the available API in the
    library. 
 
    \e Rationale:
 
    Two different configurations of the same version of
-   the Qt library are not binary compatible. The Qt library that
+   the TQt library are not binary compatible. The TQt library that
    loads the plugin uses the list of (missing) features to
    determine if the plugin is binary compatible.
 
@@ -259,7 +259,7 @@ The build key contains the following information:
    available in two different configurations. However, the
    developer writing plugins would need to know which features are
    in use, both in their plugin and internally by the utility
-   classes in Qt. The Qt library would require complex feature
+   classes in Qt. The TQt library would require complex feature
    and dependency queries and verification when loading plugins.
    Requiring this would place an unnecessary burden on the developer, and
    increase the overhead of loading a plugin. To reduce both
@@ -271,7 +271,7 @@ The build key contains the following information:
  
    \e Rationale:
 
-   When distributing binaries of the Qt library with an
+   When distributing binaries of the TQt library with an
    application, this provides a way for developers to write
    plugins that can only be loaded by the library with which the
    plugins were linked.
@@ -282,19 +282,19 @@ The build key contains the following information:
 If you want to build a plugin which you want to use with a threaded Qt
 library (whether or not the plugin itself uses threads) you must use a
 threaded environment. Specifically, you must link the plugin with a
-threaded Qt library, and you must build \link designer-manual.book Qt
+threaded TQt library, and you must build \link designer-manual.book Qt
 Designer\endlink with that library. Your \c{.pro} file for your plugin
 must include the line:
 \code
     CONFIG += thread
 \endcode
 
-\warning Do not mix the normal Qt library and the threaded Qt library in
-an application. If your application uses the threaded Qt library, you
-should not link your plugin with the normal Qt library. Nor should you
-dynamically load the normal Qt library or dynamically load another library,
-e.g. a plugin, that depends on the normal Qt library. On some systems,
+\warning Do not mix the normal TQt library and the threaded TQt library in
+an application. If your application uses the threaded TQt library, you
+should not link your plugin with the normal TQt library. Nor should you
+dynamically load the normal TQt library or dynamically load another library,
+e.g. a plugin, that depends on the normal TQt library. On some systems,
 mixing threaded and non-threaded libraries or plugins will corrupt the
-static data used in the Qt library.
+static data used in the TQt library.
 
 */