From 938578ffc3e80f59646041c2483985f1d70692f6 Mon Sep 17 00:00:00 2001
From: Michele Calgaro <michele.calgaro@yahoo.it>
Date: Sat, 23 Sep 2023 12:44:34 +0900
Subject: Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar,
 QString, QIODevice with TQ* version

Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>
---
 doc/artsbuilder/detail.docbook | 2 +-
 doc/artsbuilder/mcop.docbook   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

(limited to 'doc')

diff --git a/doc/artsbuilder/detail.docbook b/doc/artsbuilder/detail.docbook
index 34adf3d1..37d5e328 100644
--- a/doc/artsbuilder/detail.docbook
+++ b/doc/artsbuilder/detail.docbook
@@ -1415,7 +1415,7 @@ once you assigned something else (like a null reference).
 <para>
 The equivalent C++ terms would be
 <programlisting>
-   QWidget* w;
+   TQWidget* w;
    w-&gt;show();
 </programlisting>
 
diff --git a/doc/artsbuilder/mcop.docbook b/doc/artsbuilder/mcop.docbook
index 4b1d6615..ca4a195a 100644
--- a/doc/artsbuilder/mcop.docbook
+++ b/doc/artsbuilder/mcop.docbook
@@ -2197,11 +2197,11 @@ that, I am certainly proven wrong.
 While I do know that &DCOP; basically doesn't know about the data types
 it sends, so that you could use &DCOP; without using &Qt;, look at how
 it is used in daily &kde; usage: people send types like
-<classname>QString</classname>, <classname>QRect</classname>,
+<classname>TQString</classname>, <classname>QRect</classname>,
 <classname>QPixmap</classname>, <classname>QCString</classname>, ...,
 around. These use &Qt;-serialization. So if somebody choose to support
 &DCOP; in a GNOME program, they would either have to claim to use
-<classname>QString</classname>,...  types (although they don't do so),
+<classname>TQString</classname>,...  types (although they don't do so),
 and emulate the way &Qt; does the streaming, or they would send other
 string, pixmap and rect types around, and thus not be interoperable.
 </para>
-- 
cgit v1.2.1