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

Signed-off-by: Michele Calgaro <[email protected]>

2 files changed, 2 insertions, 2 deletions

diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/detail.docbook
index ebf6ba4deab..45bc5a75402 100644
--- a/tde-i18n-da/docs/tdemultimedia/artsbuilder/detail.docbook
+++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/detail.docbook
@@ -752,7 +752,7 @@ public:
 <para>er noget anderledes end at følge en NULL-peger. Du fortalte slet ikke objektet hvad det er, og nu forsøger du at bruge det. Gætværket her er at du vil have en ny lokal instans af et Arts::Synth_PLAY-objekt. Du kan naturligvis have villet gøre noget andet (såsom at oprette objektet et andet sted, eller bruge et eksisterende fjernobjekt). Det er i alle tilfælde en bekvem genvej til at oprette objekter. At oprette et objekt når det først bruges virker ikke når du allerede har tildelt det til noget andet (som en null-reference). </para>
 
 <para>Den tilsvarende C++ terminologi ville være <programlisting>
-   QWidget* w;
+   TQWidget* w;
    w-&gt;show();
 </programlisting> som naturligvis helt enkelt giver en segmenteringsfejl i C++. Så dette er anderledes her. Denne måde at oprette objekt er tricket, eftersom det ikke er nødvendigt at der findes en implementering for din grænseflade. </para>
 
diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/mcop.docbook
index c38324fa5e1..66848787e18 100644
--- a/tde-i18n-da/docs/tdemultimedia/artsbuilder/mcop.docbook
+++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/mcop.docbook
@@ -1219,7 +1219,7 @@ struct TypeDef {
 
 <para>Der er ingen grund til at basere mellemprogrammer for multimedie på &Qt;. Ved at bestemme sig for det, og bruge alle de behagelige &Qt;-strømme og andre ting, kan det let føre til at mellemprogrammer kun bliver en sag for &Qt;-(eller i virkeligheden kun &kde;). Jeg mener at hvis jeg nogensinde ser at GNOME også bruger &DCOP;, eller noget lignende, er det naturligvis beviset for at jeg har taget fejl. </para>
 
-<para>Selvom jeg ved at &DCOP; i grunden ikke kender til de datatyper som den sender, så man ville kunne bruge &DCOP; uden &Qt;, se hvordan den bruges i daglig &kde;-brug: man sender typer rundt  såsom <classname>QString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, .... Disse bruger &Qt;'s-serialisering. Så hvis nogen vælger at understøtte &DCOP; i et GNOME-program, skal han enten angive at han bruger  <classname>QString</classname>,... typer (selvom han ikke gør det), og emulere måden som &Qt; bruger til strømme, eller også skulle han sende andre streng-, pixmap- og rect-typer rundt, og på den måde alligevel ikke kunne virke sammen med &kde;-programmer. </para>
+<para>Selvom jeg ved at &DCOP; i grunden ikke kender til de datatyper som den sender, så man ville kunne bruge &DCOP; uden &Qt;, se hvordan den bruges i daglig &kde;-brug: man sender typer rundt  såsom <classname>TQString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, .... Disse bruger &Qt;'s-serialisering. Så hvis nogen vælger at understøtte &DCOP; i et GNOME-program, skal han enten angive at han bruger  <classname>TQString</classname>,... typer (selvom han ikke gør det), og emulere måden som &Qt; bruger til strømme, eller også skulle han sende andre streng-, pixmap- og rect-typer rundt, og på den måde alligevel ikke kunne virke sammen med &kde;-programmer. </para>
 
 <para>Nå, under alle omstændigheder var det altid meningen at &arts; var beregnet til at virke med eller uden &kde;, med eller uden &Qt;, med eller uden X11, og måske til og med med eller uden &Linux; (og jeg har ikke engang  indvendinger mod personer som tilretter den til operativsystemer som ikke er frie). </para>