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