summaryrefslogtreecommitdiffstats
path: root/doc/artsbuilder/mcop.docbook
diff options
context:
space:
mode:
Diffstat (limited to 'doc/artsbuilder/mcop.docbook')
-rw-r--r--doc/artsbuilder/mcop.docbook4
1 files changed, 2 insertions, 2 deletions
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>