Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version

Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>
(cherry picked from commit 241e0082f7b9ccadaeed0ef43a1c9ebb9b4fe840)

1 files changed, 1 insertions, 1 deletions

diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook
index 9fdef47ba8e..c29898adaf9 100644
--- a/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook
+++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook
@@ -866,7 +866,7 @@ struct TypeDef {
 
 <para> There is no need to base a middleware for multimedia on &Qt;. Deciding so, and using all that nice &Qt;-streaming and stuff, will easily lead to the middleware becoming a &Qt;-only (or rather &kde;-only) thing. I mean: as soon as I'll see the GNOMEs using &DCOP;, too, or something like that, I am certainly proven wrong. </para>
 
-<para> 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>QPixmap</classname>, <classname>QCString</classname>, ..., around. These use &Qt;-serialization. So if somebody choose to support &DCOP; in a GNOME program, he would either have to claim to use <classname>QString</classname>,... types (although he doesn't do so), and emulate the way &Qt; does the streaming, or he would send other string, pixmap and rect types around, and thus not be interoperable. </para>
+<para> 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>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, he would either have to claim to use <classname>TQString</classname>,... types (although he doesn't do so), and emulate the way &Qt; does the streaming, or he would send other string, pixmap and rect types around, and thus not be interoperable. </para>
 
 <para> Well, whatever. &arts; was always intended to work with or without &kde;, with or without &Qt;, with or without X11, and maybe even with or without &Linux; (and I have even no problems with people who port it to a popular non-free operating systems). </para>