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

Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>

2 files changed, 2 insertions, 2 deletions

diff --git a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook
index a82b531cd83..99bdf7fe2f9 100644
--- a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook
+++ b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook
@@ -752,7 +752,7 @@ public:
 <para>är något annorlunda än att följa en NULL-pekare. Du talade inte alls om för objektet vad det är, och nu försöker du använda det. Gissningen här är att du vill ha en ny lokal instans av ett Arts::Synth_PLAY-objekt. Du kan förstås ha velat göra något annat (som att skapa objektet någon annanstans, eller använda ett befintligt fjärrobjekt). Det är i alla fall en bekväm genväg för att skapa objekt. Att skapa ett objekt när det först används fungerar inte när du väl har tilldelat det något annat (som en null-referens). </para>
 
 <para>Den motsvarande C++ terminologin skulle vara <programlisting>
-   QWidget* w;
+   TQWidget* w;
    w-&gt;show();
 </programlisting> som naturligtvis helt enkelt ger ett segmenteringsfel i C++. Så detta är annorlunda här. Det här sättet att skapa objekt är knepigt, eftersom det inte är nödvändigt att det finns en implementering för ditt gränssnitt. </para>
 
diff --git a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook
index bf79aebb367..38453d7da04 100644
--- a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook
+++ b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook
@@ -1219,7 +1219,7 @@ struct TypeDef {
 
 <para>Det finns ingen anledning att basera mellanprogram för multimedia på &Qt;. Genom att bestämma sig för det, och använda allt de där trevliga &Qt;-strömmarna och andra saker, kan det lätt leda till att mellanprogram bara blir en sak för &Qt;-(eller i själva verket bara &kde;). Jag menar att om jag någonsin ser att GNOME också använder &DCOP;, eller någonting liknande, är det förstås bevisat att jag har fel. </para>
 
-<para>Fastän jag vet att &DCOP; i grunden inte känner till de datatyper som det skickar, så att man skulle kunna använda &DCOP; utan &Qt;, se hur det används i daglig &kde;-användning: man skickar runt typer som <classname>QString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, .... De här använder &Qt;:s-serialisering. Så om någon väljer att stöda &DCOP; i ett GNOME-program, måste han antingen ange att han använder <classname>QString</classname>,... typer (även om han inte gör det), och emulera sättet som &Qt; använder för strömmar, eller så skulle han skicka runt andra sträng-, pixmap- och rect-typer, och på så sätt ändå inte kunna fungera ihop med &kde;-program. </para>
+<para>Fastän jag vet att &DCOP; i grunden inte känner till de datatyper som det skickar, så att man skulle kunna använda &DCOP; utan &Qt;, se hur det används i daglig &kde;-användning: man skickar runt typer som <classname>TQString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, .... De här använder &Qt;:s-serialisering. Så om någon väljer att stöda &DCOP; i ett GNOME-program, måste han antingen ange att han använder <classname>TQString</classname>,... typer (även om han inte gör det), och emulera sättet som &Qt; använder för strömmar, eller så skulle han skicka runt andra sträng-, pixmap- och rect-typer, och på så sätt ändå inte kunna fungera ihop med &kde;-program. </para>
 
 <para>Nå, hur som helst var alltid &arts; avsett att fungera med eller utan &kde;, med eller utan &Qt;, med eller utan X11, och kanske till och med med eller utan &Linux; (och jag har inte ens några invändningar mot personer som anpassar det till operativsystem som inte är fria). </para>